Hacker News Reader

Comment by treffer | Hacker News Reader

Bonus error: you can't have DNS packets >64k. Even over TCP. (Been there)

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).

View on HN

>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

and I received 24,448 records transferred over 83 DNS messages, according to the stats dig prints at the end.

[1] https://datatracker.ietf.org/doc/html/rfc5936#section-2.2

The problem with DNS SRV priority is that it rarely provides the behaviour you actually want.

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.

1: https://datatracker.ietf.org/doc/html/rfc2782

I think it was one of the BCPs that recommended that people not use SRV records. I’ll have to check.

Reply on news.ycombinator.com