Chris's Wiki :: blog/web/FirefoxDNSOverHTTPSAndUs Commentshttps://utcc.utoronto.ca/~cks/space/blog/web/FirefoxDNSOverHTTPSAndUs?atomcommentsDWiki2019-09-19T20:48:38ZRecent comments in Chris's Wiki :: blog/web/FirefoxDNSOverHTTPSAndUs.By David Magda on /blog/web/FirefoxDNSOverHTTPSAndUstag:CSpace:blog/web/FirefoxDNSOverHTTPSAndUs:fec3cc119799016c10893f4f0ba60c740b385a83David Magdahttp://www.magda.ca/<div class="wikitext"><p>There is a draft available for bootstrapping/discovering DoT and DoH servers:</p>
<ul><li><a href="https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server">https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server</a></li>
</ul>
<p>In the short term I think that OSes will simply take what's given from DHCP or in resolv.conf(5) and simply try to connect securely.</p>
</div>2019-09-19T20:48:38ZBy Chris Siebenmann on /blog/web/FirefoxDNSOverHTTPSAndUstag:CSpace:blog/web/FirefoxDNSOverHTTPSAndUs:c8850f21fa3143a7950d0f45221077518b1be6efChris Siebenmann<div class="wikitext"><p>The problem I see with supporting DoH and/or DoT on our internal
resolvers is that as far as I know, there's no way to advertise
support for it in a way that lets it be automatically configured
and de-configured as people move between networks. It's routine
for people here to migrate machines between our networks and other
ones, so that has to work seamlessly. If it requires manual work
to switch to our DoH server and then switch away again, approximately
no one will do it and we might as well not implement it.</p>
<p>As far as DNSSEC goes, we are very unlikely to enable it on our internal
resolvers after my experiences with it on my own machines. The very last
thing we want is for our users to run into mysteriously unresolvable
DNS names. Breaking DNSSEC for the canary domain is not a problem.</p>
</div>2019-09-19T20:17:55ZBy David Magda on /blog/web/FirefoxDNSOverHTTPSAndUstag:CSpace:blog/web/FirefoxDNSOverHTTPSAndUs:24f7fefd0c16d05c15362c054d689e57e9f3e957David Magdahttp://www.magda.ca/<div class="wikitext"><p>With regards to blocking "use-application-dns.net", note that this will break DNSSEC.</p>
<p>The normal path for a DNS lookup is "." -> <em>net</em> -> <em>use-application-dns</em>. At every "->" the NS records are sent over, and these are signed.</p>
<p>So when the "." replies back with the NS records on where to talk to "<em>net</em>", and they also have an RRSIG. And when "net" send over the NS records on how to talk to "<em>use-application-dns</em>", they are also signed—but those are now taken over and an NXDOMAIN is faked. But there is no signature on that response (or more properly there is no NSEC(3)).</p>
<p>So one can either have proper DNSSEC validation <em>or</em> block DoH, but not both.</p>
<p>What Mozilla should have probably done is use a host record; something like (say) <em>use.application-dns.ne</em>t. This way you're not breaking the DNSSEC response of going from <em>net</em> to <em>application-dns</em>. Further, there could have been things like "<em>use-doh</em>" and "<em>use-dot</em>" so that DNS operators could signal the use (or not) of teach of those protocols.</p>
<p>It would have been nice if Mozilla talk to the DNS folks (e.g., DNS-OARC), but there is no evidence that they did AFAICT.</p>
</div>2019-09-19T11:01:18ZBy David Magda on /blog/web/FirefoxDNSOverHTTPSAndUstag:CSpace:blog/web/FirefoxDNSOverHTTPSAndUs:5e6f41270b1b07f4732b0329c58b26a60767c599David Magdahttp://www.magda.ca/<div class="wikitext"><p>IMHO I think it is a good idea to start offering DoH and DoT on internal recursive servers because the more places that have it, the more likely that software makers and OSes will will point to it. One claimed problem that is causing Mozilla to override OS defaults is that they say no one is doing anything to help move encrypted DNS forward, so they've deigned it necessary to take matters into their own hands.</p>
<p>There are proxies (packages available) that all one to add the functionality without changing / reconfiguring software:</p>
<ul><li><a href="https://dnsdist.org">https://dnsdist.org</a></li>
</ul>
<p>A good talk and a panel discussion on DNS over HTTPS considerations:</p>
<ul><li><a href="https://www.youtube.com/watch?v=pjin3nv8jAo">https://www.youtube.com/watch?v=pjin3nv8jAo</a></li>
<li><a href="https://www.youtube.com/watch?v=FqVX8WplEPg">https://www.youtube.com/watch?v=FqVX8WplEPg</a></li>
</ul>
</div>2019-09-19T10:51:16Z