Slashdot Mirror
DNS Lib Underscore Bug Bites Everyone's Favorite Init Tool, Blanks Netflix (theregister.co.uk)
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.
It's abundantly clear that systemd-resolved has quickly become a train wreck. It's inclusion in Ubuntu 16.10 was widely lamented and many folks have pointed out huge concerns for several different assumptions that it makes for fallbacks and erroneous configurations. That's not including the several different bugs 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.
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.