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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 7 Jun 2006 15:48:04 -0400

I do think one of the key criteria is when is the client likely to use
the information (address or name). If it part of the "start-up"
processing (ie, used shortly after received and not likely to be used
again), use of IP address is probably best. If it is something that the
client will use or may not use for a long time, an FQDN is preferred.

The other consideration is whether adding a DNS resolver to the target
client(s) is a burden. This day and age that would hopefully not be
common?

And, finally, is the deployment model for clients such that a DNS server
is unlikely to exist. That too is hopefully not very common?

But, we generally plan for the worst and that is why we often end up
being able to send both.

- Bernie

> -----Original Message-----
> From: Andre Kostur [mailto:[email-masked]] 
> Sent: Wednesday, June 07, 2006 3:22 PM
> To: Ted Lemon
> Cc: [email-masked]; MORAND Lionel RD-CORE-ISS; Stig Venaas
> Subject: Re: [dhcwg] Use of FQDN vs IP address
> 
> Ted Lemon wrote:
> > Stig Venaas wrote:
> >> 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 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?
> 
> 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