DDNS and Hidden Master == Brain-Damaged

[Paul Vixie]

> > 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".
> 
> So it was as I feared.  The awesome design by committee approach results
> in a perfectly sane and useful technique (hidden master) losing while
> supporting brain-damage (oh, our fabulous wizz-bang dns-management
> application didn't know what that field was about so we put crap in it,
> please wipe our butts for us).  Swell.

design-by-committee often produces irreproducable results.  after a few
false starts, i stopped wringing hands and pointing fingers and saying
"but that's *so*wrong*!" and started taking notes and reading them back
to folks and asking "so you want it to do *what*, exactly?"

> > > 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.
> 
> It is "non-trash" by any sane definition.

then make it non-trash by some insane definition.  for example, make it
match one of the NS.NSDNAME's, according to the "dns view" seen by your
dhcp population.  if you want your master hidden, then make sure that the
non-dhcp-population sees some other SOA and NS for that zone.  no problem.

> Thanks for your prompt, if depressing, answers.

as always, i'm happy to have been helpful.
-- 
Paul Vixie