Re: [dhcwg] How to encode DNS labels in DHCP options

Thomas Narten <> Wed, 05 September 2001 17:52 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id NAA12481; Wed, 5 Sep 2001 13:52:23 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id NAA18236; Wed, 5 Sep 2001 13:49:58 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id NAA18213 for <>; Wed, 5 Sep 2001 13:49:56 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA12279 for <>; Wed, 5 Sep 2001 13:48:29 -0400 (EDT)
Received: from (narten@localhost) by (8.11.2/8.9.3) with ESMTP id f85HlTZ03658; Wed, 5 Sep 2001 13:47:29 -0400
Message-Id: <>
To: Mark Stapp <>
Subject: Re: [dhcwg] How to encode DNS labels in DHCP options
In-Reply-To: Message from "Tue, 04 Sep 2001 17:27:19 EDT." <>
Date: Wed, 05 Sep 2001 13:47:28 -0400
From: Thomas Narten <>
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

Hi Mark.

> As Bernie noted, there's a historical problem in this case that makes it 
> unusually painful to remove text about the ASCII behavior entirely. We 
> don't want new clients to implement the deprecated behavior, but we need to 
> describe it for the benefit of new server implementations which will 
> encounter old clients for a long time to come.

Makes sense to me.  

> This is the revised text from section 4.1, describing the use of the "E" flag:

>     The data in the Domain Name field SHOULD appear in DNS-style binary
>     encoding (without compression, of course), as described in
>     RFC1035[3]. A client which sends the FQDN option SHOULD use this
>     encoding. The client MUST set the "E" bit when the data in the
>     Domain Name field is in DNS binary encoding. If a server receives an
>     FQDN option from a client, and intends to include an FQDN option in
>     its reply, it MUST use the same encoding that the client used, and
>     MUST set the "E" bit accordingly.

My only quibble with the above is the SHOULD. Why not a MUST?  If you
want clients that implement *this* spec to implement the binary
encoding, seems like it should be a MUST (i.e., no wiggle
room). Saying SHOULD allows them to implement the ascii flavor and be
compliant. That wouldn't seem to be the goal here.

> 4.3 The Domain Name Field

>     The Domain Name part of the option carries all or part of the FQDN
>     of a DHCP client. The data in the Domain Name field SHOULD appear in
>     uncompressed DNS encoding as specified in RFC1035[3]. If the DHCP
>     client uses DNS encoding, it MUST set the third bit in the Flags
>     field (the "E" bit). A client may be configured with a
>     fully-qualified domain name, or with a partial name that is not
>     fully-qualified. If a client knows only part of its name, it MAY
>     send a name that is not fully-qualified, indicating that it knows
>     part of the name but does not necessarily know the zone in which the
>     name is to be embedded.

Might be good to say that "not fully-qualified" really means a single

> Does this help? Is this too much change, or the right amount? Is there 
> anything that's still unclear after these changes?

Overall, this seems much better to me.


dhcwg mailing list