Hacker News Reader

Comment by tptacek | Hacker News Reader

We're a somewhat popular hosting provider that runs Docker containers (as VMs) for our customers and does private networking over IPv6, which expands the size of our DNS requests, and we run into this all the time with Alpine. It's kind of baffling.

TCP DNS is not hard. It's part of the spec. Normally, that argument doesn't mean much to me --- lots of things are parts of specs that I think are silly and not worth doing --- but TCP DNS seems like a basic necessity for DNS to work at all.

What's holding this up? TCP DNS is just UDP DNS, but over a TCP connection, with the packet length sent before the packet itself. It's the simplest thing you could possibly come up with to make TCP DNS work. It's been there since the 1980s. They should add it.

View on HN

RFC9210: DNS Transport over TCP - Operational Requirements

https://datatracker.ietf.org/doc/rfc9210/

   This document updates RFCs 1123 and 1536.  This document requires the
   operational practice of permitting DNS messages to be carried over
   TCP on the Internet as a Best Current Practice.

You should be running a local resolver. I get where you're coming from but if you "keep running into this" you should probably stop running into this?

How running a resolver will fix `getaddrinfo` not using TCP ?

This is why I like glibc’s approach of making the actual resolution someone else’s problem and pluggable.

Possibly ask on #musl or submit a patch?

They know about it! I could write the patch, but they're not going to accept it; there's something weird going on about this.

There isn't anything weird, I went on #musl asked the question, the functionality is desired but it should be worked with the community to ensure correctness.

Yes, there is. I'm not just making this up. I've gotten takes from "musl people", including Rich Felker, that this was a deliberate choice, and that not only is musl's behavior of pretending that truncated UDP responses are valid acceptable, but that it's somehow better (maybe for performance?) --- that you can always serve "getaddrinfo" off of just the truncated UDP result. Which is, of course, false.

There is a weird thing going on; maybe you can relay this back to the #musl channel you're talking on, and they can keep discussing.

> There is a weird thing going on

It's not weird they're just incompetent / a bozo.

The functionality was explicitly not added by the developer.

> My choice not to do TCP in musl's stub resolver was based on an interpretation that truncated results are not just acceptable but better ux - not only do you save major round-trip delays to DNS but you also get a reasonable upper bound on # of addrs in result.

https://twitter.com/RichFelker/status/994629795551031296

Maybe he is willing to consider it now, I don't know.

It's not a bug, it's a feature! You're welcome. (tm)

I mean sure, musl should add TCP DNS. But real world networking says if your DNS response is over the limit for basic UDP DNS, a meaningful proportion of clients won't get that response. Which I guess is okish if it's a TXT for mail servers, cause mail servers probably have a reasonable DNS setup; but if you wanted to return a lot of A records or AAAA records (or A records that a provider DNS64s into AAAA records), you need to be careful about how many you return, before the response gets too large and doesn't arrive.

This is something networks and DNS client libraries should fix, but we live in a world where PathMTU only mostly works, so realism gets your service working.

This is literally the opposite of true. The OS-supplied resolver supports TCP DNS on all of the most popular desktop and mobile OSes and has for ages. I'd estimate a minimum of 90% of users have setups that support it, and I'm only hedging the 10% because I'm not sure how prevalent horribly misconfigured corporate firewalls are.

By not supporting TCP DNS you are the odd one out.

The OS supplied resolver may support it, but many networks block TCP DNS.

Many networks also block AAAA DNS, because middleboxes are stupid. That doesn't mean it's OK for libc not to implement AAAA.

It's non-trivial to determine if your response will fit into the UDP packet size, other than erring heavily on the side of caution.

Part of the request query is included in the response, IPv6 AAAA records are considerably larger than IPv4 A records, DNSSEC adds size, RFC 1035 message compression comes into play, EDNS0 comes into play, etc.

Which is all to say that you're right that for maximum compatibility you should endeavor to fit all responses into a UDP packet, but most places lack the sophistication to ensure that is always the case.

Supporting TCP DNS on the client side should not be considered optional if you want to successfully resolve records that you don't control.

That's acceptable in the real world because virtually nobody uses IPv6, and people who run into IPv6 problems will just avoid musl.

>virtually nobody uses IPv6

Some very high percentage of mobile devices, when using mobile data, are on IPv6 and preferentially connect using IPv6. I think 80% of Meta traffic is IPv6.

Lots and lots and lots of people use IPv6.

I have to say though the BOFHesque attitude shown in this thread by a number of people has convinced me never to touch Alpine linux. I can already see exactly what sort of attitude towards users and input the developers encourage and that sort of ivory tower shit has absolutely zero appeal.

Reply on news.ycombinator.com