>Bonus error: you can't have DNS packets >64k. Even over TCP. (Been there)
I am curious how did you get there given the length field in DNS records is only 16 bits?
I think the point was that they wanted to return more data than 64kB in the response but couldn't.
I remember when you could list entire cctlds, how did that work then? They weren’t as big as they are today but definitely bigger than 65k.
It sounds like you're thinking of zone transfers (the special AXFR query type). In that case the server's response may consist of more than one DNS message sent consecutively over a single TCP connection [1], so it's possible to transfer large zones. E.g. out of curiosity I just asked for the root zone with
dig . axfr @iad.xfr.dns.icann.org
[1] https://datatracker.ietf.org/doc/html/rfc5936#section-2.2
Re:Some ways DNS can break
by richardwhiuk on Monday January 17, 2022 @03:59AM
(#29964678)
The problem with DNS SRV priority is that it rarely provides the behaviour you actually want.
Re:Some ways DNS can break
by bradknowles on Monday January 17, 2022 @03:42PM
(#29971492)
SRV is deprecated. Don’t use it at all.
When did SRV become deprecated?
The standard[1] doesn’t show it was obsoleted by anything else.
Re:Some ways DNS can break
by bradknowles on Monday January 17, 2022 @09:25PM
(#29974247)
I think it was one of the BCPs that recommended that people not use SRV records. I’ll have to check.
Someone has configured a delegation loop. (Yep, been there more than once)
Records are currently unavailable, but someone has busted the cache. (Enjoy)
All services wait for the same DNS record to be fetched and will all ask the same service at exactly the time when DNS is done. (Again, clear yes, happens. That's why you should use prefetch)
No one knows how to handle DNS SRV priority correctly (please correct me if I am wrong).