iOS 14 (Apple) DNS bits
mel at beckman.org
Thu Sep 24 14:29:14 UTC 2020
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.”
"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
I don’t know anything about your #2 question.
> 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