John C Klensin wrote:
--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.
Right. In the context of this draft, the term domain suffix is
not meant to be just the TLD. If "domain suffix" generally means,
or is thought of as, just the TLD, then the draft should use some
other term instead.
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.
Right, I understand what you mean, provided that "domain suffix"
generally just means the TLD or the last label in the FQDN.
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
Yes
"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).
"One item" is intended to say that there is just one "domain name".
So you can specify "claranet.de" so that you get xyzzy.claranet.de,
but it can not have two values/items, like both "claranet.de" and
"bogus.domain.name". Clearly the text could be improved here.
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.
Right, this is not at all what is intended.
Stig
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf