LWN: Comments on "A DNS flag day"

A DNS flag day

Cyberax — Tue, 05 Mar 2019 09:28:08 +0000

The problem is not Ethernet per se. It's the most ubiquitous medium of transfer but it's by no means the only one. There's also MPLS and even VPNs can be thought as if they are very complicated L2 networks.

The first issue is that IPv6 actually had not solved the problem of multihoming and roaming. It totally could have, without changing the Ethernet layer. But unfortunately, the IETF did not have foresight for this. QUIC (and HTTP/3) are attempting to fix this, but it's probably too late.

The second issue is hierarchic adressing. Ethernet addresses are flat, they don't have any structure. IPv6 -could- have been used to allow automatic hierarchic delegation: your router gets IPs from the ISP and delegates a part of the address space to a smart light switch, a smart switch then acts as a gateway for power line network, giving out each smart light bulb a separate IPv6 subspace, and so on.

IPv6 theoretically supports this with DHCP PD, but... there's not enough bits in IPv6 for it! You will at most get a /48 from your ISP, which only gives you 16 bits to play with. And /56 or even /60 allocations are not at all uncommon. Also, even the DHCP PD standard was finalized only in 2003.

A DNS flag day

immibis — Tue, 05 Mar 2019 07:42:19 +0000

Removing Layer-2 networking (and therefore ARP) is just not going to happen - it's too entrenched in existing hardware and protocols.
Five years ago as a university student, I would've agreed with you.
Now, as a software engineer at a networking hardware vendor, I know there's just no way, because things are too tangled already.

Even if not for that, you'll just end up in an XKCD 927 situation. Adding the new option of {IPv6 + let's call it "IPv6L2"} does not make the {IPv6 + Ethernet} option go away. You weren't crazy enough to think I'll throw out my hundreds or thousands or millions of dollars of Ethernet NICs and switches and routers were you? The *very best* case is that I keep all that equipment and it interoperates nicely with IPv6L2. And at that point why shouldn't I keep getting Ethernet equipment so I only have one L2 protocol to manage?

It's not that Ethernet and ARP are good, but at the very least, they're not all that harmful and they're entrenched, so good luck getting rid of them now. It's like saying the next version of Windows will run on RISC-V.

And what the heck will you do if I want to run it over Infiniband? And in the future someone will want to unify Ethernet with IPv6L2...

A DNS flag day

nybble41 — Tue, 05 Feb 2019 16:45:45 +0000

Assuming they already know your assigned IP range, does always responding to incoming connections with ICMP forbidden (including for unknown internal IPs) really leak significantly more information than silently dropping the packets?

A DNS flag day

JFlorian — Tue, 05 Feb 2019 15:22:58 +0000

My understanding of this is that it's all about information disclosure. In other words, it's best practice to fail hard with ICMP forbidden on internal facing connections, but to silently drop on external ones. Is there a strong argument that ICMP forbidden in both directions doesn't really present any additional risk? I certainly get the advantages (I've been caught out by my own firewall rules more times than I can count), but the disadvantages can be of the type you don't know until you've been burned.

A DNS flag day

emmanuelF — Thu, 31 Jan 2019 15:27:13 +0000

Sorry, correction :
"the solution is to disable the EDNS support." -> "a (bad) solution is to disable the EDNS support."

A DNS flag day

emmanuelF — Thu, 31 Jan 2019 14:52:12 +0000

Please note that even a compliant DNS dating "before edns existence" will not be disturbed by a edns request and give proper/compliant answer.
You are not forced to deploy an EDNS aware DNS server.
The problem is just non compliant DNS servers (edns aware or not) and non compliant/non transparent middle boxes/firewalls.
For some authoritative server buggy EDNS implementation, the solution is to disable the EDNS support.

The phrase
"The problem that has led to the flag day stems from DNS servers that do not implement the "Extension Mechanisms for DNS", also known as EDNS(0) or just EDNS"
is wrong and misleading.
EDNS is completely backward compatible with plain non EDNS aware servers.

A DNS flag day

intgr — Tue, 29 Jan 2019 23:51:53 +0000

> Hi, firewalls!

This!

ICMP provides a perfectly good mechanism to report back forbidden packets. But for some odd reason it's considered best practice to instead blackhole disallowed packets.

In more than one case, a missing firewall rule and the blackhole approach together turned a simple mistake into a cascading failure of multiple systems waiting for timeouts.

A DNS flag day

mpr22 — Sun, 27 Jan 2019 10:30:06 +0000

Define "made accountable".

Ideally, in a way that still makes people want to work in that IT department.

A DNS flag day

marcH — Sat, 26 Jan 2019 23:29:38 +0000

> 4.1. Fail Fast and Hard
> Protocols need to include error reporting mechanisms that ensure
> errors are surfaced in a visible and expedient fashion.

Hi, firewalls!

Is there any big company where the IT department can be made accountable for severe losses of productivity? Curious whether they have any job offers right now.

A DNS flag day

biergaizi — Sat, 26 Jan 2019 20:29:25 +0000

A DNS flag day

biergaizi — Sat, 26 Jan 2019 19:48:58 +0000

The Harmful Consequences of Postel's Maxim
https://tools.ietf.org/html/draft-thomson-postel-was-wron...

2. The Protocol Decay Hypothesis

[...]

An implementation that reacts to variations in the manner advised by
Postel sets up a feedback cycle:

o Over time, implementations progressively add new code to constrain
how data is transmitted, or to permit variations what is received.

o Errors in implementations, or confusion about semantics can
thereby be masked.

o As a result, errors can become entrenched, forcing other
implementations to be tolerant of those errors.

An entrenched flaw can become a de facto standard. Any
implementation of the protocol is required to replicate the aberrant
behavior, or it is not interoperable. This is both a consequence of
applying Postel's advice, and a product of a natural reluctance to
avoid fatal error conditions. This is colloquially referred to as
being "bug for bug compatible".

3. The Long Term Costs

Once deviations become entrenched, there is little that can be done
to rectify the situation.

For widely used protocols, the massive scale of the Internet makes
large scale interoperability testing infeasible for all a privileged
few. Without good maintenance, new implementations can be restricted
to niche uses, where the prolems arising from interoperability issues
can be more closely managed.

[...]

Protocol maintenance can help by carefully documenting divergence and
recommending limits on what is both acceptable and interoperable.
The time-consuming process of documenting the actual protocol -
rather than the protocol as it was originally conceived - can restore
the ability to create and maintain interoperable implementations.

Such a process was undertaken for HTTP/1.1 [RFC7230]. This this
effort took more than 6 years, it has been successful in documenting
protocol variations and describing what has over time become a far
more complex protocol.

4. A New Design Principle

The following principle applies not just to the implementation of a
protocol, but to the design and specification of the protocol.

Protocol designs and implementations should be maximally strict.

Though less pithy than Postel's formulation, this principle is based
on the lessons of protocol deployment. The principle is also based
on valuing early feedback, a practice central to modern engineering
discipline.

4.1. Fail Fast and Hard

Protocols need to include error reporting mechanisms that ensure
errors are surfaced in a visible and expedient fashion.

4.2. Implementations Are Ultimately Responsible

Implementers are encouraged to expose errors immediately and
prominently in addition to what a specification mandates.

4.3. Protocol Maintenance is Important

Protocol designers are strongly encouraged to continue to maintain
and evolve protocols beyond their initial inception and definition.
If protocol implementations are less tolerant of variation, protocol
maintenance becomes critical.

A DNS flag day

naptastic — Sat, 26 Jan 2019 15:30:39 +0000

Hey everybody: Can we do this with IPv6 too? Please? <3

A DNS flag day

jani — Fri, 25 Jan 2019 06:10:46 +0000

The Crapustness Principle: The software design guideline based on the illusion of ability to happily process any crap that you're given as if it was actually meaningful. This is when GIGO and the robustness principle collide.

djbdns

mirabilos — Thu, 24 Jan 2019 14:04:48 +0000

Ah: “day must not have timeout result in any of plain DNS and EDNS version 0 tests” so no, I don’t.

djbdns

mirabilos — Thu, 24 Jan 2019 14:03:00 +0000

I may need some help interpreting the output of the EDNS tester.

I run djbdns, which provides an axfrdns(1) utility that listens on TCP port 53.

The results are:

dns=ok edns=noopt edns1=noerror,noopt,soa edns@512=noopt ednsopt=noopt edns1opt=noerror,noopt,soa do=noopt ednsflags=noopt docookie=noopt edns512tcp=noopt optlist=noopt

Do I need to worry?

A DNS flag day

farnz — Thu, 24 Jan 2019 13:06:59 +0000

There's a pattern in slightly counterintutive results for software engineering here:

It's better to build your software to crash as soon as it detects a broken invariant, than to try to carry on despite the problem.
It's better to build on top of multiple low-reliability computers and design the system to cope when one fails unexpectedly than to build atop a highly reliable system and cope when it goes down for maintenance.
It's better to be pedantic about what you accept and cope with the resulting failure, than to be liberal and then tolerate bad implementations.

I'm sure there's other cases where the long-term results of failing fast are better than trying to push on past a failure.

A DNS flag day

peter-b — Thu, 24 Jan 2019 10:26:18 +0000

> https://en.wikipedia.org/wiki/Robustness_principle#Criticism
> (conservative in what you do, liberal in what you accept)

Over time, I've come to be of the opposite view: be absolutely pedantic about what you accept, and occasionally evil in what you send (so that there's a cost to implementations that aren't pedantic about what they accept).

This is the real way to end up with robust, reliable and well-tested software. The "robustness principle" leads to a race to the bottom where everyone adopts a "screw it, it's good enough, so why pay attention to getting the corner cases right?"

A DNS flag day

marcH — Thu, 24 Jan 2019 05:41:30 +0000

> In some ways, this provides an object lesson in the perils of working around buggy implementations. Those workarounds eventually get cast in stone, which allows oblivious users (and vendors) to keep rolling along without dealing with the shortcomings of the software they provide or run. That can stifle innovation and, ultimately, prevent more secure options from being deployed.

https://en.wikipedia.org/wiki/Robustness_principle#Criticism
(conservative in what you do, liberal in what you accept)