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.