On Thu, Jun 28, 2018 at 1:21 AM Benjamin Francis <bfran...@mozilla.com> wrote: > On 25 June 2018 at 16:50, Brannon Dorsey <bran...@brannondorsey.com> wrote: > > > As far as I see it, a > > domain name should never be allowed to respond with a private IP address > > moments after it first responded with a public IP address. > > > > If I understand correctly, this is exactly what we plan to do on our Mozilla > IoT gateway <https://iot.mozilla.org/gateway/> project.
That particular fix won't affect you (if you do indeed plan to use two names). > We're currently in the process of implementing this, and we're not sure yet > whether it will work, but if it does this could be a use case that we > wouldn't want Firefox to block. (Daniel's comments about DNS-over-HTTPS are > a bit concerning). If we ever have code to support .local in the browser, then those will need to avoid using the DoH stack for resolving those names. mDNS is a completely/mostly different stack, so that's to be expected. Similar concerns apply to other special names like .home.arpa and .onion. So I wouldn't worry about that aspect of this. Daniel's point is that DoH has implications for people who have a local DNS server that produces different or extra results for local services. This is common in enterprise where the enterprise DNS server provides results for local services that aren't addressable, or ideally even knowable, from outside that network (i.e., other DNS servers would return NXDOMAIN). That this is difficult to distinguish from a rebinding attack is something that the techniques Brannon describes might help with, but getting that right is tricky and maybe expensive. Ultimately, the answer is to use HTTPS throughout, but we're all aware of the difficulty of doing that in some environments. (Enterprise should be easy, but we've seen some reluctance there.) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
