davidb dives in

I feel sick, but not as sick as I could feel.

Update: Duke 67, WVU 73. Sigh.

Ben Laurie celebrates the publication of RFC 5155. I hadn’t gotten around to blogging about it, but I’m also pretty happy that this RFC finally made it out.

Ben says:

It turns out that in general, to prove the nonexistence of a name using NSEC you have to show at most two records, one to prove the name itself doesn’t exist, and the other to show that you didn’t delegate some parent of it. Often the same record can do both. In NSEC3, it turns out, you have to show at most three records. And if you can understand why, then you understand DNS better than almost anyone else on the planet.

One of the fascinating things about working on NSEC3 was that it forced us to really understand how existence in DNS works. Basically, we had to develop the general form of the theory when we already had a special case (in NSEC). So, after we figured out how NSEC3 had to work, we actually knew more about how NSEC worked.

For me and our co-editor Roy, this RFC culminates the 2nd round of working on the some of the problems that NSEC3 solves. The first effort was “DNSSEC Opt-In”, now published as an experimental RFC, RFC 4956. (That effort was also tied up in DNS minutiae and political wrangling and ultimately failed to make the IETF standards track). For us, it feels more like the culmination of 7 years of work.

I’m at the IETF this week, and so I get to turn my brain to thinking about IETF-y things, like Internet Drafts that I think should (and could) be written.

Idea #1: Cache Poisoning Resilience

This would be a draft that describes steps beyond RFC 2181 that a resolver must do to protect itself from cache poisoning. (RFC 2181 addresses this problem by introducing credibility rules in section 5.4.1.) Modern caching resolvers need to do more to protect themselves from name poisoning attacks like malicious CNAME chains. I would expect this draft to be able to lay out a few simple rules like:

• Discard any RRs in a response that are “irrelevant” (i.e., answer RRs that do not match qname/sname, addtional RRs that don’t match names in the RDATA of answer and authority RRs, etc.)
• Discard any RRs in a response that are not at or below the queried zone.

Idea #2: Authoritative Servers Should Not Chase CNAMEs

This is a draft discouraging authoritative servers from chasing CNAMEs out-of-zone (or, optionally, at all), based on conclusions presented in draft idea #1. This draft could either side-step or confront other possibly controversial things about CNAME processing, like whether or not the authority section should apply the head or the tail of a CNAME chain.

Idea #3: DNS Name Compression Standards

A draft mandating the DNS name compression only be done in one direction. Virtually all (or perhaps even actually all) implementations have DNS compression pointers only pointing to earlier in the message. This draft would propose that forward-pointing compression pointers should be treated as format errors. This would accomplish two things:

1. Simplify what implementers need to support when parsing messages, and
2. outlaw any possibility of having to deal with a compression pointer loop.

And, in the process, effectively codify standard practice.