Subject: Re: [dhcwg] Use of FQDN vs IP address

From: Stig Venaas <[email-masked]>
Date: Wed, 07 Jun 2006 19:13:02 +0200

MORAND Lionel RD-CORE-ISS wrote:
> During the dhc WG session, there was a couple of discussions about the
> use of FQDNs in dhcp options to provide information to a dhcp client.
> We can all agree on the fact that using IP@ instead of FQDN makes life
> easier. However, if we can recommend to use IP@, should we forbid
> someone to use FQDN if possible?

Even if the protocol only supports IP, the DHCP server or some 
configuration tool could do a DNS lookup.
> 
> I'm not an expert on dhcp or dns but I think that this kind of choice
> depends on how you want to configure your network. And if someone sees
> some advantages to rely on DNS administration instead of dhcp
> configuration when possible, is there any dhcp implementaton issue to
> use FQDN based options, except maybe concerns about the total length of
> the dhcp messages?

The length is the big reason, I think we need pay more attention to 
this. Using only IP rather than having suboptions for IP and FQDN also 
simplifies the option usage. Having both means that the clients need to 
be able to handle both.
> 
> For the dhc-paa-option draft in particular, I repeat that there is no
> reason to mandate one or the other method from a pana specification
> standpoint. The requirement is just to be able to use DHCP to locate
> PANA agent, whatever the way to finally get the agent's IP@ (IP@
> retrieved from the DHCP or using DNS resolution). After it's a matter of
> network configuration.

So I suggest we only use IP here. In general we should use only IP 
unless there are specific reasons for using FQDN. At least that's my view.

Stig

> 
> BR,
> 
> Lionel
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 07 Jun 2006 11:12:20 -0700

> unless there are specific reasons for using FQDN. At least that's my 
Stig has summarized this nicely.   From a usability standpoint, using 
FQDNs is nice, but you can do that in the server.   One other issue to 
think about is that if you supported FQDNs in options, sometimes you 
would return an FQDN in an option where only one IP address was 
appropriate.   What if the FQDN's A record contained more than one IP 
address?   It's possible to specify an answer, but is it a good answer?

So from an operational standpoint, I think it really is better to do the 
translation from name to IP address in the DHCP server.   The case I've 
described is really a configuration error; a DHCP server can report the 
configuration error to someone who has the power to fix it, whereas a 
DHCP client really cannot.

---

From: Andre Kostur <[email-masked]>
Date: Wed, 07 Jun 2006 12:22:25 -0700

> address?   It's possible to specify an answer, but is it a good answer?

Same as any other DNS client that gets multiple reponses in an A record 
to a query.  And if the server is resolving the FQDN, what does it send 
back if the FQDN happens to be unresolvable at the time of address 
allocation?  And would the server have to re-resolve the FQDN to IP 
every time it wants to send that option to a client?  After all, that 
DNS record may have changed, or the DNS server may be reordering a set 
of A records on each query.

>
> So from an operational standpoint, I think it really is better to do 
> the translation from name to IP address in the DHCP server.   The case 
> I've described is really a configuration error; a DHCP server can 
> report the configuration error to someone who has the power to fix it, 
> whereas a DHCP client really cannot.

I guess to provide a view from the other side, by providing FQDNs 
instead of IPs in options, you could be offloading certain 
load-balancing decisions onto the DNS infrastructure.  That FQDN may be 
queried each time the client needs to use that option data, instead of 
being set in stone at the time of address allocation.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 07 Jun 2006 12:49:46 -0700

Andre Kostur wrote:
> Same as any other DNS client that gets multiple reponses in an A 
> record to a query.  And if the server is resolving the FQDN, what does 
> it send back if the FQDN happens to be unresolvable at the time of 
> address allocation?  And would the server have to re-resolve the FQDN 
> to IP every time it wants to send that option to a client?  After all, 
> that DNS record may have changed, or the DNS server may be reordering 
> a set of A records on each query.
The DHCP server is just another user of the DNS.   I would expect that 
it either has a built-in DNS cache (really, this is needlessly 
complicated) or just does the DNS lookup every time it answers a DHCP 
query.   So if you are doing load balancing with DNS, it will give a 
different answer every time, for that FQDN, just as the client would.   
The client is going to do the same lookup the server is going to do, 
most likely at the same time, so except in exceptional cases you're 
going to get exactly the same behavior whether you do the lookup on the 
client or the server.

It's possible to posit a case where the client would cache the FQDN and 
do a lookup on it more frequently than the lease renewal time, but I 
think this is likely to be the exception rather than the rule.   
Generally speaking, the client is going to get an FQDN during lease 
acquisition or renewal, look it up then, and hand the result to an 
application, or else start an application with the name, and the 
application is going to do the lookup once and cache the IP address.   I 
think your position is that this isn't how it should work, and you may 
be right, but generally this is how it does work, and for the kinds of 
things we're configuring with DHCP, I think that it's okay that it works 
this way.\

 From the perspective of error handling, it's definitely better to do 
the lookup on the server, because the error is on the part of the 
administrator, not the user.   If an FQDN is entered incorrectly, or if 
it becomes unusable due to a DNS change that isn't reflected in the DHCP 
server's configuration, the person who needs to know is the DHCP server 
administrator, not the user of the computer with the DHCP client.   So 
doing the lookup on the server ensures that the error message will 
appear in the correct log - the DHCP server log.   Doing the lookup on 
the client means that the error will never be reflected in the DHCP 
server log - you will have to diagnose the problem based on a possibly 
obscure failure on a client machine, which may go unreported for some 
time, if the client is able to limp along without the information.

> load-balancing decisions onto the DNS infrastructure.  That FQDN may 
> be queried each time the client needs to use that option data, instead 
> of being set in stone at the time of address allocation.

Ideally, the client has an opportunity to refresh the data each time it 
renews its lease.   I can see where this objection would be significant 
in an environment where you're using really long leases, or where the 
client is broken and doesn't refresh data that changes, but generally 
speaking network administrators seem to prefer short leases, even when I 
personally think longer leases would make more sense, so I don't think 
this is a practical concern.

And, of course, there's the fact that having a choice between FQDN and 
IP address creates extra work for both the client and server 
implementors, and creates possible interoperability problems for a 
poorly implemented client, that there's no way for the client to specify 
which it wants, and that DHCP packet space is at a premium, and FQDNs 
are longer than IP addresses.   So although there are reasonably good 
theoretical arguments for why it's useful to send FQDNs to clients, I 
think they really are outweighed by the practical concerns.

If we were to go to a model where we could send either an FQDN or an IP 
address, I would argue that the complexity that's been added to various 
DHCPv4 options that do this is a mistake - you should just have an 
option that returns *only* the IP address, and another option that 
returns *only* the FQDN.   This way the client can specify the one it 
wants, and doesn't have to implement both.

Of course, that opens the can of worms that now it's an error for the 
server to be configured with only one and not the other, but I don't 
mind that as much - it's relatively simple to define a relationship of 
that type in the DHCP server, and you only have to get it working on the 
server, not on the client.

It also means that you can be strategic about which options you do it 
for.   E.g., it never makes sense to send an FQDN for the DNS server 
addresses, because you need the DNS server addresses to look up an 
FQDN.   It's possible that there might be some options for which sending 
the FQDN is a particularly good idea; in this case, you define the 
option, and in cases where it's not so important, you don't bother, 
because it doesn't add value.