There already is a SRV service name reservation for both http and www-http, with Tim Berners-Lee as the contact name. Fun fact: using DNS address records ("A" or "AAAA") for endpoint name resolution in HTTP is a convention; it is not required in the standard or in any of the normative references. Web services do not own the address record and should never have been using it in the first place. Nonetheless they continue squatting addresses in a de facto assertion of unwarranted privilege, and every other use of the DNS has to steer carefully around.
When SRV is discussed e.g. on the HTTP/2 list, the objections of resolution speed and number of round-trips are usually raised. But SRV records do not intrinsically require an additional lookup or round trip. Unoptimised zone configurations (especially those that slice at _tcp, which occurs at some Microsoft shops) may fare less well, but that is true of all DNS configuration. Services that care about resolution speed already optimise their DNS as necessary, and they would for SRV as well if it were mandated.
In practice, the reasons for non-adoption are, mundanely, simply a matter of inertia, combined with a lack of motivation: the browser vendors who in practice write the HTTP standard do not care to change and have no external force that will push them off overloading the address record.
I think you allude to this with your comments on optimization, but DNS resolvers will generally, just like CNAMEs (which nearly all DNS names begin with these days) will return additional records to reduce any round-trips for getting the record at the end of the SRV.
SRV records are great, and would reduce antiquated reliance on ports for specific services. This would be helpful for HTTP, especially with things like TLS, where certs cold be returned without SNI being used.
There's a couple things about modern DNS that just doesn't make sense. There's probably a good explanation buried somewhere in a mailing list or three.
The other one that still astounds me is that DV certificates rely entirely on DNS control for validation prior to issuance, and browsers trust that system, but there still exists no way for me to cut out the middle man and put my own domain-specific CA Cert in DNS directly.
CA can expect that its connection to your DNS server is reliable and not tampered. So their check is reliable. User can't expect that his DNS is reliable. So HTTPS must work with those conditions: when user's DNS server might be controlled by bad actor. DNS security is supposed to solve that, but it's not widely used AFAIK.
CAs should be able to afford to make the requests from multiple sources and compare the results.
Alternatively they can use secondary challenge-response auth which depends on some credentials being deployed to your server. Mitm-ing it wouldn't give the attacker anything interesting in that case.
CAs bet the farm on the idea that doing two separate DNS queries instead of one will keep them safe. This is a ridiculous assumption. Sophisticated attackers can often successfully attack multiple targets at once.
They can use a secondary challenge, but this being optional completely defeats the purpose. A MITM attack will allow an attacker to pretend to be the target during creation of a new cert, tricking a random CA into giving them a valid cert. You do not need to use the CA that the site owners use, so their use of an extra challenge is irrelevant.
Lots of assumptions which are ridiculous in theory are pretty good in practice. Having to MITM multiple servers just to get a cert (which will most likely be detected on the CT logs) is orders of magnitudes harder than just clicking a button on Firesheep or adding a few lines of code to a router malware.
Credit cards literally rely on every single merchant not leaking their info, yet as flawed as that is, there's no great pressure to replace them.
Credit cards have manual charge back as a fallback with human driven process. The equivalent fallback for certificates does not exist. You can only revoke.
They're not just doing two queries. Anybody on HN with a strong opinion about DNS and CAs and a bare minimum of programming ability could rig up a fairly sophisticated DNS validation service in under a week. Just think about how you would do it, given a pretty reasonable budget.
I'm not thinking about a sophisticated service. I'm thinking about the weakest link in the chain that I could possibly exploit to generate fake certs. Pick the least secure CA with the least secure validation method and you now have valid fake certs.
Even if DNS by itself was secure enough to validate, this is a single factor and there are many ways to exploit a single factor. Why a secondary mechanism/factor isn't required for critical infrastructure makes no sense.
I didn't say they do that. Just that it's one of the ways to avoid a single, targeted mitm. There are many other approaches and cab baseline requirements (3.2.2.4.) are not very specific on what's specifically expected.
To test this, I just now acquired a Let's Encrypt cert using `certbot certonly` while tailing the logs. I received only a single request, from 64.78.149.164. The cert was issued. They did not appear to take a second measurement.
HTTP challenges do not offer meaningfully increased resistance to MitM over DNS challenges, and require measurements from multiple vantage points just as much as DNS challenges do.
No, but it is a good example that CAs don't require DNS changes to assign a cert. One just needs to MITM an HTTP connection for a single request. (Or, depending on the CA, control one of the following email addresses: "admin@example.com, administrator@example.com, postmaster@example.com, webmaster@example.com, hostmaster@example.com")
Local network tampering (ARP etc) at registrar end, routing attacks such as BGP hijack, below-IP attacks in transit (eg MPLS hijack, malicious transit router, QUANTUM INSERT, other fiber tap approaches, ...) DNS implementation bugs in UDP spoofing countermeasures, local network tampering at domain holder end, social engineering or extortion against transit or stakeholder sysadmins, etc. It's a long list of possibilities.
> CA can expect that its connection to your DNS server is reliable and not tampered
Why? It goes over infrastructure that you nor they control.
It might be worth illustrating what happens here, as it's not immediately clear from common DNS settings or common commands. First, the client asks their local DNS server, the one you get via DHCP or configure (for example 8.8.8.8 which is by definition already outside your network, but for argument's sake let's assume that they're smarter than that and they pick one inside their own network). Let's say this one doesn't have it in cache, so then it has to go out and ask the TLD (let's assume it has the TLD cached).
The TLD, for example `.com`, will say "the name servers for your.example.com can be found at ns.your.example.com" and it gives the IP addresses for those. Now the local resolver at the CA has to go and ask there for your domain. In this final step, if nowhere else, it will have to leave any sort of trusted network and venture into whatever place the user's servers are at. This could be anywhere in the world, with all sorts of intermediate networks.
> Why? It goes over infrastructure that you nor they control.
They're able to use many secret locations to perform the query.
There is a theory that it is very unlikely an attacker can detect and get leverage over every network between every one of those secret locations for an indeterminate amount of time, without being discovered.
What you describe is a possible technique that CAs could use, so let's stipulate that some CA does this. We certainly can't conclude that all or even many CAs do this.
One very simple reason is that they tell their service provider that "No" they don't want the brilliant new anti-whatever service it's offering by tampering with DNS queries.
Alas "No" isn't an option for that public WiFi access point you're using, or most mobile service, or your mom's Internet, the average corporate workplace, and so on. So even though this is hardly foolproof it makes a huge difference.
Attacking server infrastructure is order of magnitude harder than attacking user. Those who can do this attack, can just ask their CEO to issue them a certificate via subpoena.
Yet both the user and DV certificate issuers rely on the same DNS that you consider unreliable. So you seem to dismiss DV certificates altogether but your comment seems to imply that you only want to dismiss certificates as DNS records. There's something very inconsistent about your comment.
That inconsistency is that users are generally on much less trustworthy networks and DNS right now is rarely authenticated (DNSSEC is not wide spread and even then most clients don’t authenticate it)
While not perfect it’s generally quite true for the majority case.
Actually, a large number of hosts are behind a DNSSEC validating resolver. And that's because the use of Google's public resolvers is extremely wide spread.
I don't know if they document it somewhere, but it is essentially trivial for letsencrypt to use a DNSSEC validating resolver.
So that means that if you care about DV security, you enable DNSSEC.
DNSSEC doesn't protect the connection between a browser and Google's DNS server. Attackers can simply edit the responses generated by Google's DNS. Moreover, virtually nobody signs their domains with DNSSEC (why would they? It's all downside.) So CA's can't require DNSSEC, or depend on it being there. You can enable it, but it's pointless, because the attack against DV that DNSSEC is meant to prevent can be launched whether or not you enable it. DNSSEC has essentially no practical impact on DV.
Although CAs don't (not can't, neither the CAB rules nor any major trust store programme requires you allow names without) require DNSSEC they absolutely can insist on figuring out whether a name is protected by DNSSEC and enforce that if so, since the root is signed and DNSSEC has a closed world assumption (we can get a definitive signed answer which says "No" this domain isn't signed).
It's interesting, even though the $0 price isn't intended to be the main draw a large number of domains with broken DNS fixed it to get Let's Encrypt working rather than pay a CA that doesn't care...
But checking CAA with DNSSEC is mandatory (this caused much feather spitting)
So if you have DNSSEC you can deny all the CAs you don't trust. If a bad guy leaves the CAA record alone they can't get a cert. If they try to replace the CAA record or deny it exists they fail DNSSEC checks.
If your chosen CA agrees to only use a method that's actually secured you get an actual bona fide panacea, for the very affordable price of deploying DNSSEC and CAA, automating cert issuance and getting your DNS config right.
There's so much brokenness here that it's hard to know where to start rebutting this. I took an hour to game through this with some people who actually work on CA initial identity verification security; here's where I land:
* First, most CAs don't do DNSSEC today, or, if they do, do DNSSEC fail-open.
* Second, CA's can already do multi-perspective DNS lookup, which means that a practical attack to defeat CAA over standard DNS requires an on-path attacker. But if the attacker is on-path, most of the mechanisms CAs use to validate a domain fail, even if you use DNSSEC.
* Finally, there's already a replacement for all this stuff in progress: RDAP, a secure JSON API that allows data to be pulled directly from registrars. Every mainstream browser and every CA/B forum CA voted to add it to the BRs; it's going to be implemented. If you really believe that something like CAA is the future for DV certs, then it seems pretty obvious that RDAP is going to be the way that happens.
Whilst it's nice that RDAP is being worked on what you've got there is very much jam tomorrow. It takes a powerful imagination to see the CA/B vote to allow RDAP (when it becomes available, which may be never for many TLDs) and interpret it as a death blow to DNSSEC, but I admit you do have such an imagination.
Your first point argues from an alleged fact, not in evidence, that "most CAs" don't obey the Baseline Requirements in respect to their requirement to use DNSSEC to avoid an on-path attacker replacing or removing CAA records. Do you have such evidence? As I said, this requirement caused CAs to spit feathers, but that's also true of e.g. record keeping requirements and CAA checking itself. One of the unexpected side benefits of Let's Encrypt at scale is that arguments go like this:
Big CA: This requirement is crazy, we issue a vast number of Web PKI certs, and the requirement would cause us to do X for most of those certs, that's just not technically feasible, the requirement must be removed.
Let's Encrypt: We do X for every single cert we issue. Big CA the logs show you issuing only 4% as many certs as us, are there hundreds of times more than you don't log?
Big CA: Um, er, oh, we just realised our single-threaded PHP program might be a bottleneck, we're investigating upgrading to PHP4 to work around that.
But then your second point argues the reverse, that CAs "can" do multi-perspective, and so even though they mostly don't we should pretend they all do. Then it jumps from this backwards argument to claiming all of the Ten (well, nine now) Blessed Methods are vulnerable to an on-path attacker "even if you use DNSSEC", when in fact several are not.
Try it, write down the Ten Blessed Methods as they stand today (yes there are currently nine), then mark whether an on-path attacker succeeds against this method when DNSSEC is in place
3.2.2.4.3, 3.2.2.4.7 and 3.2.2.4.12 are unaffected by an on-path attacker. 3.2.2.4.3 is out-of-band, which I'm sure won't bother a nation state adversary like the NSA, but is otherwise pretty good, 3.2.2.4.7 is in DNS itself, and so protected by DNSSEC, and 3.2.2.4.12 is a simple database lookup, just one that's only possible if your CA is also your registry/ registrar.
I consider unreliable routers that deliver response from DNS to user, especially the last router. If that last router is controlled by attacker, he still can't break HTTPS.
I think he makes a fair point. Browser vendors may be trusting CAs to do more due diligence on their DNS lookups than they might expect browser users to even be able to provide.
I still think there's a better way, though. Surely it must be possible to do some consensus through WebRTC and end up with something that lets me run my own domain-specific CA, at least for DV certs.
Most of the things that are "curious" about DNS I think comes from its lack of a version.
DNS has no version, so it has no obvious way to extend itself by allowing for graceful upgrades. So you can't just change behavior and have clients support a particular version. Everything has to be backwards compatible with something written in 1984.
The only serious attempt at extending DNS died because the specs and DNS admins allowed the extension mechanism to be optional. Now, most networks break the extension, and the DNS just limps along because nobody is willing to implement a sane upgrade path.
And the middlebox brokenness is due to a lack of versioning. Virtually all middlebox brokenness is a result of a lack of versioning and poor upgrade paths - usually from people demanding backwards compatibility above all else.
I view it as more of a consequence of "fail closed" thinking than a lack of versioning. As we've seen recently with TLS [1], even protocols with explicit versioning suffer from middlebox brittleness.
> put my own domain-specific CA Cert in DNS directly.
Remember that this allows any of your government or people controlling the zone to transparently put the cert there too. (For potential problems see [0]).
With the CA system (that I personally also don't like) at least the certs are logged in Certificate Transparency logs so you see any potential attacks.
AFAICT, anyone who controls .com can add or replace a cert for ycombinator.com, but only visibly. If they do it, they show the change to the entire world at once, because .com is signed with dnssec. Right?
Your parent mentioned Certificate Transparency. Under CT all the public CAs log certificates they issue, and everybody can see the logs, programmatically (with cryptographic security) or via a log monitor like crt.sh
So yes, bad guys operating a TLD can trick a CA into issuing for a domain under theirs, but the CT logs would preserve evidence of this cert existing, and the CA is required to keep records of why it was confident to issue. Monitors would know about the cert in 24 hours (usually much less)
The idea behind the attack they're talking about is that the USG has de jure control over .COM's DNSSEC keys, and so they can in fact edit .COM transparently.
DNS is actually the least sketchy component in the DV story.
Until about a year ago the situation was that each CA could do anything they (without even peer review) thought seemed good.
Then we got the Ten Blessed Methods, a specific list of ways to verify that your subscriber really controls the names they want a cert for.
Most of the Blessed Methods involve DNS, but not all of them, some are relying on paper documents, some use WHOIS and out of band communications (e.g. Fax!). And of those which use DNS, many involve even less secure elements, email, plaintext HTTP, that sort of thing.
So there's still work to do, but we're headed in the right direction.
Having service location be at the TCP/IP level is a major contributor to the IPV4 crisis. We have 48 bit addresses, but 16 of those bIts are relatively unused.
Rather than solving the problem the pragmatically (and in a backwards compatible way), we're pushing a reinvention of the wheel (protocol).
IPv4 certainly has problems but I think they were solvable without bisecting the internet.
IPv4, don't get me wrong, I like much more than IPv6 for many reasons(128 bits? Overkill). There are more people on Earth than ipv4 addresses, you can't solve that problem without heavy NATing, which has its own drawbacks.
I disagree that 128 bits is overkill. Most networks are devided between 64bits for public routing, and 64bits for internal routing.
The network space is huge, but segmented. At each branch of the network, you reduce your addressable space significantly.
When you think of the future, and huge interconnected small devices, I don’t think 128 bits are going to seem excessive.
Remember, when they came up with 32bits for IPv4, they were not planning for a computer (or multiple!) in your pocket that was going to be network routable.
Because the minisec that Arthur C. Clarke had postulated in Imperial Earth in 1975 and the commlock that appeared in Space:1999 also in 1975 were both obviously fantastic nonsense. (-:
One can see from IEN28 in 1978 that early forms of 32-bit addressing, at the time comprising 1 octet network, 1 octet IMP, and 2 octets host, weren't even planned as extending beyond ARPANET.
To play devil's advocate, there are not enough raw materials on earth to produce close to the amount of necessary devices that would fill the ipv6 space.
I can be convinced that this large amount has other benefits, but not that this number of IPs was needed for futureproofing.
Well, there's a couple other considerations. For one thing, some devices may have multiple IPv6 addresses - perhaps even entire slices of it. For another, having additional bits to work with allows people more room to divide their subnets into future-proof chunks without risking ever running out of IPv6 space - something IPv4 could never really afford in the first place. What would be considered large chunks of IPv4 are a drop in the bucket in IPv6.
I think the main idea is that you want to have plenty of space both for growing horizontally and vertically, at least enough to where you can't even imagine exhausting it in either direction. Giving massive private and public address space without need for NATs effectively provides this.
Also, hey, who knows. There isn't enough raw materials on Earth, perhaps, but maybe there are enough raw materials in the universe. Who knows for sure if the Internet always be confined to just Earth.
Unless you get faster than light communication, the interplanetary protocols will require advanced collision handling which TCP does not provide anyway, and all kinds of "on-line" access will be impossible due to light lag.
It is needed for future proofing because the idea is not that every single IPv6 address is used.
To simplify routing, only a small fraction of the address space will be used.
At least that's how I understand it. Think of it like this - GPS coordinates are longer than post codes and less efficient for storing the location of people. But as a bonus finding someone's location using coordinates doesn't require a huge database of post codes.
Similarly, coordinates have a huge address space - every location on the planet, but we don't expect people to actually live at every location - in the ocean etc.
I think you missed my point, so I'll explain another way because I think it's important to make.
If you look at the TCP packet, bits 16-31 are constant for all HTTP traffic. Because they are a fixed value, they're wasted (non-unique). With the current system, we can only have 2,147,483,647 web servers.
Using SRV records, these bits become distinguishable, giving us 281,474,976,710,656 possible addresses for web servers.
[Yes this is an oversimplification for the pedantic]
I'm not sure I get your point clearly, even now. Are you stating dst port could be used for other things? I'm honestly unclear how 'static' bits in TCP relate to IPv4.
I think they're saying that most things that go over TCP are HTTP, which means usually those bits are set to 80 or 443. With SRV records we could be using more ports, and then presumably do port based routing instead of host based routing on the back end.
Idea is to treat (ip, port) pair as single 6-byte endpoint address. Each endpoint would be able to run just one service (well, two, one for tcp, another for udp). Type of service would be determined by looking up PTR record.
On the downside you won't be able to easily tell if two services run on a same machine or not. SSH and HTTP endpoints would be related only through DNS.
I think doing it in compatible way that doesn't require replacing routers would require NATs on both sides, and client that looks up PTR records before connecting.
Ah. That is actually an interesting idea I had never thought of. That said, it has its drawbacks as well - especially when it comes to who owns what. IPv4 are mainly all gone. So even if we tack two bytes onto each address, I'd assume those who got the allocations would get those additional addresses.
> There are more people on Earth than ipv4 addresses
Assuming you're responding to this? That statement is unwieldy but clear (would have preferred there aren't even enough IP addrs to uniquely identify every currently living person or some such).
I think they're saying that address records are part of the address-exhaustion problem. If we used SRV records instead then the port numbers become available for service endpoint discrimination, and this is a 16-bit space as alluded to. If adopted some time back this would indeed have conserved IPv4 address space; certainly there would have been far fewer 1:1 assignments for SSL termination, and a public cloud load balancer would be able to handle many distinct customers on a single IP address and so on.
In practice there'd be some introductory issues in deviating from the well-known ports involving gateway traversal (particularly corporate firewalls), but we've cleared such hurdles before.
Remote Desktop really needed to use SRV. It's just so much more convenient to be able to connect to foo.example.com and have that bind to example.com:12345 when all you have is 1 IP address.
For what it is worth, that is not actually my title, and the answer does deal with a lot of things other than that subject including the many things that one can discover do use SRV resource record sets.
Enjoy a related discussion of some poor FTP clients:
I try to keep the Frequently Given Answers up to date, occasionally revising them as I learn new stuff and people tell me stuff. I'm going to trust my own footer information (-: and not check with the Wayback Machine. So first published in 2004 but revised over the years since.
Just from the article and some of the comments here, it's not quite clear to me what the motivation for making HTTP use SRV records is. To me, naively, it seems like relying on A/AAAA records a) "works", and b) is central to a lot of people's intuition of how networking services function.
Following some of the links in the article, I've seen people make arguments on how straightforward it would be to implement and how it clearly works well for some non-HTTP systems. I'm guessing there's some implicit shared understanding of the problem space that I, as an uninitiated, casual DNS user, can't really wrap my head around.
Can y'all point me in the right direction to read something about, like, what problems SRV records solve for HTTP, and specifically how that solution compares to how people have traditionally solved those problems with HTTP? There seems to be some tension between best practices as established by IETF RFCs and best practices coming from decades of deploying public-facing HTTP infrastructure/browsers, does that sound about right?
An URL of "https://github.com" means looking up A and AAAA records for "github.com". The HTTP vendors are arrogant enough to demand that your host address for the whole domain is that of the web service, and not any other service.
Because it's at the apex of the domain, that record also cannot be a CNAME alias, because the apex includes DNS metadata that is not allowed to be aliased. So instead we have numerous ugly hacks from DNS providers that vary that address record by tracking an alias target, with varying degrees of reliability.
In other words, your DNS is now entirely subordinate to the demands of the web protocols and using ugly hacks to work around limitations of address records. You can stick a "www" on the front as a cheap, poorly specified, and untyped service selector, but because of the convention of just entering a domain name you'll still have to do the apex record.
Basically, the current convention for HTTP is to overload the address record to be its personal service record and screw everyone else and the consequences.
SRV also provides mechanisms for service fallback and weighted loadbalancing that address records do not. It can also conserve IP space by directing clients to alternative ports without ugly port specifications in the URI. There's a lot to like about it, and a lot to dislike about the current practices.
A big one: client-side load balancing allows for the removal of the last SPOF for most websites: the IP(s) of the load balancer(s) to which the A record(s) point to.
A second one: deploying TLS websites used to require one ip per hostname, and presently requires weird hacks like SNI (which leak the hostname to which one is connecting to observers). Being able to deploy any website on any port allows for a lot more flexibility in deployments, especially given the current trends such as “serverless”, k8s, et c.
Hm, I don't quite understand, if I have multiple A records, is it still a single point of failure? Could you clarify the difference between having a bunch of SRV records and a bunch of A records here?
If your client recieves multiple A/AAAA resource records, your client has no way to know what order they should best be tried in, from the server's point of view, and there is no way for the content DNS server to transmit that information.
Note that making priority and weighting available is given in the rationale section of the original RFC from 1996. What you're talking about actually isn't specific to HTTP.
For web browsers, multiple A/AAAA are sufficient. Web browsers worked around the issues folks are mentioning some time ago using retries to each IP.
The use of SRV could help in newer API driven implementations so that scripts and other tooling could enumerate which IP's are preferred. For now, developers will just have to make use of multiple records like the browsers do.
That said, it won't likely happen because the HTTP spec does not allow new DNS implementations. The RFC would have to be deprecated with a new one that permits SRV. HTTP/2 would have been a grand opportunity to do just that. There have been many discussions [1] and debates on the issue, but I do not foresee it happening.
HTTP protocol & normative references don't actually mention DNS at all.
The hand-wringing evidenced by some about the difficulties of introducing a new behaviour seems pretty feeble when you consider that Google has successfully intruded both a new transport protocol (QUIC) and a new application layer protocol (HTTP/2 i.e. SPDY) in a few short years. Rolling browser updates are now the norm and enable these major changes.
Agreed, but the protocol does not allow for deviation without creating a new protocol; which to your point, Google did. Google could have introduced SRV records as optional components in the spec. So the lack of mention of DNS standards in the protocol is sufficient to block the implementation of a new DNS requirement.
Browsers are not the only thing that speak http. There are a myriad of libraries used by API's and all manor of automation that must also be updated to support a new protocol. A good example of this is SNI. All major browsers support SNI, but there are plenty of libraries that have yet to catch up to that very well aged protocol.
Funny thing is, TBL anticipated this years ago when registering the service names. Read the assignment notes at https://www.iana.org/assignments/service-names-port-numbers/... - yes it's talking about DNS-SD specifically but the remark generalises to all service discovery, basically setting the expectation of different service names based on intended use.
API endpoints tend not to be apex records, indeed are characterised by using a label of "api" or similar which doesn't automatically conflict with other services, certainly not in the common case. It'd remain a violation IMO to use a host name as a service selector but in practice they could continue using address records for many years of transition.
Hm. Sounds great and all, but there’s a catch: All “managed” networks (corporate, schools or otherwise) are built on the fact that port 80 means HTTP and port 443 means HTTPS.
It would be great if you could do a DNS lookup, and in the request, say I want x record types for y name. Like, give me A, AAAAA, CNAME and SRV records for apple.com. I guess there's opportunity for abuse, but I think it would be better than ANY.
Of course, if we were redesigning the DNS protocol (which for what you want would be necessary, given how questions are structured) I would suggest being far more radical and not structuring things in terms of separate A, AAAA, CNAME, and SRV resource record sets in the first place; but rather in terms of <domain,transport,service> tuples and <priority,weight,address,port> tuples, as getaddrinfo() roughly is. Query goes out with <example.org,tcp,https>, full answer response comes back with a prioritized and weighted set of IPv4 and IPv6 addresses and port numbers (possibly with intermediate domain names, if one wanted to keep that concept in a redesigned protocol, which one possibly would not) all together.
I'm wondering, is there support for multiple queries in one request in DOH (DNS over HTTPS)? Currently that looks like where browsers are most likely to try new things.
You can put in multiple queries in a single packet. It's just that the response header would be ambiguous (a NODATA status could refer to any one of your queries) and therefore not even a minority of clients or servers support this.
It's right there in the protocol, we just need to figure out how to signal NODATA/NXDOMAIN/SERVFAIL/... for each individual query.
Didn't know that thank you! I guess it should be more compact though. Sending multiple complete queries would almost certainly need TCP, not sure the browsers would like that. Then again I think we're getting to the point where DNS should now be considered a mostly TCP protocol.
A IN 38:mydomainnameislongerthanyourdomainname 3:com
AAAA IN <2 bytes pointer>
CNAME IN <2 bytes pointer>
SRV IN <2 bytes pointer>
So 43 bytes for the name (41 bytes data, 2 length fields), plus 4 bytes for the type and class, and 6 bytes (type, class pointer) for each additional type. Even if you would already consider 200 bytes to be a lot of overhead, that would fit `floor(200/6)`=33 question records, more than I think we'd ever use. (Sure, the exist more, but currently we only query for A and AAAA. The overhead of that, when using the current DNS format but using multiple queries in one packet, is a grand total of 6 bytes.)
When SRV is discussed e.g. on the HTTP/2 list, the objections of resolution speed and number of round-trips are usually raised. But SRV records do not intrinsically require an additional lookup or round trip. Unoptimised zone configurations (especially those that slice at _tcp, which occurs at some Microsoft shops) may fare less well, but that is true of all DNS configuration. Services that care about resolution speed already optimise their DNS as necessary, and they would for SRV as well if it were mandated.
In practice, the reasons for non-adoption are, mundanely, simply a matter of inertia, combined with a lack of motivation: the browser vendors who in practice write the HTTP standard do not care to change and have no external force that will push them off overloading the address record.