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 <m...@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 <vom...@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 ? >> >