Hi Jaques, et al. Tom Pusateri can probably say something on his now expired https://www.ietf.org/archive/id/draft-pusateri-dhc-dns-driu-00.txt.
The git commentary at https://github.com/pusateri/draft-tpwt-dhc-dns-discovery says: Ted Lemon made a good argument that DHCP should only be used for boostrapping initial network parameters and not for full fledged configuration of all network parameters. There was enough consensus that we feel that moving forward with this work would go against the wishes of the IETF community. There still is a need for configuring the ADN in a campus environment where all of the servers are controlled by the network administrator but a different proposal will need to be invented. I wonder if ALL (including the original) DNS discovery options) fall into that area or not, and if that possibly changed over time, but likely there was a debate that already explored the topic in dhc BR, Normen -----Ursprüngliche Nachricht----- Von: DNSOP [mailto:dnsop-boun...@ietf.org] Im Auftrag von John Levine Gesendet: Donnerstag, 21. März 2019 23:50 An: dnsop@ietf.org Cc: jacques.lat...@cira.ca Betreff: Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator In article <428d5ff2b5704cdf956a5919e330e...@cira.ca> you write: >Plus! >Is anyone looking at adding DoH and DoT servers as part of DHCP/SLAAC? I believe that for DoT, the idea is that the client just probes the DNS server address on port 853 and uses it if it gets an answer. I suppose you could try the same thing on port 443 but that seems riskier. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
