On Oct 8, 2013, at 3:38 PM, Ted Lemon <Ted(_dot_)Lemon(_at_)nominum(_dot_)com>
wrote:
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.
Nah, it's not quite like that - Long story how that it but the security
mechanism make sure you authenticate both ends to stop that.
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.
Help educate me on this a bit - I don't see all the things that get requested
of DHCP. What are some examples of things where people are request FQDN where
IP would be better. I think having some real examples that have come up would
make it easier to see what advice is needed.