Comment by shp0ngle | Hacker News Reader

Comment by shp0ngle | Hacker News Reader

The weird thing about DNS-over-TCP is that the maintainers of musl know about it, there were patches for that long time ago, but they intentionally want it to be broken and they refuse the patches. It’s not a known bug, a design decision.

I’m however not sure if this is correct

> Another example is Golang whose standard library - or more specifically net/http or os/user modules - depend on C libraries and therefore on glibc.

To my knowledge, no go standard library depends on cgo? Can you show me in the docs/source code where is stdlib using cgo? I am very surprised by this claim

edit: I might be wrong about musl declining patches. I swear I saw it happen but now I cannot find it

You might not be aware, but dns-over-tcp has been added to musl[0] and will be part of the next release.

[0]:https://git.musl-libc.org/cgit/musl/commit/?id=51d4669fb9778...

okay then I am double wrong and I’m sorry.

What is so wrong with DNS over UDP? It's worked like that since it was invented. Surely making sure your cluster has a UDP-accessible DNS service can't be that hard. I think this is not an unreasonable decision for the musl maintainers to take.

Is there an RFC that deprecated DNS over UDP?

If your dns response won’t fit in a udp packet dns needs to flip to tcp or dns just silently breaks. A docker image that wont work in large k8s deployments is broken. The thing that breaks it is broken. Broken by design is still broken.

I think it’s a pretty unreasonable design decision.

No, that’s why UDP is default and TCP is expected to be a fallback.

DNS over TCP has been standardized since before many people on HN were born. The "problem" with UDP is that there are limitations on UDP datagram sizes. DNS is designed to deal with this: there's a "truncation" bit in the header that tells resolvers to repeat their queries over TCP.

That's odd. What's the stated justification for it?

Reply on news.ycombinator.com