11–20 of 61 posts
Earlier quoted context omitted.
Its only broken if you dont consider robustness a feature.
It's not just "robustness". Not supporting TCP DNS breaks DNS if your responses are "large", for values of "large" that include numbers that are in fact very small.
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 doi…
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.
The moment I saw Alpine Linux in the title, my first guess was "I bet this is something to do with musl libc". Briefly looking through the blog, it looks like my gut feeling was correct. A while ago I evaluated Alpine Linux. I wanted to like it, I really did, it ticked so many boxes. But time and time again, I kept on running into issues with their adoption of musl libc. The last straw for me was when I discovered pa…
(I assume you meant "glibc", not "libc".)
That's how every software works. The software developer cares about A, B, C distros at most, so other distros are on their own. The maintainer of distro D takes responsibility themselves to make the package work on D. The maintainer needs to understand the software well enough to be able to assert that it will work on their distro, patch it as necessary to make that happen, and maintain those patches in the light of bug reports from the distro users.
>(And yes I raised some of these as bug reports, but the cases got closed and nothing done about it).
Well, yeah. Unless you find something that is irrecoverably broken against musl such that it can only be fixed by compiling against glibc, your bug report is pointless.
The moment I saw Alpine Linux in the title, my first guess was "I bet this is something to do with musl libc". Briefly looking through the blog, it looks like my gut feeling was correct. A while ago I evaluated Alpine Linux. I wanted to like it, I really did, it ticked so many boxes. But time and time again, I kept on running into issues with their adoption of musl libc. The last straw for me was when I discovered pa…
"you're on your own" is like, the expected thing when you are doing something different. Still, Alpine is on top of everyone else when it comes to Docker Images sizes. Thats why it will stick.
Indeed. And that's fine. As long as you're willing to support that difference.
But the "Alpine compiling XYZ against musl" thing is/was just being done blindly by Alpine (i.e. load X into auto-build and let it rip). Sure it compiled without errors. But it never ran properly.
The moment I saw Alpine Linux in the title, my first guess was "I bet this is something to do with musl libc". Briefly looking through the blog, it looks like my gut feeling was correct. A while ago I evaluated Alpine Linux. I wanted to like it, I really did, it ticked so many boxes. But time and time again, I kept on running into issues with their adoption of musl libc. The last straw for me was when I discovered pa…
>The last straw for me was when I discovered packages in their package repo (some of which were well-known names) that were compiled against musl when the upstream developers quite clearly wrote in their docs that "if you compile X against anything other than libc, you're on your own". (I assume you meant "glibc", not "libc".) That's how every software works. The software developer cares about A, B, C distros at most…
Yes, corrected.
> The maintainer of distro D takes responsibility themselves to make the package work on D.
Yeah, but Alpine are not doing that, or at least not at the time I evaluated. I got tired of finding distro supplied packages that just didn't work as expected because things broke unexpectedly because of musl.
Earlier quoted context omitted.
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.
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 doi…
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), y…
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.
Earlier quoted context omitted.
It's not just "robustness". Not supporting TCP DNS breaks DNS if your responses are "large", for values of "large" that include numbers that are in fact very small.
Its okay to ignore "modern" features if they create bad edge cases.
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 doi…
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), y…