*** 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 ?
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.
I’m an Apple developer, and I remembered a session from WWDC about this. Here’s the link, open to public view:
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!
vom513> Observation: iOS 14 now seems to send 3 queries (up from 2) for
vom513> every socket connection to a name. Whereas we've had A
vom513> + AAAA for quite some time in many OSes - on iOS 14 we now
vom513> have A + AAAA + HTTPS (type 65).
vom513> Question: iOS 14 now flags networks that it believes are
vom513> blocking encrypted DNS. It puts a warning in Settings for the
Apple has made a number of unilateral decisions about how their phones
should work (in search of some definition of privacy) that are likely to
cause headaches for enterprise and others using something other than
apple blessed tech to secure their users. The mac addr randomization is
going to be another headache for IT.
From an apple developer on another list, official docs from apple and
some other things to read.
"Encrypted resolvers designated by domain owners" based on;