[dns-wg] Re: rev delegation robot and selection of NS to pull zone from

["Wilfried Woeber, UniVie/ACOnet" Woeber@localhost]

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.
>