--On Wednesday, 27 September, 2006 09:19 +0200 Stig Venaas
<stig(_dot_)venaas(_at_)uninett(_dot_)no> wrote:
Frank Ellermann wrote:
Fred Baker wrote:
["domain suffix"]
It is the new-speak for use when all us ancient geeky types
would prefer "TLD".
It's what a client might add to it's hostname to form an FQDN.
Typically also used as domain search path by many systems if
no explicit search path is specified. Often also called
"domain name".
Whoops. It is what a client might add to a hostname to form an
FQDN if, and only if, that hostname appears as a second level
domain. But hostnames as registrations in TLD zones are not
especially common, MX records for mail and short forms for web
servers notwithstanding. The typical host name looks more like
abc.example.com or xyz.example.co.uk.
For example, note that to get an FQDN from Frank's hostname
("xyzzy") one needs to add "claranet.de", and not "de", but the
latter is all that is permitted by this proposal. If software
Frank was running assumed it could use this DHCP option to
construct an FQDN from Frank's hostname, Frank would end up with
xyzzy.de, which is probably not what is intended.
I thought it's some new kind of DHCP builtin DynDNS service.
If it's a TLD I'm perplexed why that would ever change for a
given DHCP server. And for clients of different servers the
TLD isn't enough to know where they are.
For a given DHCP server and a given client, this would
normally not change. The draft doesn't say that it might
change either. However, a given server might give different
domain suffices to different clients.
But, if your guess as to what this is for -- providing
information for completing an FQDN given a host name -- is
correct, then the option should be returning all of the FQDN
after the first component, "claranet.de" in Frank's case or
"bogus.domain.name" for a host FQDN of
"silly.bogus.domain.name". But that use is prohibited: the
specification says that the option value may contain only one
"item" (presumably a DNS label).
The only thing I can think of that this option, as specified,
would support is not FQDN completion but the setting and
implementation of policy options on an TLD basis. An example of
such a policy option would be the idea of interpreting IDNs
differently depending on what top-level domain they appeared in
that floated around some years ago. That whole family of
policies strikes me as bad ideas, bordering on horrible, given
the nature of the DNS administrative structure.
I have sent a somewhat longer note to the IESG list.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf