[HN Gopher] What's the maximum size of a DNS response?
___________________________________________________________________
What's the maximum size of a DNS response?
Author : vinnyglennon
Score : 56 points
Date : 2022-07-27 18:24 UTC (4 hours ago)
(HTM) web link (www.netmeister.org)
(TXT) w3m dump (www.netmeister.org)
| jagged-chisel wrote:
| > the actual maximum sizes [and how various factors] influence
| the practical limit are far from obvious.
| 1vuio0pswjnm7 wrote:
| Why EDNS0 Because DNSSEC Why DNSSEC Because
| cache poisoning Why cache poisioning Because
| remote, shared caches Why remote, shared caches
|
| Was the idea for remote, shared caches suggested in RFC 1035.
|
| RFC 1035 suggests that the resolver and the cache are part of the
| user's operating system.
|
| "User queries will typically be operating system calls, and the
| resolver and its cache will be part of the host operating
| system."
|
| The expectation is that the cache is local, not remote.
|
| "Resolvers answer user queries with information they acquire via
| queries to foreign name servers and the local cache."
|
| Mockpatris' DNS does not direct anyone to make use of remote,
| shared caches. It is entirely optional.
|
| "Foreign nameservers" refers to authoritative servers, not third
| party caches.
|
| DNS can work without using third party DNS service. I have been
| using it this way for 14 years. Remote, shared caches are
| optional. As is making remote DNS queries contemporaneous with
| HTTP requests, generally. For myself, the DNS data I need can be
| collected in bulk and stored.
|
| IMO, a general historical principle that applies to computer
| software is that "features" can carry risks. In a non-DNS
| context, Apple's latest "Lockdown Mode" has now provided a
| popular contemporary illustration. Not every "feature" makes
| sense for every user in every situation. EDNS0 is an optional
| feature. Some computer owners may choose not to use it.
|
| There are risks in DNS "extensions".^1 It is for users to decide
| whether they wish to undertake those risks by using them.
| Personally, I still adhere to original DNS packet sizes on the
| networks I control. The now relatively small 512 byte packets are
| one of the things I like most about DNS. I do not enable EDNS0. I
| do not send ECS.
|
| NB. I am not against extensions, per se. RFC 1035 contemplated
| them. I remain keen to to learn what the "Z" bits will be
| eventually be used for. However using remote caches "safely" and
| facilitating someone else's DNS-based load balancing are not
| "features" that interest me.
|
| 1. EDNS0/DNSSEC becoming a DoS vector and user privacy leakage
| via ECS.
|
| Notes
|
| EDNS0 may have spawned further extensions with different
| impetuses. EDNS Client Subnet (ECS) being an obvious example.
| Here I refer to what appears to be the initial impetus for EDNS0.
|
| ECS has been the source of problems, e.g, with user privacy.^2
| Its impetus was to help CDNs, not users.^3 It may or may not also
| be used to further the commercially useful data collection (read:
| advertising-related services) of those who provide third party
| DNS service.
|
| Remote, shared caches are sometimes referred to as "open
| resolvers". Problems have been associated with open resolvers.
|
| 2. User privacy against the third party and its commercial
| pertners, not against the operator of the authoritative
| nameserver.
|
| 3. Whether it is "mandatory" (cf. optional) for CDNs is
| debatable. Cloudflare, a large CDN and third party DNS provider,
| has said they do not send it. Unless the RFCs have changed, IETF
| recommends that it be disabled unless it provides a clear benefit
| to clients.
| jsmith45 wrote:
| RFC 1035 did in one part suggest a model in which some bigger
| more powerful machines may run a recursive resolver as the
| local resolver, but other machines would probably use a stub
| resolver that redirected a local service running a recursive
| resolver as a service to the network.
|
| This had benefits like the centralized cache of the local
| networks' recursive resolver being more beneficial.
|
| Implementation wise, most implementations are either stub
| resolvers, or full blown dns servers capable of serving up
| arbitrary sets of domains authoritatively. There are fewer
| implementations that do recursive lookup without a full
| authoritative server implementation. Obviously including a full
| capability DNS server in every OS install is absurd, so they
| come with with the stub resolvers instead.
|
| And originally when the Internet was just big organizations
| connecting their networks, each network running a recursive
| resolver for the other machines made sense and worked fine. But
| along comes home internet, where originally just one machine
| running windows was getting connected. ISPs could perhaps have
| required users to run their own recursive resolver, this would
| be painful, and inefficient. (Keep in mind that a recursive
| resolver's cache is more efficient the more machines it is
| providing services to). So the ISPs ended up running recursive
| resolvers for customers.
|
| But now since the ISPs customers don't all trust each other,
| concerns like cache poisoning become possible, which were not
| much of an issue when you ran and trusted your own networks
| recursive resolver.
| jiggawatts wrote:
| These extensions aren't solely intended for "greedy CDN
| corporations".
|
| Anyone who has set up multi-site load balancers knows that
| telcos aggregating DNS via just a couple of egress IP addresses
| makes load balancing too coarse. Similarly, session stickyness
| may not work.
|
| These extensions largely fix this issue.
|
| Having said all this, anycast routing is arguably superior for
| solving this problem, but nonetheless it's a real problem that
| needs _some_ solution.
| tptacek wrote:
| A fun bonus detail: the libc used by many Docker containers
| doesn't implement TCP DNS at all, and just returns the truncated
| result from the UDP response as if it was the whole answer.
| nimbius wrote:
| totally untelated but I wonder if DNS response size is optimized
| in faang..
| toast0 wrote:
| Mostly faangs use load balancers and don't return more than one
| A/AAAA record. Sometimes there's some CNAME chaining which
| isn't ideal, but might be expedient. Otherwise, not too much to
| optimize.
|
| Otoh, they like their really short TTLs, which results in a lot
| of queries.
| toast0 wrote:
| One thing to consider if you're packing in A records, but want to
| fit in 512 bytes is that there may be an intermediary server
| doing DNS64, turning your A's into AAAA's at a much increased
| size. It's been a while since I looked at that, but I was
| encouraged to return no more than 8 A records, so that T-Mobile
| could return 8 AAAA and not go over the 512-byte length where
| things tend to get dicey.
| more_corn wrote:
| udp or tcp?
| mobilio wrote:
| "Now just about every website on this here internet will tell
| you that the DNS uses UDP port 53, and that any response must
| fit into a single 512 byte UDP packet, and of course that
| answer is right. Except when it isn't. But let's start with
| that assumption and see how much data we can then fit into a
| single 512 byte response:"
| Dwedit wrote:
| People used to use DNS Tunneling to get free internet in a
| captive portal, so a lot of data was getting transmitted in DNS
| packets.
| ipdashc wrote:
| Is DNS tunneling not used anymore? I've been thinking of
| setting one up recently
| hsbauauvhabzb wrote:
| It's used by malware, and detectable via high entropy nature
| of the traffic (most domains don't have thousands of txt
| records containing b64). Recently I sent a 1mb file over dns,
| which terminated abruptly, I suspect dns resolvers
| blacklisted the domain.
|
| It also multiplies bandwidth by at least 2-3x I think, so I'd
| call it bad etiquette to use unless you have a very very good
| reason to.
| siraben wrote:
| This still works in a lot of circumstances with iodine[0],
| including several US domestic flights.
|
| [0] https://github.com/yarrick/iodine
| CraigJPerry wrote:
| This made me wonder about DNS over HTTP but it seems the standard
| accounts for size and limits both GET / query string and POST
| methods to 512 bytes.
|
| So tcp supports the longest then?
___________________________________________________________________
(page generated 2022-07-27 23:00 UTC)