[dns-wg] Re: rev delegation robot and selection of NS to pull zone from
- Previous message (by thread): [dns-wg] Re: rev delegation robot and selection of NS to pull zone from
- Next message (by thread): [dns-wg] Re: rev delegation robot and selection of NS to pull zone from
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wilfried Woeber, UniVie/ACOnet
Woeber at CC.UniVie.ac.at
Thu Nov 20 20:42:36 CET 2008
Thanks, Anand, providing answers for two of my questions in one mail :-) - that this isn't going to work for this setup, and - that we can deal with it locally, by excluding the server at the NCC from the list of slaves for that zone (as the requirement for a slave at the NCC is no longer in place - which I missed). Best regards, Wilfried Anand Buddhdev wrote: > On 20/11/08 15:02, Wilfried Woeber, UniVie/ACOnet wrote: > > Hello Wilfried, > > >>Another question regarding v6 reverse delegation, but possibly also >>applicable to v4 reverse... >> >>One of our customers has a somewhat complex DNS setup which makes us >>face the situation that in the SOA record the name of the NS where >>the zone originates is not in the set of responses to NS queries. >> >>While this is not the common case, I presume, it seems to NOT be "illegal". >> >>The domain has to on-site name servers and is configured to have a slave >>at the NCC. >> >>For this zone we received an alert that the ZXFR has failed from the >>machine with the name given in the SOA. That box will never be serving >>external zone transfer requests. >> >>So - this may just be a glitch in the alerting script, but I am still >>left with the question: how does the robot at the NCC's end determine >>the "appropriate" host to try zone transfers from? > > > When the RIPE NCC's provisioning system sees ns.ripe.net in the list of > name servers for /16 IPv4 and /32 IPv6 zones, it looks up the SOA record > of the zone, extracts the MNAME from there, and looks up A and AAAA > records for the MNAME. These are then used to attempt zone transfers for > that zone. The provisioning system does not use any servers from the NS > RRset. > > The provisioning system just generates configuration for BIND running on > the ns.ripe.net cluster. It doesn't know whether a zone transfer will > succeed or not. The recent alerts that we sent out to notify > administrators of failing zone transfers were generated by a script, > which took its input from BIND log files, where we have a record of > failed zone transfers. > > The configuration you describe above isn't illegal. However, the RIPE > NCC's provisioning system won't be able to cope with it. Currently, > there's no way to explicitly provide a list of master servers that zone > transfers should be attempted from. > > One solution is to list a server in the MNAME field which will provide > zone transfers. Alternatively, you can choose not to use ns.ripe.net as > a secondary - it is no longer mandatory for /16 IPv4 and /32 IPv6 > reverse zones. >
- Previous message (by thread): [dns-wg] Re: rev delegation robot and selection of NS to pull zone from
- Next message (by thread): [dns-wg] Re: rev delegation robot and selection of NS to pull zone from
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]