iOS 14 (Apple) DNS bits

Mel Beckman mel at beckman.org
Thu Sep 24 14:36:11 UTC 2020


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 at 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 at 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 ?
>> 
> 



More information about the NANOG mailing list