My initial impressions:

1. It will be nice once there are distribution packages for unbound. I spent more time that I would like (which is zero) figuring out where to put the log file, pid file, etc. Of course, I was installing it on a machine running Fedora Core 5…
2. I was forwarding a zone to a nameserver running on localhost:20053. There is a gotcha to doing this, as, by default unbound won’t send any queries to localhost. You have to add a ‘do-not-query-localhost: no’ config line to fix it. Maybe this is something unbound-checkconf could detect?
3. unbound’s configuration defaults leave it locked down fairly tightly. I had it running, but on my other machines, it seemed so slow — turns out, my queries were timing out and I was hitting my ISP nameserver. Make sure you add your networks to the ‘access-control:’ config parameters.
4. I turned up the logging to debug some of my issues. Looking at the log was uncanny.

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.

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.

Mike’s idea was soundly rejected by the IETF working group that it was presented to, DNSEXT. I’ll outline some theories why in a bit. But, its rejection was not because it was a horrible idea. In fact, from some points of view, it is a pretty good idea. In a nutshell, DNSSEC SO says:

• Drop the NSEC (née NXT) or NSEC3 records, and just concentrate on being able to positively verify records, and
• because successful chains of trust through zones don’t actually involve NSEC records, this can coexist with standard DNSSEC.

However, let’s take a look at the main purposes of DNSSEC:

1. Protect legacy and security-unaware Internet applications from DNS spoofing attacks, and
2. Enable new applications to use DNS as security scaffolding.

And now we can see why DNSSEC SO was rejected: it is utterly useless for purpose #1. And, since most new applications have to live an world without universal DNSSEC deployment (SO or otherwise), DNSSEC SO isn’t as useful for purpose #2 as it might be. Let me explain.

Standard DNSSEC (including things like NSEC3) says that DNS responses, after being validated, fall into one of three states (actually four, but never mind): SECURE, INSECURE, and BOGUS. That is: it validated and was signed; it wasn’t signed, but that was proven to be OK; and it failed to validated (for any reason). When a response is BOGUS, the response is withheld from the application. Thus, an unaware application is spared from the effects of the spoofing attack.

DNSSEC SO says that responses, after validation, only fall into two states: SECURE and NOT SECURE. That is: it validated and it was signed; or it wasn’t signed or didn’t validate. So spoofing attacks just get passed on the unaware client, which can’t distinguish them from normal DNS responses.

OK, so what about purpose #2? Imagine an application that might be aware of DNSSEC and might really want to use it for security scaffolding. Let’s call it DKIM, an application that looks up cryptographic keys in DNS for the purpose of deciding to accept or reject email. It might decide that it is only going to use DKIM keys that have been signed and verified by DNSSEC. This is great, and, in fact, DNSSEC SO works here just fine.

However, at this point in time, DKIM cannot afford to restrict itself to only using keys signed with DNSSEC. Even with DNSSEC SO, it is going to take a while to get enough infrastructure in place so that any zone that wants to can be signed and trusted. And DKIM needs as many email senders and receivers to use it as possible.

…

So why was DNSSEC SO rejected by the IETF? I suppose that everyone who spoke up saying “No” has his/her own reason, but my belief was that it was because DNSSEC SO rejects the initial requirement for DNSSEC, and that the initial requirement (purpose #1, above) is still valid. Also, the working group was obviously tired of working on DNSSEC, and DNSSEC SO represented another 6 to 12 month round of effort for what seemed like little gain. In other words, “too little, too late”.

A Brief DNAME Tutorial

Whereas CNAME is used to alias a single domain name to another, DNAME aliases an entire subtree to another. It accomplishes this in one of two ways: either it acts as a CNAME generator, or it is understood by the client and the client implements the same behavior without all the generated CNAMEs.

So, some examples. Imagine that this record exists in its proper place in the DNS:

www.bar.com IN CNAME www.foo.com.

This means that queries for www.bar.com, of any type (A, AAAA, MX, etc.) will get aliased to the same query for www.foo.com. But queries for mail.bar.com (for example) do not. Nor do queries for yyy.www.bar.com. Now imagine a similar usage of DNAME: bar.com IN DNAME foo.com.

Now, the DNAME record will synthesize a CNAME for any query below bar.com. A query for www.bar.com will get aliased to www.foo.com. mail.bar.com will be aliased to mail.foo.com. x.y.a.b.c.bar.com will be aliased to x.y.a.b.c.foo.com. Everything. But, queries for bar.com won’t be aliased at all. DNAME only matches below the name, not at the name.

All in all, a pretty clever idea.

Using DNAME to Create IDN TLDs

So, let’s think of some ways that DNAME might be used. One idea that has been bandied about is to create IDN aliases for TLDs. So, for example, imagine a DNAME that maps ‘xn--c4m’ (somebody feel free to suggest a real punycoded com equivalent) to ‘com’: xn--c4m. IN DNAME com.

The idea being that while the world wants native language versions of com, net, etc, the world doesn’t actually want them to be new TLDs (where amazon.xn--c4m could be different than amazon.com.) So, using DNAME in this way looks great—somebody who registered xn--b7r.com now gets to advertise their domain as bÃ¥r.cøm (or whatever—I’m too lazy to actually use real unicode here, people). When somebody queries for www.bÃ¥r.cøm, this gets converted to www.xn--b7r.xn--c4m IN CNAME www.xn--b7r.com. Not bad, not bad at all. However, what happens when the owner of xn--b7r.com starts thinking of his domain as actually “xn--b7r.xn--c4m” (or bÃ¥r.cøm, since people don’t actually think in punycode…), and creates a subdomain: xn--su9b.xn--b7r.com. IN NS ns1.xn--b7r.xn--c4m. xn--su9b.xn--b7r.com. IN NS ns2.xn--b7r.xn--c4m.

Well, what happens is that this delegation actually doesn’t work. And it doesn’ t work because ns1.xn--b7r.xn--c4m doesn’t actually exist as a name in the DNS. Instead, it is gets converted into a CNAME, and NS record targets cannot be CNAMEs (This is pointed out in RFC 2181, but the real point is that resolvers won’t generally handle this case.) Note that it isn’t that the owner can’t have subdomains. It is that he can’t use the IDN TLD version of his domain the same way as the real one. So, the DNAME based IDN TLD is a second-class citizen, and will probably lead to operational problems as end users fail to realize that this IDN TLD isn’t actually a real TLD, and what the consequences of that are.

Using DNAMEs for Variants

OK, so how about another potential use, instantiating IDN variants? This is slightly different from the case above in that the idea here is to create aliases to existing second level domains as a courtesy. It isn’t really nearly as likely that someone down the road will mistake the DNAME for a real name—this is just to help people who enter a variant get to the right place.

Actually, this idea isn’t really about IDN variants at all. Imagine that you have a bunch of domains of which one is the “real” one, and the rest were just registered to keep other jackasses from registering them and defaming you. Or just registered because people might try to find you under the other domains. For an example, let’s imagine that Amazon has amazon.com (the main zone), amazon.co.uk, and amazonsucks.com, all of which Amazon wants to behave the same. Instead of maintaining a bunch of copies of the amazon.com zone, couldn’t you just leave one “real” and have the rest be DNAMEs? This would make managing these copies so much easier, wouldn’t it?

Well, yes, but…. Since the DNAME doesn’t match at itself, you haven’t aliased the entire zone, since you haven’t aliased the name “amazon.com” itself. Alas, there are always critical records stored at the apex. At the very least, an MX record. So, you haven’t really saved yourself much work, since you will (most likely) have manage the variant zones anyway, just to keep the zone apex in sync.

Another way to accomplish this task is to use the same zone file for all of the variants. BIND, at least, makes this easy: just make sure that everything in the zone is relative to the “origin”. When the file is loaded against different zones, the origin will be set to each zone in turn. (This is a bit like using all relative paths in your HTML and then having the freedom to move the pages around without changing the HTML.)

The Good News

So what is DNAME good for? The canonical use for DNAME is to move zones around in the reverse tree, typically for renumbering. This works better, because the zone apexes in the reverse tree aren’t used much (or at all). It is also useful (although not perfect) in cases where you do not control the zone that you wish to mirror.

I won’t say that DNAME is completely useless—a few people have certainly successfully used it. But, it doesn’t work adequately in situations where no other good solutions exist (IDN tlds), and even where it does work, there is always another way to accomplish the same thing that, generally, isn’t much more work.

Also, that it has been around for six years and hasn’t seen any sort of widespread use is, at least, an indication that DNAME doesn’t solve any pressing problem.

Now, I’m certainly no expert on anycast, but I can see a small kernel of truth buried in the FUD of the doubters.

Anycasting can lead to a false sense of resiliancy.

For example, 2 anycast clouds with 6 instances each is less resilient than 12 separate unicast instances. This is because, from the point of view of the DNS client, there are only two nameservers to contact, and if both go down, the client is hosed. Two failures in the unicast case don’t lead to any noticeable problem.

This isn’t the same as saying that anycasting doesn’t, in general, improve the situation. But it isn’t a substitute for advertising more than, say, two nameservers.

Anycasting can be done poorly.

Imagine having two different anycast addresses, but that each cloud essentially has both addresses in the same rack at every instance. Or even just at some instances. In this case, the amount of redundancy is less than the operator might suppose, and a single power failure (e.g.) could render the zone inaccessible.

Of course, people who set up high-profile anycast DNS service generally know what they are doing and provide sufficiently independent anycast clouds.

It is possible that the use of anycasting can have negative consequences for some people, somewhere.

Ok, so this is the argument put forth by a famous internet troll. (If the phrases “scientific fraud!” and “for spoofing” are familiar, you know who I’m talking about. If not, don’t worry about it.) Basically the theory goes like this:

1. Sometimes DNS must be done over TCP.
2. TCP is stateful.
3. It is possible to have to different anycast instances the same “distance” away.
4. It is possible to have a routing devices that divides packets between these two instances.
5. All of the packets really need to go to the same instance, otherwise the TCP handshake (or whatever) doesn’t complete and the DNS query fails.

And thus, for some people, somewhere, in magic spots on the internet, might find a given anycast address unusable for TCP. The famous internet troll takes this argument to mean that anycast is completely unusable for DNS. Now, keep in mind that, even if you are in such a magic spot, the chances of all of the anycast addresses for a domain suffering from the same problem are extremely small. And keep in mind that the vast majority of DNS queries are over UDP, which doesn’t have this (potential) problem.

I, of course, have no idea if there are actually any such magic spots on the internet.

…But a kernel of truth doesn’t equal truth.

These are just things that could be wrong with an anycast DNS deployment, not that they are. I sympathize with the operators who must defend themselves in the face of clueless folks who make the leap from their being a potential problem to an actual one without actually investigating anything. Nevertheless, I think that it would be better to inform the clueless that the operators are aware of the pitfalls, and thus, have not fallen into them.

It seems to me that when non-experts look at wildcards they come to one of two conclusions:

1. Wildcards don’t match enough.
2. Wildcards match too much.

Don’t match enough

My experience has generally shown that when a naive user is introduced to wildcards, they generally expect the wildcards to apply in more situations than they actually do, leading to long-standing common errors (c.f. RFC 1034, section 4.3.3). The classic wildcard MX:

$ORIGIN example.com
*     IN MX  10 a
a     IN A   1.2.3.4
b     IN A   1.2.3.5
mail  IN MX  b

The naive user generally expects the wildcard to match (c.example.com, MX) (which it will), (a.example.com, MX) (which it won’t), and possibly even (b.a.example.com, MX), but not (mail.example.com, MX).

That is, a possibly more natural interpretation of the wildcard is one of: this is the default MX record for the zone, use it when no other MX in the zone applies.

Match too much

This typically comes up when folks struggle with wildcards interacting with DNS records that use so-called “name hacks”, like the SRV. “Why can’t I have a wildcard SRV?”, they ask. Why cannot a DNS server exhibit a great deal of control over how a wildcard matches? So we see proposals that look like:

_http._tcp.*.example.com. IN SRV ....

where the expected behavior is that (_http ._tcp.foo.example.com, SRV) matches, but (bar.example.com., SRV) does not, and (_smtp ._tcp.foo.example.com., SRV) certainly does not.

The limits of how much control this wildcard mechanism should have are not typically well explored by such proposals. However, the example above might be considered a lower bound of control. An upper bound might be to use regular expressions as wildcard matching rules. (Not that regular expressions represent a real upper limit — any arbitrarily complex language could be defined).

While I personally cannot think of many interesting uses for an expressive (say regular expression-based) selectively matching wildcard, my gut feeling is that there would be.

I do not necessarily think that there is a call for multiple new wildcard mechanisms. The first issue (match too little) could be handled by a zone pre-processor (by which I mean that the desired semantics are expressible using current DNS, but just verbose), and/or a single new mechanism could encompass both behavioral issues.