On Oct 8, 2013, at 3:38 PM, Ted Lemon <ted.le...@nominum.com> wrote:
> On Oct 8, 2013, at 4:30 PM, Cullen Jennings (fluffy) <flu...@cisco.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.
