BIND version 9.9.0a2 was released a few hours ago, and the first change noted in the release notes mentions NXDOMAIN redirection. I groaned. I recall Site Finder, and ICANN was not amused either.

When a recursive BIND name server receives a query which cannot be satisfied (e.g. I search for it will answer with an NXDOMAIN:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56608

That is good. It is good for humans because they realize they've mistyped a name or the domain has gone away, and it is good for programs for similar reasons, particularly because, for automatic submission of data, I don't want that data to be sent to the wrong server.

If I configure my BIND server with the new NXDOMAIN redirection (or worse: if your ISP configures the DNS servers you use with the new NXDOMAIN redirection!), the query is satisfied:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50387
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; ANSWER SECTION:   60   IN   A

The way this works is a BIND administrator can configure a special zone of type redirect. The BIND ARM says:

Provides a source of answers when the normal resolution returns NXDOMAIN. Only one redirect zone is supported per view. allow-query can be used to restrict which clients see these answers. If the client has requested DNSSEC records (DO=1) and the NXDOMAIN response is signed then no substitution will occur.

This zone catches NXDOMAIN responses BIND would typically return to the client and replaces the NXDOMAIN code with an reply containing a record.

Consider the definition of the root zone (.) in the following named.conf snippet:

zone "." IN {
   type redirect;
   file "root.redir";

The file root.redir contains

@       IN      SOA     localhost. root.localhost.  (
                                      1 ; Serial
                                      28800      ; Refresh
                                      14400      ; Retry
                                      3600000    ; Expire
                                      86400 )    ; Minimum
                IN      NS      localhost.
localhost.  IN  A    IN  A
*  IN  A

The wildcard on the last line works. It will catch any NXDOMAIN for the zone and replace it with an answer of type A containing the specified address. It goes without saying, that your ISP can also put just an * into the zone definition ...

This very unfortunate addition to the BIND code makes it even easier for BIND to lie. And it breaks DNSSEC.

Say No to NXDOMAIN redirection.

Flattr this
DNS, BIND, and NXDOMAIN :: 30 Sep 2011 :: e-mail


blog comments powered by Disqus