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

"Henning G. Schulzrinne" <> Sat, 08 September 2001 17:00 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id NAA27498; Sat, 8 Sep 2001 13:00:03 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id MAA28431; Sat, 8 Sep 2001 12:59:09 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id MAA28411 for <>; Sat, 8 Sep 2001 12:59:07 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA27478 for <>; Sat, 8 Sep 2001 12:57:39 -0400 (EDT)
Received: from ( []) by (8.9.3+Sun/8.9.3) with ESMTP id MAA12878; Sat, 8 Sep 2001 12:58:59 -0400 (EDT)
Message-ID: <>
Date: Sat, 08 Sep 2001 12:58:59 -0400
From: "Henning G. Schulzrinne" <>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-3cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ted Lemon <>
CC: Thomas Narten <>,
Subject: Re: [dhcwg] How to encode DNS labels in DHCP options
References: <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>
Content-Transfer-Encoding: 7bit

I think in practice, this only moves the problem around. It seems
unlikely that configuration files for DHCP servers would force users to
enter RFC 1035 notation. Among other things, it is rather likely to
cause errors. (Forget to update the count byte when you change a label
and you've introduced some rather strange results.) 

Thus, I would expect that actual servers will use some higher-level
character set that can express IDN names, say, UTF-8 and then internally
translate. If that's the case, it really doesn't much matter where the
translation takes place. 

It does matter if the standard OS interfaces expect UTF-8, say, since
most applications will need this. In that case, you'll do the
translation twice. The client gets the RFC 1035 string from DHCP,
translates it into UTF-8 so that the client OS understands it and then
this gets translated again by the resolver library back into RFC 1035
for the on-the-wire format. I know of no current resolver library that
allows you to specify RFC 1035 labels as input, but I obviously haven't
done a complete survey. Can be done, but hasn't accomplished much in
terms of avoiding translation errors, since you have two translations
instead of one. One can only hope that both translation directions are
one-to-one, otherwise you could get some peculiar results.

Ted Lemon wrote:
> The idea of using the RFC1035 encoding is that it is exactly what the
> DNS protocol currently specifies.   This means that if we use this
> format, we don't have to worry that it will be our fault that the
> encoding doesn't work.   When IDN happens, it will presumably work on
> top of the existing packet format, so that means that what we have
> specified should also work.
> So IMHO any new DHCP option that contains a domain name should use the
> RFC1035 format.   I can't remember the details with SIP, but I *think*
> that what is being encoded is not a domain name, and that is the
> reason for the difference.

Henning Schulzrinne

dhcwg mailing list