DDNS and Hidden Master == Brain-Damaged

[John Hascall]

> John Hascall <john at iastate.edu> writes:
> > Can somebody explain to me why on earth the DDNS code,
> > after looking up the SOA for the zone to be updated,
> > insists on checking the NS records for the zone to see
> > if the SOA.MNAME is listed there?

> because that's what RFC 2136 says to do.

yes, but you wrote RFC2136, so that doesn't answer *why*.

What is GAINED by looking through the NS records to see
if the SOA.MNAME is listed there?  At best it seems to
catch the case where some doofus puts nonsense in for the
MNAME and the resolver just happens to luckily choose the
real master from among the NS records.  And, of course,
this means only intermittent success if there are more than
3 NS addresses.


> RFC 2136 says:
> 
>    4.3. If the requestor has reasonable cause to believe that all of a
>    zone's servers will be equally reachable, then it should arrange to
>    try the primary master server (as given by the SOA MNAME field if
>    matched by some NS NSDNAME) first to avoid unnecessary forwarding
>    inside the slave servers.  (Note that the primary master will in some
>    cases not be reachable by all requestors, due to firewalls or network
>    partitioning.)

> res_findzonecut() is only called if your nsupdate doesn't specify a server.
> therefore if you have specific knowledge of what server ought to be receiving
> the update, you should share that knowledge and avoid res_findzonecut() all
> together.

And how do I make ISC DHCP do that?

John