Ralf Weber wrote:
Moin!
On 20.11.2008, at 20:14, Anand Buddhdev wrote:
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.
Why? I mean for me that would be one natural source of information another of course would be the nserver entries in the RIPE database.
Beware - I am not a DNS expert... My feeling is that the current behaviour is quite reasonable. Of course we might suggest to look at the NS records (in addition maybe), but I presume that many folks do not allow zone transfers from *all* NS in the set. Unless we find a "clever" way to provide the info about the name server(s) to try for a transfer, overall, we would just increase the number of failed attempts. Whether that would do any harm (at the NCC's or customer's end) is a different story, maybe.
Using these source also would increase the resiliency of the zone transfers as the server then usually has more than one source to transfer the zone from. I think that this is what people using hidden/ distribution masters want to have also, at least from my experience with our customers using this.
[..]
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.
Both are options, but I still would like to know if it wouldn't make more sense to use nserver records or NS RRset. Do you have some statistics on how often the MNAME is not in the nserver/NS RRset?
I definitely don't have any figures.
So long -Ralf
Wilfried