Re: iOS 14 (Apple) DNS bits

[Mel Beckman <mel () beckman org>]

Vom,

I’m an Apple developer, and I remembered a session from WWDC about this. Here’s the link, open to public view:

https://developer.apple.com/videos/play/wwdc2020/10047

I haven’t watched the talk, but it dives pretty deeply into the mechanics of Apple’s encrypted DNS mechanics, so it may 
answer your question. Let us know what you find out!

 -mel


> On Sep 24, 2020, at 7:29 AM, Mel Beckman <mel () beckman org> wrote:
>
> Vom,
>
> Because the HTTPS RR is designed to improve performance for clients that need to resolve many resources to access a 
> given domain, I think the theory is that the total Internet traffic will be reduced. From the draft RFC:
>
> "By providing more information to the client before it
>   attempts to establish a connection, these records offer potential
>   benefits to both performance and privacy.”
>
> and 
>
> "The SVCB and HTTPS RRs provide clients with complete instructions for
>   access to an origin.  This information enables improved performance
>   and privacy by avoiding transient connections to a sub-optimal
>   default server, negotiating a preferred protocol, and providing
>   relevant public keys.
>
> For example, when clients need to make a connection to fetch
>   resources associated with an HTTPS URI, they currently resolve only A
>   and/or AAAA records for the origin hostname.  This is adequate for
>   services that use basic HTTPS (fixed port, no QUIC, no [ECH]).  Going
>   beyond basic HTTPS confers privacy, performance, and operational
>   advantages, but it requires the client to learn additional
>   information, and it is highly desirable to minimize the number of
>   round-trips and lookups required to learn this additional
>   information."
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/00/?include_text=1
>
> I don’t know anything about your #2 question.
>
> -mel
>
> > On Sep 23, 2020, at 4:46 PM, vom513 <vom513 () gmail com> wrote:
> >
> > *** Hopefully this is on-topic enough for the list…
> >
> > Since iOS 14 has been released recently, folks have observed the changes to the network and DNS mechanics.  I wanted 
> > to get some feedback from folks here on this.  I have a small observation, and a slightly larger question:
> >
> > Observation: iOS 14 now seems to send 3 queries (up from 2) for every “socket” connection to a name.  Whereas we’ve 
> > had A + AAAA for quite some time in many OS’es - on iOS 14 we now have A + AAAA + HTTPS (type 65).  I doubt this 
> > will be any burden on anyone, but I just wanted to point out that now many Apple devices will have 1.5x the previous 
> > query traffic coming from them.  I also wonder who is actually using HTTPS RR’s in their zones - I would assume 
> > Apple would be (soon at least) for their cloud and infra. services.  Alas, I don’t see anything in Wireshark, nor do 
> > I have a command line utility that understands the RRtype to test by hand...
> >
> > Question: iOS 14 now flags networks that it believes are blocking encrypted DNS.  It puts a warning in Settings for 
> > the wifi.  For my home network this is expected.  I redirect 53 to my own firewall - as well as use some RPZ feeds - 
> > one of which aims to block/poison DOH/DOT attempts.  My question is how is it making this determination ?  I log the 
> > iptables redirects, and I also log RPZ hits out of bind.  I don’t see anything in my logs where my phone has tripped 
> > these.  I don’t currently block 853/tcp (but I likely will) - so it shouldn’t be making it’s determination off of 
> > that…  Does anyone *really* know how iOS 14 is testing this ?