dhcpcd-discuss

Thanks Roy.

I agree with your reasoning.  People using the ISC dhcpd server can (and should) set "option fqdn.encoded true" in their server configuration when using "option fqdn.fqdn" to provided fqdns to dhcp clients.  This conforms to the standard.  The deprecated ASCII form of fqdn should never be used and there's no sense in implementing support for it in DHCP servers or clients.

Paul

-----Original Message-----
From: Roy Marples [mailto:roy@xxxxxxxxxxxx] 
Sent: Friday, July 03, 2015 1:32 PM
To: Walrath, Paul
Cc: dhcpcd-discuss@xxxxxxxxxxxx
Subject: Re: [dhcpcd-discuss] RE: DHCP Option 81 Client FQDN and new_fqdn

Hi Paul

On Thursday 02 July 2015 20:20:09 Walrath, Paul wrote:
> I tried dhcpd with "ddns-update_style interim" but it makes no difference. 
> The encoding of the fqdn returned by dhcpd seems to depend on the
> fqdn.encoding setting and the default value is ASCII.  My dhcpd is not new
> enough to support "ddns-updat-style standard" so I could not make that test
> right now (4.3 and newer is needed).

ISC dhcpd 4.3.0 works fine for me with this:

# We don't do DNS updates
ddns-updates off;
# But but do enforce RFC compliant FQDN transactions
option fqdn.encoded true;

host uberpc {
        hardware ethernet XX:XX:XX:XX:XX;
        option host-name "uberpc";
        option fqdn.fqdn "uberpc.marples.name";
}

Here is the output:
new_fqdn=uberpc.marples.name
new_fqdn_flags=E
new_fqdn_rcode1=0
new_fqdn_rcode2=0


> 
> It would be good if dhcpcd could support checking the E flag and accepting
> ASCII if E is 0 since ISC dhcpd seems to be a DHCP server that is in common
> use. 

It would be better if dhcp servers behaved in a RFC way :)
ISC dhcpd can be made to work, the current dhcpcd works so I see no reason to 
change anything right now.

>  I don't know if all administrators configure it to use RFC 1035
> encoded fqdn.  I also don't know how the DHCP servers in Windows Server
> 2008 and Windows Server 2012 behave.

Well, do they really care? From dhcpcd's perspective, the FQDN is only of any 
use for two things:
1) Setting the hostname of the client
2) Setting the domainname of the client

Both of which can be set already by options 12 (host_name) and 119 
(domain_search). It has been a long standing custom to abuse the host_name 
field to also include the FQDN instead of just the hostname.
And AFAIK windows does not set the hostname or DNS search from this option.

In DHCPv4, the FQDN option is primarily for setting DDNS, ie the hostname is 
already known.

Of course this is different in DHCPv6 where the FQDN option is the ONLY means 
of getting the hostname. However, this RFC has never had ASCII encoding in any 
draft, so to support DHCPv6, FQDN encoding is *required*.

But back into the topic at hand. If you want dhcpcd to support the *default* 
ISC dhcpd encoding, ie the deprecated ASCII then you can re-define the FQDN 
option in dhcpcd.conf to support this at the cost of working with RFC 
compliant servers.

Roy