Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26723 for ; Tue, 5 Mar 2002 15:32:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03265 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 15:32:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02856; Tue, 5 Mar 2002 15:30:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02813 for ; Tue, 5 Mar 2002 15:30:20 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26610 for ; Tue, 5 Mar 2002 15:30:12 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g25KUEh07904 for ; Tue, 5 Mar 2002 14:30:14 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g25KUEj24900 for ; Tue, 5 Mar 2002 14:30:14 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Mar 05 14:30:13 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 14:30:13 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4D07B@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'rbhibbs@pacbell.net'" , dhcwg@ietf.org Subject: RE: [dhcwg] Host Name option considerations draft Date: Tue, 5 Mar 2002 14:30:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C484.8CDD11F0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C484.8CDD11F0 Content-Type: text/plain; charset="iso-8859-1" Barr ... thanks for providing some of these comments - I had several of them but hadn't yet sent a message. And, Carl and Ted, thanks for writing this draft! FYI Barr, I believe regarding your issue: >In (3), the Host Name *is* the FQDN, but how do I parse it properly into a >"DNS domain name" given that simple rules such as "use the last two parts of >the name" (which works for things like "dot.com") renders the DNS domain >name as "co.uk" which I don't think is what you intend. The host would remove the first label to produce the Domain Name, hence "inside.sales.bluebear.co.uk". That's all it can and should do. --- > "a client SHOULD check for the presence of both Host Name > and Domain Name options, forming the FQDN by appending the > Domain Name to the Host Name. A client MAY wish to compare > the Host Name option to the Domain Name option to verify > that the Host Name option does not include the Domain Name > part before concatenating the parts." I like this better than what Mike was suggesting because I could easily see a case, such as your (2) below that should work and thus the client can not simply see if the Host Name has one or more dots to determine whether it is fully qualified. I would suggest that (a) if the host name has NO dots, the client should add the domain name. If the host name has one or more dots, the client should only add the domain name if the host name does not end in the domain name. >2. Host Name: "mike.inside.sales" > Domain Name: "bluebear.co.uk" --- Perhaps I missed it, but can we be clear about whether the trailing dot MUST NOT be included. And, for backwards compability, a client (and server) should remove any trailing dot if it does exist (this applies to the Host Name, Domain Name, and FQDN options). --- One thing that wasn't clear to me (and perhaps it is specified in RFC 2131?), but for a client REQUEST, does (MUST) a client send the Host Name and FQDN options the server sent in the OFFER, or MUST it send what it originally sent in the DISCOVER? From this draft, it would appear it MUST send what was in the DISCOVER and not what the server may have sent back. - Bernie -----Original Message----- From: Richard Barr Hibbs [mailto:rbhibbs@pacbell.net] Sent: Tuesday, March 05, 2002 2:18 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] Host Name option considerations draft Carl, Ted, et al.-- I've cut and pasted some sections from the draft with my comments.... --Barr <*Snip!*> 3. Interactions with Name Services A DHCP client's use of the Host Name option should be fairly straightforward, but users report problems, particularly with the interactions between it and Domain Name option and between the DNS (RFC 1034 [5] and RFC 1035 [6]) and other naming services so we reiterate and expand the description of the expected behavior: if a DHCP server supplies both Host Name and Domain Name options to a client, the host name SHOULD NOT be fully- qualified *corollary one* -- the Domain Name option also SHOULD NOT be fully-qualified *corollary two* -- the name formed by concatenating Host Name and Domain Name MUST be the Fully-Qualified Domain Name of the host, that is, there should be no other prefixes or suffixes added to the Host Name and Domain Name parts in creating the FQDN if a DHCP server supplies only a Host Name option, the host name SHOULD be fully qualified; the server MUST append only DNS domain names in forming a fully-qualified name Carl, I don't understand your point here: if the Host Name part IS fully-qualified, how can any other information be added to it and make an understandable name? For example, if the Host Name part is "rabbit.warren.org" what could be appended that makes any sense? a client MUST check to see whether a Host Name option contains a fully-qualified name and if so, MUST NOT append the value of the Domain Name option (if present) in forming its fully- qualified domain name Carl, I think "MUST" is too strong here, plus I think this wording calls for a specific level of sophistication in a client where it really should be an implementation decision. Having said that, if I understand this point correctly, to mean that you are trying to guide a client so that invalid FQDNs are not unintentionally created, I agree with the concept. How about wording such as: "a client SHOULD check for the presence of both Host Name and Domain Name options, forming the FQDN by appending the Domain Name to the Host Name. A client MAY wish to compare the Host Name option to the Domain Name option to verify that the Host Name option does not include the Domain Name part before concatenating the parts." The proposed wording does not require the client either to have local knowledge of Top Level Domain names or to perform a DNS lookup on the Host Name to determine if it is fully-qualified, which are the only two ways I can imagine for the client to test the name as you proposed. since a Host Name option's value may be fully-qualified only by supplying the DNS domain name, a client that receives a fully- qualified name in the Host Name option MAY infer the DNS domain name from the suffix of the supplied host name. This inference remains valid even in the presence of client configuration information or policies that prefer other name services in favor of, or in place of, DNS. Carl, I don't understand what you're saying here. Perhaps a few examples will show you my confusion: 1. Host Name: "mike" Domain Name: "inside.sales.bluebear.co.uk" 2. Host Name: "mike.inside.sales" Domain Name: "bluebear.co.uk" 3. Host Name: "mike.inside.sales.bluebear.co.uk" Domain Name: "" In (1) and (2) appending the Domain Name to the Host Name clearly produces an FQDN, but which is the "correct" representation of the "DNS domain name" since both are valid representations? In (3), the Host Name *is* the FQDN, but how do I parse it properly into a "DNS domain name" given that simple rules such as "use the last two parts of the name" (which works for things like "dot.com") renders the DNS domain name as "co.uk" which I don't think is what you intend. <*Snip!*> 4.1 DHCP Client Considerations and Behavior A DHCP client that uses the Host Name option to request a DNS update MUST be prepared to independently verify the success or failure of the request before using the name in a manner that would imply its validity. If a DHCP server returns the requested name in the DHCPACK's Host Name option, the client MAY infer that the server has honored its request. There are a number of reasons that a DHCP server may fail to return a Host Name option, so nothing should be inferred from the option's absence in the DHCPACK. The client MAY supply the option on subsequent RENEW operations as a method of retrying the request. However, if the Host Name option is absent in the DHCPACK, the client MUST NOT use the requested name until it has verified the validity of the association between it and the IP address supplied in the yiaddr field. Moreover, if the name returned in the DHCPACK is different from the one requested, the client MUST use the new name. So, are you implying that (1) if a client does not request a Host Name option from the server [typical of several widely-deployed clients!] but (2) the server returns a Host Name option anyway in a DHCPACK, the client should accept the [presumably] unwanted name? I think this will break a whole lot of deployed clients. A DHCP client MAY send either an unqualified or fully-qualified name in the Host Name option. Clients sending unqualified names are implicitly relying on DHCP servers to associate the clients with the appropriate zone before issuing any updates to DNS. A DHCP client in INIT state SHOULD fill in the requested host name in the DHCPDISCOVER packet. It MUST do so in its subsequent DHCPREQUEST packet. Here, again, I don't know how the server can reliably parse an FQDN sent in the Host Name option. <*Snip!*> 4.2 DHCP Server Considerations and Behavior Use of the FQDN option makes it possible to easily separate update operations into pieces corresponding to what are thought of as the traditional ownership boundaries: DHCP servers own the addresses they lease, while the clients own their names. This boundary is not present when the Host Name option is used: the implied proxy update request assumes that the DHCP server has sufficient privilege to change both the A and PTR records. That is, it ``owns'' both. For this and other reasons, use of the FQDN option is preferred: a DHCP server that receives both a Host Name option and a client FQDN option MUST prefer the FQDN option. In such a case, the server SHOULD behave as if the Host Name option is not present. I'm inclined to go further and suggest: "If a server receives both the Host Name option and the FQDN option from a client [for whom DNS updates are being proxied] the fully qualified name formed by appending the Domain Name to the client-supplied Host Name MUST be identical to the FQDN option for the server to update DNS on behalf of the client. The server SHOULD return an error to the client if the names do not match." This is something that has always bothered me about the FQDN option and the DHCP-DNS update protocol -- is a mismatch an unintentional accident or an attempt to confuse and invalidate DNS records? <*Snip!*> _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1C484.8CDD11F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Host Name option considerations draft

Barr ... thanks for providing some of these comments = - I had several of them but hadn't yet sent a message. And, Carl and = Ted, thanks for writing this draft!

FYI Barr, I believe regarding your issue:

>In (3), the Host Name *is* the FQDN, but how do I = parse it properly into a
>"DNS domain name" given that simple = rules such as "use the last two parts of
>the name" (which works for things like = "dot.com") renders the DNS domain
>name as "co.uk" which I don't think is = what you intend.

The host would remove the first label to produce the = Domain Name, hence
"inside.sales.bluebear.co.uk". That's all = it can and should do.

---

>      "a client = SHOULD check for the presence of both Host Name
>      and Domain Name = options, forming the FQDN by appending the
>      Domain Name to = the Host Name.  A client MAY wish to compare
>      the Host Name = option to the Domain Name option to verify
>      that the Host = Name option does not include the Domain Name
>      part before = concatenating the parts."

I like this better than what Mike was suggesting = because I could easily see a
case, such as your (2) below that should work and = thus the client can not simply
see if the Host Name has one or more dots to = determine whether it is fully qualified.
I would suggest that (a) if the host name has NO = dots, the client should add the
domain name. If the host name has one or more dots, = the client should only add
the domain name if the host name does not end in the = domain name.

>2.  Host Name:  = "mike.inside.sales"
>    Domain Name:  = "bluebear.co.uk"

---

Perhaps I missed it, but can we be clear about = whether the trailing dot MUST NOT
be included. And, for backwards compability, a = client (and server) should remove
any trailing dot if it does exist (this applies to = the Host Name, Domain Name,
and FQDN options).

---

One thing that wasn't clear to me (and perhaps it is = specified in RFC 2131?), but
for a client REQUEST, does (MUST) a client send the = Host Name and FQDN options the
server sent in the OFFER, or MUST it send what it = originally sent in the DISCOVER?
From this draft, it would appear it MUST send what = was in the DISCOVER and not
what the server may have sent back.


- Bernie

-----Original Message-----
From: Richard Barr Hibbs [mailto:rbhibbs@pacbell.net]
Sent: Tuesday, March 05, 2002 2:18 PM
To: dhcwg@ietf.org
Subject: RE: [dhcwg] Host Name option considerations = draft



Carl, Ted, et al.--

I've cut and pasted some sections from the draft with = my comments....

--Barr


<*Snip!*>

3. Interactions with Name Services

   A DHCP client's use of the Host Name = option should be fairly
   straightforward, but users report = problems, particularly with the
   interactions between it and Domain Name = option and between the DNS
   (RFC 1034 [5] and RFC 1035 [6]) and = other naming services so we
   reiterate and expand the description of = the expected behavior:

      if a DHCP server = supplies both Host Name and Domain Name
      options to a client, = the host name SHOULD NOT be fully-
      qualified

*corollary one* -- the Domain Name option also SHOULD = NOT be fully-qualified

*corollary two* -- the name formed by concatenating = Host Name and Domain
Name MUST be the Fully-Qualified Domain Name of the = host, that is, there
should be no other prefixes or suffixes added to the = Host Name and Domain
Name parts in creating the FQDN


      if a DHCP server = supplies only a Host Name option, the host
      name SHOULD be fully = qualified; the server MUST append only DNS
      domain names in = forming a fully-qualified name

Carl, I don't understand your point here:  if = the Host Name part IS
fully-qualified, how can any other information be = added to it and make an
understandable name?  For example, if the Host = Name part is
"rabbit.warren.org" what could be appended = that makes any sense?


      a client MUST check to = see whether a Host Name option contains
      a fully-qualified = name and if so, MUST NOT append the value of
      the Domain Name = option (if present) in forming its fully-
      qualified domain = name

Carl, I think "MUST" is too strong here, = plus I think this wording calls for
a specific level of sophistication in a client where = it really should be an
implementation decision.  Having said that, if = I understand this point
correctly, to mean that you are trying to guide a = client so that invalid
FQDNs are not unintentionally created, I agree with = the concept.  How about
wording such as:

      "a client SHOULD = check for the presence of both Host Name
      and Domain Name = options, forming the FQDN by appending the
      Domain Name to the = Host Name.  A client MAY wish to compare
      the Host Name option = to the Domain Name option to verify
      that the Host Name = option does not include the Domain Name
      part before = concatenating the parts."

The proposed wording does not require the client = either to have local
knowledge of Top Level Domain names or to perform a = DNS lookup on the Host
Name to determine if it is fully-qualified, which = are the only two ways I
can imagine for the client to test the name as you = proposed.


      since a Host Name = option's value may be fully-qualified only by
      supplying the DNS = domain name, a client that receives a fully-
      qualified name in the = Host Name option MAY infer the DNS domain
      name from the suffix = of the supplied host name.  This inference
      remains valid even in = the presence of client configuration
      information or = policies that prefer other name services in
      favor of, or in place = of, DNS.

Carl, I don't understand what you're saying = here.  Perhaps a few examples
will show you my confusion:

1.  Host Name:  "mike"
    Domain Name:  = "inside.sales.bluebear.co.uk"

2.  Host Name:  = "mike.inside.sales"
    Domain Name:  = "bluebear.co.uk"

3.  Host Name:  = "mike.inside.sales.bluebear.co.uk"
    Domain Name:  = ""

In (1) and (2) appending the Domain Name to the Host = Name clearly produces
an FQDN, but which is the "correct" = representation of the "DNS domain name"
since both are valid representations?

In (3), the Host Name *is* the FQDN, but how do I = parse it properly into a
"DNS domain name" given that simple rules = such as "use the last two parts of
the name" (which works for things like = "dot.com") renders the DNS domain
name as "co.uk" which I don't think is = what you intend.

<*Snip!*>

4.1 DHCP Client Considerations and Behavior

   A DHCP client that uses the Host Name = option to request a DNS
   update MUST be prepared to = independently verify the success or
   failure of the request before using the = name in a manner that
   would imply its validity.  If a = DHCP server returns the requested
   name in the DHCPACK's Host Name option, = the client MAY infer that
   the server has honored its = request.

   There are a number of reasons that a = DHCP server may fail to
   return a Host Name option, so nothing = should be inferred from the
   option's absence in the DHCPACK.  = The client MAY supply the option
   on subsequent RENEW operations as a = method of retrying the
   request.  However, if the Host = Name option is absent in the
   DHCPACK, the client MUST NOT use the = requested name until it has
   verified the validity of the = association between it and the IP
   address supplied in the yiaddr = field.  Moreover, if the name
   returned in the DHCPACK is different = from the one requested, the
   client MUST use the new name.

So, are you implying that (1) if a client does not = request a Host Name
option from the server [typical of several = widely-deployed clients!] but (2)
the server returns a Host Name option anyway in a = DHCPACK, the client should
accept the [presumably] unwanted name?  I think = this will break a whole lot
of deployed clients.


   A DHCP client MAY send either an = unqualified or fully-qualified
   name in the Host Name option.  = Clients sending unqualified names
   are implicitly relying on DHCP servers = to associate the clients
   with the appropriate zone before = issuing any updates to DNS.  A
   DHCP client in INIT state SHOULD fill = in the requested host name
   in the DHCPDISCOVER packet.  It = MUST do so in its subsequent
   DHCPREQUEST packet.

Here, again, I don't know how the server can reliably = parse an FQDN sent in
the Host Name option.

<*Snip!*>

4.2 DHCP Server Considerations and Behavior

   Use of the FQDN option makes it possible = to easily separate update
   operations into pieces corresponding to = what are thought of as the
   traditional ownership boundaries:  = DHCP servers own the addresses
   they lease, while the clients own their = names.  This boundary is
   not present when the Host Name option = is used:  the implied proxy
   update request assumes that the DHCP = server has sufficient
   privilege to change both the A and PTR = records.  That is, it
   ``owns'' both.

   For this and other reasons, use of the = FQDN option is preferred:
   a DHCP server that receives both a Host = Name option and a client
   FQDN option MUST prefer the FQDN = option.  In such a case, the
   server SHOULD behave as if the Host = Name option is not present.

I'm inclined to go further and suggest:

   "If a server receives both the Host = Name option and the FQDN
   option from a client [for whom DNS = updates are being proxied] the
   fully qualified name formed by = appending the Domain Name to the
   client-supplied Host Name MUST be = identical to the FQDN option
   for the server to update DNS on behalf = of the client.  The server
   SHOULD return an error to the client if = the names do not match."

This is something that has always bothered me about = the FQDN option and the
DHCP-DNS update protocol -- is a mismatch an = unintentional accident or an
attempt to confuse and invalidate DNS = records?

<*Snip!*>



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1C484.8CDD11F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg