On Oct 8, 2013, at 4:30 PM, Cullen Jennings (fluffy)
<fluffy(_at_)cisco(_dot_)com> wrote:
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.
This use case is a good example of when to use an FQDN format for a DHCP
option. However, it's not a great example of when to use a DHCP
option—configuring SIP servers with DHCP is generally a bad idea, because if
your device is connected to a new network, it will blindly take the SIP server
IP address or FQDN information from the DHCP server and use it, and that SIP
server might well perform an MitM attack or the like.
So it's only in the very restricted use case of a Cisco IP phone permanently
installed on a desktop and connected to a trusted network that (a) configuring
SIP via DHCP makes sense, and (b) using the FQDN is a good idea. Of course
it's possible that my limited understanding of how SIP works is preventing me
from seeing why it's safe to configure SIP service using DHCP, but I'm assuming
that that's not the case in this argument; please feel free to correct me.
We've actually been having this same conversation on the iesg mailing list, and
I asserted that SIP was something you ought not to configure with DHCP; your
use case is the one case where it sort of makes sense. Can you think of
similar use cases where it actually makes sense to configure these parameters
via DHCP?
Possibly the right solution is to update the document to talk about this sort
of restricted use case as one where FQDNs actually do make sense. The
document certainly doesn't say you _can't_ use FQDNs, but we see people wanting
to use them a lot in cases where they really don't make sense, hence the
advice. Historically I don't think we bothered to make this distinction when
defining new DHCP options, but it seems like a useful distinction to make.