pusateri> Another point I remember most clearly is that DHCP has fallen pusateri> out of favor for communicating all but the most minimal pusateri> network bootstrap configuration information. There was general pusateri> agreement in the room that you only should use DHCP in IPv4 pusateri> for address/router info and then use trusted sources for pusateri> everything else. In IPv6, SLAAC generally provides this.
That may be the consensus at the IETF but it's not even close the consensus with ISPs, nor large enterprise. That seems to cover most of the eyeball/consumer... DHCP is still how much of the world gets connected and that hasn't changed in decades. pusateri> One more point (from the Android crowd) was that they are pusateri> going to try to connect to the DNS server's IP address using pusateri> port 853 using DoT at the same time they are trying to resolve pusateri> names over port 53 with UDP. If they're able to make a DoT pusateri> connection, they'll use it. This doesn't provide for a way pusateri> to have an ADN to verify the certificate but a PTR query can pusateri> give you a name to do certificate validation and/or DANE pusateri> validation. So they seemed to be making the point that no DHCP pusateri> extensions were necessary. The google/android crowd's bias against DHCP and DHCPv6 is well known and is why android is having trouble penetrating said enterprise market. Getting DOH via DHCP is the same argument as TOFU and the IETF has used TOFU. DHCP is how hotspots, ISPs and enterprise work. Users able to understand security risks and who read drafts from the IETF already know how to deal with this and won't need a DHCP option. Much of the world does need and want configure hosts/devices via DHCP. Saying this is all broken and that we need to protect the world from themselves by not having a DHCP option simply means that vendors will have a slew of non-standard ways of doing it and we've helped noone. Let's just give the option, document the security holes and risks and at least offer much of the world a standard way of doing this if they so choose. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
