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