DDNS and Hidden Master == Brain-Damaged

[Paul Vixie]

John Hascall <john at iastate.edu> writes:

> > because that's what RFC 2136 says to do.
> 
> yes, but you wrote RFC2136, so that doesn't answer *why*.

i'm sure that's in the archives somewhere.  (while i was the main author
and editor of this document, it was a community effort and many voices
were heard during its preparation.)

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

i believe the original proposal was to always use the MNAME as the target
of update transactions, but a number of voices spoke against that on the
basis that MNAME was usually trash and that there had never been any kind
of protocol requirement that it not be trash and attempting to redefine
it as non-trash would break a number of dns-management applications.  so
we said "very well, let's do update forwarding amongst published servers,
since published servers already have to know who the master server is",
but then a number of people said "but that's silly, if the MNAME isn't
trash, we should use it."  the definition of "MNAME isn't trash" turned
out to be "MNAME matches one of the NSDNAMEs".

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

use a non-trash MNAME in the dns view seen by your dhcp server and clients.
-- 
Paul Vixie