Dynamic DNS (was Re: h2n 2.38)

[Andris Kalnozols]

> >>>>> "Andris" == Andris Kalnozols <andris at hpl.hp.com> writes:
> 
>     Andris> For the benefit of the DNS novices, what Kevin is
>     Andris> referring to is DNS Dynamic Update as introduced by RFC
>     Andris> 2136.
> 
> Jim Reid wrote:
>
> Maybe, maybe not. All he seemed to be saying was make the DNS the one
> repository for naming and addressing information. And quite right too!
> DDNS is just one way of doing that. [Not a particularly good way IMHO,
> but that's another story.] There are other ways of centralising that
> information in the DNS: like maintaining the DNS zone files by hand;
> generating them from tools; or using enterprise DNS "solutions" like
> QIP or NetID.

I jumped the DDNS assumption based on my [perhaps flawed] recollection
of information gleaned from Kevin's past posts (thanks, BTW, for his
contributions).  As for a couple of the cited alternate methods of
generating zone files:

  * Manual maintenance.
    Personally, I can't imagine doing this for anything larger than
    a /24 network.  I look at division of labor between [wo]man and
    machine and there's something wrong with this picture in a large
    environment.

  * Generation from tools.
    Arguably hn2 is one such tool with the ubiquitous /etc/hosts file
    as its database from which A/CNAME/PTR RRs can be directly derived.
    It's at least half the work of the manual method.

No matter what tool is used (h2n, dnswalk, DNS Expert, etc.), the
point I wanted to drive home was the regular use of *something* that
checks the human's handiwork for basic DNS compliance.

>     Andris> DDNS is a Good Thing(tm) and it's use should be encouraged
>     Andris> for those whose environment justifies the bit of added
>     Andris> complexity.
> 
> I disagree. Unless DDNS is used sensibly, it can cause far bigger
> problems than it supposedly solves. Lack of proper audit trails, weak
> change controls, scaling, security, and inconsistent zone integrity
> (eg CNAME and other data errors) are just some of the problems that
> can arise from ill-judged use of DDNS. For instance until BIND9 came
> out there were no fine-grained controls over what a DDNS client could
> do. Essentially they had unrestrained write access to a zone. Any
> "trusted" DDNS client could diddle with MX records or change the
> zone's NS records, etc, etc. This is absolutely not a Good Thing.

By Good Thing I certainly wan't thinking about anything approaching
"allow-update { any; };" and crossing one's fingers.  As usual,
there's no free lunch here - a DDNS infrastructure must be engineered
with *geat* care and I certainly should have stressed this a lot more.
But I like the concept.

>     Andris> Also, BIND 8 users considering the nsupdate command should
>     Andris> be aware that it requires a zone's master nameserver to
>     Andris> appear in the NS RRset as well as in the SOA RR's MNAME
>     Andris> field, i.e., no stealth master is allowed because update
>     Andris> forwarding is not implemented.  This presents a bit of a
>     Andris> dilemma for a master that's behind a firewall because
>     Andris> including such an unreachable nameserver in the NS RRset
>     Andris> violates the best current practice per RFC 2182.
> 
> True enough, but why would anybody want to trust DDNS updates that
> came from the other (presumably hostile and untrusted) side of a
> firewall?

In total agreement here.  My [too vague] inference was the scenario
of moving a stealth master to a bastion host just to be able to use
nsupdate and satisfy RFC 2182.  Don't even think about it.

Andris Kalnozols
Hewlett-Packard Laboratories
andris at hpl.hp.com