Dynamic DNS (was Re: h2n 2.38)

[Jim Reid]

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

    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?