ietf
[Top] [All Lists]

Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)

2005-09-01 13:37:29


On Thursday, September 01, 2005 15:31:05 -0400 Daniel Senie <dts(_at_)senie(_dot_)com> wrote:


These are the same issues I recall asking about when dynamic DNS was
being discussed/proposed. Any machine can make a claim they're whomever
they want to be, and that request to insert mapping gets fired off to
some distant DNS server who has no idea who the client is. I recall being
told that any authorization to use a particular name was out of scope of
the protocol. Thanking the person who told me this, I've made it a point
to disable dynamic DNS in all envinronments since it's been available in
running code. It's useless.

Actually, it's not completely useless. DDNS can be highly useful in specific deployments, where requests are authenticated and where there is a suitable authorization policy in place. And yes, policy (authorization or otherwise) generally is out of scope for a well-designed protocol, and for good general-purpose implementations as well.


For example, here at CMU most of our authoritative nameservers are updated via DDNS; this allows us to map dynamically-assigned addresses to real hostnames, and to mix names of machines with dynamically- and statically-assigned addresses in the same domain. The trick is that DDNS updates are all authenticated, and the only clients permitted to make such updates are the DHCP servers (which add and remove both forward and reverse records for dynamically-assigned hosts) and the tools which propagate changes from the network registration database (which maintain all the other records).

Of course, more precise policies are possible. For example, a site like dyndns.org could allow a particular authenticated DDNS client to point its own name to any address it likes, but not to change any other name.



I suppose LLMNR might have its uses, too. But I can't figure out what they are, and whether they are worth the significant amount of confusion and breakage which seem likely to result from widespread deployment of this protocol on the Internet.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+(_at_)cmu(_dot_)edu>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf