Dynamic DNS (was Re: h2n 2.38)

[Kevin Darcy]

Jim Reid wrote:

> >>>>> "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.
>
> Maybe, maybe not. All he seemed to be saying was make the DNS the one
> repository for naming and addressing information.

Yes, my comments about the use and abuse of h2n were made primarily in
the context of whether or not DNS should be the central repository of
information. How you maintain that repository is mostly irrelevant to
that point. For many years, DNS has been Chrysler ITM's central
repository of naming/addressing information and was maintained by a
non-DDNS-based maintenance system. So I'm certainly familiar with that
scenario.

However, I do also _coincidentally_ happen to favor using Dynamic Update
to maintain DNS, and I have some experience in such areas, having
recently migrated our maintenance system to use Dynamic Update. So, since
the thread has apparently drifted in that direction, I'll respond to
Jim's points below...

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

The main "problem" that DDNS attempts to "solve" is how to cleanly and
efficiently and elegantly manipulate the DNS database, with a fine degree
of granularity, potentially from multiple remote clients. Dynamic Update
is just *part* of a DNS maintenance system, possibly an interchangeable
part, not a maintenance system _ipso_facto_  and the quality of the
maintenance system as a whole probably depends more on other parts
besides the DDNS component.

Another "problem" that DDNS solves is integration with DHCP and/or Win2K
client registration and/or Active Directory subsystems. How many posts
have we seen on this list like "I converted my zone to use Dynamic Update
for {DHCP/Win2K/AD}, so now how do I do manual updates to the zone
file?". The answer, as we know, is "you don't, use Dynamic Update to
maintain the zone from now on". So, is it better to use DDNS to maintain
*some* zones, and a non-DDNS methodology to maintain the rest, or is it
better to use a single methodology for maintenance of *all* zones?

> Lack of proper audit trails,

This problem is not specific to the use of DDNS. In fact, at least with
DDNS you have an idea in named's logs of what was changed. With a
non-DDNS-based maintenance system, like one which spews out zonefiles
from an external database e.g. an SQL database, you have no inkling in
named's logs as to what has changed in the zone, if anything. Any logging
that is done has to be done in the maintenance system itself.

> weak
> change controls,

Ditto. This problem is not specific to the use DDNS.

> scaling,

Not sure what is meant here. If anything, DDNS would seem to scale better
because the changes are made incrementally. Most non-DDNS maintenance
systems I've seen -- including my old legacy system that I replaced with
a DDNS-based one -- reload a whole zone (or even the whole nameserver!)
after each update. That's not very scalable for a high frequency of
updates.

> security,

I don't understand this criticism. DDNS updates can be secured with
TSIG (or I presume, with DNSSEC in BIND 9) *in*addition*to* whatever
security mechanisms you have embedded in the maintenance system itself.
How is this less secure? Moreover, with a non-DDNS-based maintenance
system, you have to give the maintenance system access to manipulate
zonefiles somehow, which typically means putting extra software on the
master, e.g. SQL databases or whatever, or giving remote access to
zonefiles, e.g. rcp/scp/rsync/whatever, or NFS. Setting up a trust
relationship for remote file access obviously decreases security, and
putting extra software like an SQL database on the master increases its
configuration complexity and commensurately the likelihood of
vulnerabilities. With TSIG-authenticated DDNS, the master can have a very
simple, secure configuration; named is the *only* thing allowed to
programmatically manipulate zone files, and the only people allowed on
the box are system-support and DNS-infrastructure-support people. Of
course, it goes without saying that the TSIG keys need to be protected.
But if given a choice I'd rather protect a key than a whole
remote-file-access or database subsystem. (I suppose it can be argued
that if you use an *authenticated* remote-file-access system, e.g. scp or
whatever-over-ssh, then that also boils down to protecting just a key.
However, it still leaves the configuration-complexity argument, since the
more sophisticated remote-file-access systems are also more complex.
Compare the complexity of such subsystems to merely specifying a
"keys" statement in your named.conf and then using the key name in the
relevant allow-update ACLs. And let's not forget that if the non-DDNS
mechanism needs to reload a zone after updating the zonefile, in BIND 9
it needs key configuration *anyway* in order to issue rndc commands. So
if you have to generate, configure and protect a key anyway, why not use
that key for Dynamic Update and be done with it? Configuring one key for
ssh and another for rndc and then having to protect both keys as well as
install, configure and protect the whole ssh subsystem on the master
seems rather ridiculous compared to this).

> and inconsistent zone integrity
> (eg CNAME and other data errors)

I'm not sure that BIND will accept a Dynamic Update that would cause a
CNAME and other data error, or other kinds of inconsistency-causing
updates that would cause a zone to be rejected. Even if it does accept
them in its current incarnation, I don't think it would violate the
Dynamic Update spec for it to automatically reject such updates. So, at
most, this complaint is just about a missing BIND feature, not the whole
idea of using DDNS for maintenance systems, _per_se_.

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

Agreed, but diddling with those records in the zone file is also a risk
with non-DDNS-based solutions, and a bug in a non-DDNS-based maintenance
system that would cause a zonefile to become munged, seems more likely
than a bug in named itself which would cause corruption when it processes
the update and/or when it dumps the zonefile.

DDNS is, after all, just a *mechanism* for getting the records into the
DNS database; if you're smart, you enforce restrictions on that
mechanism. In our case, the only thing which has access to the necessary
TSIG key(s) is a program which (in addition to enforcing security, and
doing the forward/reverse synchronization) does a whole slew of sanity
checks before generating the Dynamic Update, and even then it puts
prereqs on that Dynamic Update for an extra guarantee of consistency.
This sanity-checking program is in fact the same one I used before
I implemented Dynamic Update, just with a different, DDNS-based backend
bolted onto it.

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

This point is rather moot: Andris is referring only to a limitation in
the BIND 8 nsupdate client and/or the BIND 8 nameserver. If one writes
one's own Dynamic Update client (using the BIND 8 libraries if one
wishes), or uses the Perl Net::DNS module's Dynamic Update routines, or
uses the BIND 9 nsupdate client (which works fine with a BIND 8
nameserver), one can *explicitly* specify the target server for the
Dynamic Update. This is exactly what I'm doing here -- using BIND 9
nsupdate and explicitly specifying the target server -- with my "hidden
master" setup.

And of course, if one upgrades nameservers to BIND 9 then update
forwarding is available too. (Admittedly my external slaves are still
running BIND 8, but it doesn't matter in this context since I don't need
update forwarding).


- Kevin