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 <[email protected]> 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 ? >
