DNS Lib Underscore Bug Bites Everyone's Favorite Init Tool, Blanks Netflix (theregister.co.uk) 292
Reader OneHundredAndTen writes and shares a report: Systemd doing what it does best. From a report on The Register: A few Penguinistas spent a weekend working out why they can't get through to Netflix from their Linux machines, because when they tried, their DNS lookups failed. The issue emerged over the weekend, when Gentoo user Dennis Schridde submitted a bug report to the Systemd project. Essentially, he described a failure within systemd-resolve, a Systemd component that turns human-readable domain names into IP addresses for software, like web browsers, to connect to. The Systemd resolver couldn't look up Netflix's servers for Schridde's web browser, according to the report. In his detailed post, Schridde said he expected this to happen: ipv6_1-cxl0-c088.1.lhr004.ix.nflxvideo.net gets resolved to 37.77.187.142 or 2a00:86c0:5:5::142. When in reality, that wasn't happening, so Netflix couldn't be reached on his box. His speculation that libidn2, which adds internationalised domain names support to the resolver, was at fault turned out to be accurate. Rebuilding Systemd without that library cleared the problem.
Not a bug (Score:5, Insightful)
Underscores are not allowed in domain names. Some resolvers allow them for historical reasons, because they were common in Microsoft environments that defaulted to converting a space to an underscore when entering the hostname on initial configuration, back when Microsoft thought that everybody would be using Microsoft Network and not Internet.
But they're not legal, and should NOT resolve. My DNS servers do not have the ancient msdos compatibility turned on, and reject them as they should.
libidn (internationalized domain names, punycode) do not use them either, and if it rejects them, all the better.
Re: (Score:2)
If we're on the subject of what's wrong with this hostname, I'll add that they put "ipv6" in the hostname itself and yet it can resolve to an ipv4 address.
Re:Not a bug (Score:5, Insightful)
Don't expect the hostname to match functionality. One of the companies I have to download patches from every now and then have their ftp server named wwwonly.
That said, and back to topic, underscores can be used in DNS, but not for hostnames, only for other services. Hostnames are restricted by rfc1123. So if it returned an SRV record or similar, it would be fine.
But don't name a host with an underscore.
Re:Not a bug (Score:5, Insightful)
But they're not legal, and should NOT resolve. My DNS servers do not have the ancient msdos compatibility turned on, and reject them as they should.
Although apparently the behavior that it has is to strip out the offending characters and then try to resolve the result, which doesn't make a whole lot of sense either.
From the bug, it looks like the problem is caused by linking with libidn2, and support for that was marked as "experimental" in systemd, so this really doesn't matter much. You shouldn't be enabling experimental features in software unless you're willing to deal with potential problems.
Re: (Score:2)
Underscores are not allowed in domain names.
But .. but .. but .. systemd!!!!!!
Re: (Score:2, Informative)
Underscores are not allowed in domain names.
That has not been the case and is not the case currently. RFC 2181 dictates differently and more specifically section 11 of said RFC. [ietf.org]
Re: Not a bug (Score:2)
Re: (Score:3)
I don't know who the AC person was that decided to go full on retard there is, but it's just simple misunderstanding on my part. You are correct in that hostnames cannot have underscore. I'll leave this here [sourceforge.net] for all the other parts of DNS that do allow underscore. That said, my confusion was taking sub-domain and mixing it with hostname. Honest mistake on my part.
Re: (Score:2)
The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record.
Re: (Score:3)
STD3 rule applicability is contentious for this *very reason*
You, the link you provided, and Internet Explorer all agree that you shouldn't use underscores for labels unless they're a specific kind of label. You all conform to the STD3 rules for "host names"
The rest of the internet does not, and conforms to the RFC2181 reading which says, "labels are whatever the hell the clie
Re: (Score:2)
Good luck, indeed.
A DNS label is just that, a DNS label. Just as the netflix client asked for. Resolution of a DNS label. libidn2 mangled that when it handed it off to the resolver due to some well known issues in libidn2 that did not exist in libidn.
You are so far out of your league it isn't even funny. You literally have no idea what you're talking about.
Re: (Score:2)
It in fact says, "you can have underscores as part of the domain name, but it's possible browsers may not bother to try to resolve it."
You are such a manipulative shit.
Re: (Score:2)
No it doesn't. That section of RFC 2181 says that a DNS server isn't allowed to refuse to serve a zone because a DNS label in the zone isn't a valid hostname. It does not say that any valid DNS label is a valid hostname, and it does not say that a DNS client must resolve an invalid hostname. If fact, RFC 2181 doesn't define what is or is not a valid hostname at all - for that you should consult RFC 952 (with a small amendment in RFC 1123).
Basically, you are allowed to use whatever you want as a DNS label bu
Re: (Score:2)
Urgh, sorry - I just expanded an abbreviated reply to Zero__Kelvin and see that it's you showing that you already know all that. Sorry for lecturing you on something you already understand.
Re: (Score:2)
It says, essentially, that any name label is valid for any RR, and it is up to the client to determine whether or not it considers it valid for resolution.
In this instance, Netflix is the client. It considers that name valid for its service, and is well within its rights to do so. In the instance that they published that as a URL for you to put into your browser, they would be stepping into bad-netizen territory.
The real issue here has nothing to do with resolvers. All resol
Re: (Score:2)
[This discussion](https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it) on StackOverflow seems to disagree with that statement. I don't really understand the specifics of it and don't really have time to delve into them right now, but the basics are that while using an underscore is illegal in a host name, it is not illegal to use one in a domain name (I'm not sure of how the difference is discerned here). I'm not saying you're wrong, but it seems like there is c
Re: (Score:2)
You realize that systemd's resolve doesn't give 2 squats of piss whether or not there is an underscore in one of the names when it encodes it into a DNS query?
Do you know why it doesn't? Because it *shouldn't*
This issue is with the internationalization IDNA/Punycode-to-ASCII non-transitional flags in use that are mangling the hostname before systemd's DNS resolver forwards the request.
Re: (Score:3)
The problem is, Poettering doesn't subscribe to Netflix. If he did, this problem wouldn't have happened :D
Re:Not a bug (Score:4, Funny)
The problem is, Poettering doesn't subscribe to Netflix.
I'll bet because he couldn't get the sound to work.
Re: (Score:2)
Underscores are not valid in hostnames but are totally legitimate in DNS labels. SRV records come to mind.
Re: (Score:2)
Underscores are not valid in hostnames but are totally legitimate in DNS labels. SRV records come to mind.
Absolutely, but this was about A/AAAA records.
Getting a DNS response to an A record query for a hostname with an underscore is as wrong as getting a DNS response to a PTR record for 21.43.65.987.in-addr.arpa
Re: (Score:2)
Re:Not a bug (Score:5, Informative)
Nope. You misread it. That RFC says:
Which is to say that legal DNS labels may not include underscores. They are exclusively allowed for non-hostname types, such as service records, and they specifically chose that character for this use to ensure that it cannot conflict with any legal DNS name.
Re: (Score:2)
Any RR label may include an underscore, and it is a breach in etiquette and standards for any server to refuse to accept these. That behavior is left to the client, which may interpret that RR for whatever needs suit it.
RFC 2181 11. Name syntax: The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs. A DNS server may be configurable to issue warnings when loading, or even to refuse to load, a primary zone containing labels that might be considered questionable, however this should not happen by default.
You're not wrong about it not being a valid hostname.
It is not invalid to use that label for any RR record. It is invalid to name a machine ipv6_1-cxl0-c088, which I'm fairly certain doesn't refer to a machine.
It is also not invalid for any client to refuse to accept that name. It i
Re: (Score:3)
But once it's published, it's pretty much ratified. Here's the mess https://www.ietf.org/rfc/rfc31... [ietf.org]
Re: (Score:2)
Yes, they can be (and are) used for other lookup data, but It's fairly common practice to reject them for A and AAAA records, because those are by definition hostname lookups, and hostnames on the internet cannot contain underscores.
Re: (Score:2)
but It's fairly common practice to reject them for A and AAAA records
This is a blatant lie. That is why Netflix works.
Re: (Score:2)
Underscores in DNS names are reserved for use in SRV and other such records, where they are mandatory, and they serve to prevent SRV records from getting confused with A and AAAA records, which are not supposed to have them. Humans are supposed to be able to tell the difference between a SRV and A/AAAA record by looking at them, without any extra markup.
Real things use SRV records. Just take a look at any pcap of any enterprise network and you'll see them flying every which way. Lots of service discovery
When's sshd getting incorporated? (Score:2, Funny)
Re: (Score:2)
I hear that Poettering has declared ssh a "broken concept", and so he's going to pull telnetd into systemd instead and permanently block port 22.
Re: (Score:2)
While funny, this is about what I expect from these morons.
Re: (Score:2)
Does anyone know if they've settled on a timeline for pulling all SSH into systemd as well?
I think right after they pull systemd into emacs.
Re: (Score:2)
Yeah, you just "figure out" that colon is being used as a control character. Right.
Only crazy people think using vi as the "only editor installed everywhere" is a great idea. It is unintuitive, and a royal PITA to use. Really "J" from outside insert mode to get rid of a newline? That's beyond cretinous. I can only guess that it persists due to the more sadistic greybeards wanting to lord it over the n00bs when they find themselves on a system with no decent editors.
I purge all vi from all my personal s
Re: (Score:2)
Really "J" from normal mode to Join two lines? That's ... actually not very difficult to memorize.
FTFY
Re: (Score:2)
Memorizing that isn't the problem with that one. Using it is. It's an anachronism in this day an age.
Re: When's sshd getting incorporated? (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Actually opened and marked as as a known issue by developers themselves as news long before some idiot user compiled a non-default setup with an experimental library and was SHOCKED! SHOCKED! I tell you, that he found a bug.
So reading between the lines... (Score:5, Funny)
"A Gentoo users ... recompiled a component... everything is working OK now".
How is this not working as designed?
trash (Score:2)
systemd = not-invented-here anti-UNIX botnet trash
Hey "Everyone's Favorite Init Tool" ? (Score:2)
I assume the poster wanted to be funny, right ?
Or is it one of those "black is white", "up is down" orwellian thing ?
Living in interesting times....
Re: (Score:2)
I assume the poster wanted to be funny, right ?
Or is it one of those "black is white", "up is down" orwellian thing ?
Living in interesting times....
It was a dickweed editor trying to be snarky in a article title.
systemd networkmanager also does not do server stu (Score:2)
systemd network manager also does not do server stuff to well like bonding / bridging / etc.
Re: (Score:2)
This is completely false:
https://www.freedesktop.org/so... [freedesktop.org]
Why do you lie?
Re: (Score:2)
systemd network manager also does not do server stuff...
[satire_mode = ON]
That's because apparently the systemd crew thinks Linux is only used in laptops and the occasional desktop, but never on a device with more than one network port.
[satire_mode = OFF]
Yes, it is a bug (Score:5, Informative)
The systemd fan club's response is that underscores are not allowed in DNS, and that this is ultimately a libidn2 bug.
Both of these excuses are claptrap.
Underscores are not valid in hostnames. They are valid in DNS labels.
It is not the DNS resolver's job to translate internationalized domain names. It is the application's job to do so. The DNS resolver's job is to resolve the request. Full stop. Ten year old versions of bind will happily process, and pass on, internationalized domain name. This is because internationalized domain names gets transcoded into ASCII-compatible encoding and THAT's what in DNS.
The way that it should work is as follows: an application, such as a web browser, translates an international domain name into ASCII-encoded hostname, and then looks it up in DNS. It would be the application's responsibility to use libidn2, or some other equivalent, to do the translation.
A typical systemd fail.
Re: (Score:2)
It's not just that underscores are valid. They are *required* for some uses of DNS. For example DKIM and DMARC records.
Re: (Score:2)
And the underscore was chosen to effectively put those records in a different namespace than A and AAAA records.
So let me get this straight (Score:5, Insightful)
A bug was noted in an optional library that wasn't default for any release of systemd. ... wait for it, this is the best part ... he notices a bug.
The following release of systemd downgraded support of the optional unused library libidn2 to experimental.
A pull requested was put in the bug tracker by the maintainer (not Poettering) to fix this in the future.
Some dude compiles a piece of software with an experimental library and
It makes front page news and Slashdot users start frothing from their mouth in their stupor.
And you wonder why complaints aren't taken seriously by developers. *golfclap*
Re: (Score:2)
You missed a step.
* thegarbz and the rest of the systemd fan club start pretending that just because this one bug isn't serious, the rest of the problems with systemd and its developers aren't real.
Re: (Score:2)
* thegarbz and the rest of the systemd fan club start pretending that just because this one bug isn't serious, the rest of the problems with systemd and its developers aren't real.
Oh no I saw that step. But we've filed it with the rest of the bullshit and hyperbole in its rightful place.
Why in the FUCK (Score:2)
Why in the FUCK is your init system messing with this type of shit?
What's next? Will you add an email client?
Re: (Score:2)
b-but is it IOT-ready?
Train Wreck (Score:4, Interesting)
It's abundantly clear that systemd-resolved has quickly become a train wreck. It's inclusion in Ubuntu 16.10 was widely lamented [dns-oarc.net] and many folks have pointed out huge concerns for several [launchpad.net] different [github.com] assumptions [github.com] that it makes for fallbacks and erroneous configurations. That's not including the several [github.com] different [slashdot.org] bugs [launchpad.net] that have plagued systemd-resolved thus far. Granted many of them are fixed but with the breakage what have we bought? Something that's a pretty basic task now requiring patch after patch. Additionally, what has this solved? Now we can make DNS configuration a bit easier to integrate across the board?
The bad rep that systemd especially resolved has obtained isn't just simply one where grey breads say "it's too different". It is one that time and time again, ignorant assumptions, bloated egos, and hasty code have led to a general distrust, especially when tools that have always worked are suddenly not working or worse still, become methods for exploits. I still think systemd is a vast improvement over the "ye olde init scripts", but while the idea is commendable, it's execution has been somewhat lack luster to put it mildly. There needs to be a serious "Come to Jesus" moment for the systemd team. You need to build trust if your going to build something that's rewriting the books. This is just another example of how that trust is being chipped away. Complexity of the task at hand aside, either the team is up to delivering or they are not. This ostinato where breakage just keeps happening needs a serious all hands or something to restore trust in the team guiding this project. Poettering, you are doing no favors to yourself nor your team by these stories. Deliver us from the hell of bad init if that's what you seek, but don't plunge us deeper into a different hell of your making and say that it's alright because you're the one who built it.
Re: (Score:2)
I think the systemd team just cannot hack it. They are too dysfunctional. Systemd needs to die before something that actually improves on the classic solutions will get a chance.
Re: (Score:3)
RedHat are the second biggest contributor to Linux, behind Intel. That makes them first among software companies.
Basically, they can shovel shit in quicker than everyone else can take it out.
https://thenewstack.io/contrib... [thenewstack.io]
OES/SLES had this issue too (Score:2)
Not newsworthy (Score:2)
This issue isn't newsworthy. As others have noted in the comments, underscores are not supposed to be in hostnames (they can be in other DNS RRs) and is about a bug in an experimental feature in a release of systemd that is not in any stable distros. People running rolling distros using the latest versions of everything are going to experience bugs. That's not news.
It
One question... (Score:2)
Do Linux users who use SysVinit encounter this issue?
I see what you did there (Score:2)
The issue emerged over the weekend
Gentoomen will get the joke. BTW, systemd is not used by default in Gentoo.
This is why .COM does not accept underscore (Score:2)
Back in the 1990's I was asked if .COM and .NET should continue to accept underscore in domain registrations. This was after I added "check-names" to BIND to prevent address and MX records with non-LDH names being accidentally added to zones in contravention of RFC 952 and RFC 1123 (still the current host requirement specification). I pointed out that if underscore was permitted that people would be continually having to explain why address lookups for names like "a.label_with_underscore.com" would not wor
Re:Blanks Netflix for a userbase edge case (Score:4, Insightful)
I guess you expected the headline to explain everything to you in full detail and with absolute accuracy, that's a pity.
But users with systemd is NOT an 'edge case' really. In fact it's becoming more like users WITHOUT systemd would be the edge cases, within *nix.
Re: (Score:2)
Just sayin'. But you know it's true.
One has to wonder what other subtle bugs are in systemd. Purely unintentionally, of course. No TLAs would want an opportunity to widely disseminate new bugs into vast numbers of systems.
Re:Blanks Netflix for a userbase edge case (Score:5, Funny)
People read headlines on Slashdot? I just look at comment numbers and pop in, I really think this crypto currency stuff is getting dangerous. We need more Net Neutrality, because it will fix the problem with congress leaving too many tweets for Kaspersky to hack the elections.. appy apps? O.o
Re: (Score:2)
I would like to point out that a significant subset of /. readers DO expect the headline to explain everything so that reading the article becomes unnecessary.
So the 140 character generation is becoming the (what?) 80 character generation?
In the words of a now (in)famous former, #Sad
[ And the irony of this quip is not lost on me. ]
Re: Blanks Netflix for a userbase edge case (Score:2)
64 characters ought to be enough for everyone!
Re: (Score:2)
But users with systemd is NOT an 'edge case' really. In fact it's becoming more like users WITHOUT systemd would be the edge cases, within *nix.
I believe the edge case is Netflix viewers running systemd, not just users with systemd. Sure many people view Netflix via Linux, but I doubt it is a significant portion of all Netflix viewers, thus an edge case. Offended by being referred to as an edge case? Perhaps "edge case" is a bit too much troll as the parent post is getting modded, "relatively minor case" may be more accurate.
Any yeah, systemd still sucks, but doesn't warrant sensationalized headlines.
Re: (Score:2)
Nor does it deserve the title Everyone's favorite init tool
Personally, I read that as sarcasm. I still presume it was intended that way.
Re: (Score:2)
Nor does it deserve the title Everyone's favorite init tool
Personally, I read that as sarcasm. I still presume it was intended that way.
Agreed. It's like Microsoft's famous 'Where do you want to go today?'
I always read that as the first part of a conversation with your evil jailer: "Where do you want to go today? 'Cos this trains going to Hell, with stops in Dis and the Lake of Fire. If you upgrade to First Class, we'll take the pitchfork out of your ass.... and put it somewhere else."
Then Microsoft dropped the slogan. And I kicked ketamine.
Re: (Score:2)
There are so many articles (here and in other places) that I don't have time to read them all and I have to rely on headlines to help make the cut. Call it "sensationalized" or just call
Re: Blanks Netflix for a userbase edge case (Score:2)
Re: (Score:2)
systemd-resolved is an optional component of systemd. I run a lot of systems with systemd as init and none of them run systemd-resolved (or systemd-timesyncd for that matter).
The problem is systemd breaking unexpectedly (Score:5, Insightful)
The real problem here isn't that a handful of Linux users couldn't use Netflix.
The real problem is that, yet again, systemd has been involved in critical functionality breaking in an unusual and unexpected way.
It doesn't matter if it was an external library that systemd used that's responsible. Systemd is responsible for the problem because it uses this flawed library.
There's no reason for systemd to be involved with resolving domain names. Linux got by just fine throughout the 1990s, the 2000s, and even a big part of the 2010s without systemd being involved. Yet now that systemd is involved, things are going to hell.
Long time Linux users will be very aware of how problematic systemd so often is in the dumbest of ways.
Maybe somebody who just started using Linux in the systemd era thinks it's acceptable for their system to sometimes not boot properly, or for the domain name resolution to break unexpectedly. But long time Linux users know it wasn't like that before systemd was forced on the Linux community, and they know that such breakage is just not acceptable.
This is just the latest in a long chain of problems involving systemd. It has gotten to the point where Linux's reliability is below that of the BSDs, of macOS, and as much as I hate to say it, even modern versions of Windows!
Systemd needs to go, at least from important distros like Debian and Ubuntu. If Fedora wants to screw around with systemd, then so be it. But the other distros should remove it immediately.
Re:The problem is systemd breaking unexpectedly (Score:4, Insightful)
Hear, hear!
Why the hell does an init system need a built-in DNS resolver anyway?
Re: The problem is systemd breaking unexpectedly (Score:4, Insightful)
...which is an utterly retarded design.
Unix is a bunch of components by different authors, most with competitors, that use well-defined protocols to communicate. Unix works because stuff that sucks gets replaced, and no one person's vision defines what happens.
Systemd and Windows are defined by one small man's vision, not by protocols and competition. And when that man doesn't think usernames should have certain forms, well, fuck everyone else, right?
Re: (Score:2, Informative)
READ THE FUCKING COMMENT! It addresses that! (Score:4, Informative)
NO SHIT! Did you even bother to read the comment before replying to it, and before wrongly criticizing it?! OBVIOUSLY NOT! The comment you didn't read, yet still replied to, contained the following:
It doesn't matter if it was an external library that systemd used that's responsible. Systemd is responsible for the problem because it uses this flawed library.
By choosing to use this foreign library, the foreign library code effectively becomes part of systemd. If a user invokes systemd to perform some action, but systemd does the wrong thing because it uses a broken library, then it's both the library that's broken and it's systemd that's broken. Systemd can't be excused just because it uses a broken library. It's a problem with systemd as much as it is with the foreign library.
Re: (Score:2, Offtopic)
If systemd hadn't taken it upon itself to handle DNS resolution instead of sticking to its ostensibly primary job (initd), it would never have had reason to pull in libidn2 and fall to one of its bugs.
The Unix Way. systemd fails it.
Re: (Score:2)
You do not get it. Seriously. What counts for reliability is how the tool performs that delivers the service. What it uses for that is under control of the developers. If they select a bad library and fail to include appropriate redundancies in a system-critical tool, then the fault is on their heads.
Re: (Score:3)
His question was "why is systemd doing that instead of something else?"
Comment removed (Score:5, Insightful)
Re:The problem is systemd breaking unexpectedly (Score:5, Funny)
What next? A kernel bug gets blamed on systemd because systemd uses the kernel?
Wait! Who uses who now? :-)
Sorry, I'm from the future, where there is no kernel, only systemd.
Fun facts, after subsuming the kernel, the last non-systemd user land utility remaining is Emacs. Lennart and his (remaining) crew started the battle to absorb Emacs in 2040, five years before his death, and it's still raging many years after that. There have been casualties on both sides. Lennart died in 2045 when the experimental "systemd-elisp" module controlling his cold, robotic heart turned out to contain sleeper code, rumored to have been committed to GitHub by a radical faction of the FSF. He was found dead at his keyboard late one evening by the hooker he had ordered from Amazon Premiere earlier that day. The police report says he had been watching Trump porn.
Re: (Score:2, Insightful)
Re: (Score:2)
Thanks for that. It generated a seg fault and dumped garbage all over the screen.
Re:The problem is systemd breaking unexpectedly (Score:5, Informative)
Actually, the bug is not in libidn, but in libidn2. Or rather was – it got fixed rather quickly – https://gitlab.com/libidn/libi... [gitlab.com]
As for systemd, it uses libidn by default. libidn2 support is marked as experimental – reasonable decision as this bug shows.
The submitted article is pure flamebait - this is not a bug in systemd suite, but in 3rd party library; to experience this (already fixed) bug, distribution would have to have enabled experimental option. No sane distro does that.
Nb. The Register articles with even a passing mentions of systemd are terribly misleading and often blatantly false.
Re: (Score:2)
And yes, it's best practices
...to write unit and integration tests to catch these kinds of things. If you add libfoo to implement foo functionality, you want to test that it actually results in a working foo.
Re: (Score:2)
No, the real problem is that a library, Libidn, that's used by resolver libraries including that apparently shipped with systemd
The real real problem is even less severe than that. The bug is in libidn2 not in libidn. Libidn which is what systemd ships with doesn't have the issue. You need to specifically force systemd to use an experimental library that it is not shipped with by default to trigger the bug.
Re:The problem is systemd breaking unexpectedly (Score:5, Informative)
No, the real problem is that Netflix violated RFC 1034 section 3.5 [ietf.org] and RFC 1035 section 2.3.1 [ietf.org], which both explicitly say that hostnames must still conform to the old ARPANET restrictions, which allow only letters, numbers, and hyphens. Underscores have never been legal in DNS hostnames, and in spite of the pain this spec-compliant behavior has caused for some users, the systemd behavior is correct, and Netflix needs to fix whatever broken software they have that incorrectly created an invalid hostname containing an underscore.
The remarkable thing, frankly, is that any DNS resolver resolved that address, and more significantly, that the DNS servers actually responded to the request.
Re: (Score:2)
the systemd behavior is correct
Yes, it is. Well. to the extent that systemd being used by the system for DNS resolution is correct, as opposed to using a real DNS resolver. The extra junk in systemd should only be used to bootstrap containers and VMs and should be replaced during boot with real services. And really, systemd and/or its packagers should ship a version without that crap for people not doing VM/container stuff so it doesn't get in their way or pull in unwanted dependencies.
Re:The problem is systemd breaking unexpectedly (Score:4, Informative)
Apparently you didn't read the RFCs, which do not say at all that "hostnames" "must" conform to anything. What they both say is that compatibility will be maximized if you use the host name syntax. RFC 2181 is also painfully clear that a DNS owner name may contain any octets at all. There is nothing remarkable about servers responding to such host names: they're supposed to.
Indeed the "underscore name" convention is so important that it is how SRV records even work.
_But_, and this is the key point, such names are not legal LDH names, which is what libidn2 is expecting. LDH names contain only letters, digits, and hyphens, and it's a foolish sysadmin who attempts to use some kinds of names (things that resolve directly to A or AAAA and probably CNAME or maybe DNAME and so on) that do not conform to LDH. This fact is what led IDNA to be invented: there's nothing preventing just looking up UTF-8 names in the DNS except that there's a lot of stuff that will probably break.
And there remains the question of why in the heck systemd is involved in all of this. Systemd is the Windows registry of the Linux world.
Re:The problem is systemd breaking unexpectedly (Score:4, Interesting)
RFC 2181 11. Name syntax: The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs. A DNS server may be configurable to issue warnings when loading, or even to refuse to load, a primary zone containing labels that might be considered questionable, however this should not happen by default.
These days, it is up to the client to validate the labels being requested in its own context, but otherwise, anything goes.
The "client" in this instance, has been forced to use a resolver that decides to validate for all clients that may be using it, which is entirely incorrect behavior.
Re: (Score:2)
Indeed. This low level or reliability is _not_ acceptable on Linux. And look, it is the same cretins that have broken other things before. Why is this stuff in distros labeled as "stable" again?
Re: (Score:2)
It doesn't matter if it was an external library that systemd used that's responsible. Systemd is responsible for the problem because it uses this flawed library.
Except it didn't. Systemd uses libidn. You need to specifically compile systemd with 2 separate flags in order to force it to use a library that is marked as experimental.
The real problem is users are stupid and other users justify their actions in an echo-chamber because systemd! *froth from mouth*.
systemd & network layer (Score:2)
Does systemd recognize IPv6? Can that be the issue?
Re: Hey Poettering (Score:3, Informative)
Re: (Score:2)
Sure...in software there's no one to say that you have to program an elegant way to fail when you have what seems like garbage data coming in...except for the fact that the "garbage" data is really what the endpoint is expecting and other, more user oriented systems, handle without any issue. Systemd is behaving like a damn government bureaucracy that is completely detatched from the way the world works.
Also...as has been brought up several times in this post but has yet to be answered: WHAT THE FUCK IS AN
Re:Hey Poettering (Score:4, Informative)
Any explanation for this piece of shit problem, asshole?
Because he's technically correct, which is the best kind of correct... The DNS specification expressly prohibits the use of the underscore character in domain names. It's netflix that's at fault here, more than anything else.
Re:Hey Poettering (Score:4, Insightful)
Underscores are not allowed in top level domains names, for example you can't register example_domain.com.
However, in sub-domains they are perfectly legal. For example: my_subdomain.example.com is perfectly valid.
Re: (Score:3)
RFC 2782 talks about SRV records, which are a different beast than A or AAAA records. SRV records deliberately use the underscore character to emphasize that they should not be resolved by the normal DNS resolution libraries. As per the RFC:
An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature.
RFC 2181 talks about other record types (MX, SOA, NS, PTR, CNAME, and so forth), and just says that the DNS server shouldn't prohibit those types of records.
Re:Hey Poettering (Score:4, Insightful)
Any explanation for this piece of shit problem, asshole?
Yes. libidn2 is not a default and is marked as experimental and not ready for use. Also libidn2 isn't maintained Poettering.
Now what would interest far more people is, do you have an explanation for being an unbearable cunt?