Dynamic DNS (was Re: h2n 2.38)
Andris Kalnozols
andris at hpl.hp.com
Fri Jun 15 19:22:42 UTC 2001
> >>>>> "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
More information about the bind-users
mailing list