(Dear OPs ADs, please read … )
I disagree with the advice in section 8. Cisco IP phones have been deployed
with DHCP options that use FQDN and with options that use IP addresses. For
this type of use case the FQDM turned out to be much better from an operational
and administration point of view. IT departments are used to making sure that
changes of IP addresses on servers are well coordinated with changes to the DNS
- they are good at doing that and that and have good tools for it. Conversely,
they are not used to coordinating server changes with DHCP changes and do not
have good tools for that. Part of why you can't do this with DHCP is that
clients are written so that when an IP address fails to work for an application
connection, the application re does the DNS and gets the new address (assuming
TTL had been moved down during the move). Applications can not tell the OS to
redo DHCP when they fail an application level connection.
For nearly every case in the real world, the power and RTT and reliability
issues are simply not relevant - regardless of which way you do it, the
application is unlikely to work if DNS is down, the extra RTT make no speed
difference the user can percieve and the power difference over a day of use of
the application is so small it is not measurable.
FQDN allow usage of things like DNS SRV for load balancing, happy eye balls for
v6 transition, and make it easier to get things to geographically close
servers.
I don't think it should come a a shock to anyone that the level of indirection
that FQDNs provides turns out to be a really useful tool. Lets use that
indirection tool where appropriate.
Related to this, the advice in section 12 seems a bit off to me. I understand
the issues - but keep in mind that many modern applications (browsers and SIP
phones for example) do the DNS inside the application instead of using the OS
resolvers. Part of the reason for this is asynchronous resolution but part of
it is also control of which interface is used for DNS and if multiple
interfaces are used, being able to keep the applications traffic on the the
appropriate interface for the DNS server that returned the address. So while I
agree that
"Existing nodes cannot be assumed to systematically segregate
configuration information on the basis of its source;"
Equally true is you can't assume the converse of that. So I think the statement
that
As a consequence, DNS
resolution done by the DHCP server is more likely to behave
predictably than DNS resolution done on a multi-interface or multi-
homed client.
Is just plain wrong. I think it would be more accurate to say in these cases
the results are not always predictable. The issue is the DHCP server may get an
DNS answer that contains and server that can not even be reached by the DHCP
client.
As a general rule of thumb, using FQDN in the configuration of a DHCP server is
a really bad idea because IT admins assume that if they change the the DNS
information, the clients will get the new information. But they don't.
Cullen
On Sep 19, 2013, at 3:54 PM, The IESG <iesg-secretary(_at_)ietf(_dot_)org>
wrote:
The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Guidelines for Creating New DHCPv6 Options'
<draft-ietf-dhc-option-guidelines-14.txt> as Best Current Practice
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2013-10-03. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This document provides guidance to prospective DHCPv6 Option
developers to help them creating option formats that are easily
adoptable by existing DHCPv6 software. This document updates
RFC3315.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/ballot/
No IPR declarations have been submitted directly on this I-D.