Bogon filtering for DNS

[gdt]

A while ago I documented how to configure a anycast DNS service. It turned out to be a popular idea, as it breaks the nexus between the address of the service and its location in the network. This is more useful then using a real IP address, having circumstances force you to change the location of the server, and having to find clients which have hard-coded the server's IP address (rather than using DHCP or SLP). It also works fine for other services, such as RADIUS.

Anyway, that paper included the best practices for DNS. As did a AusCERT advisory I wrote some years ago. Those practices included a bogon filtering list.

With the exhaustion of the IANA pool of IPv4 addresses we can give one last issue of the bogon list, containing only the "impossible" networks. This list superceeds that in the two papers.

// RFC5735 Special use IPv4 addresses
// All other address space has been assigned to unicast routing by IANA,
// although some blocks have been held back for special purposes by the
// various regional internet registries.
acl "bogon" {
   0.0.0.0/8;          // Null, RFC1122
   10.0.0.0/8;         // Private network, RFC1918
   127.0.0.0/8;        // Loopback, RFC1122
   169.254.0.0/16;     // Link-local network, RFC3927
   172.16.0.0/16;      // Private network, RFC1918
   192.0.0.0/24;       // Protocols, RFC 5736
   192.0.2.0/24;       // Documentation, RFC1166
   192.88.99.0/24;     // 6to4 can't be src_addr, RFC3068
   192.168.0.0/16;     // Private network, RFC1918
   198.18.0.0/15;      // Benchmarking, RFC2544
   198.51.100.0/24;    // Documentation, RFC5737
   203.0.113.0/24;     // Documentation, RFC5737
   224.0.0.0/4;        // Multicast can't be src_addr, RFC3171
   // 240.0.0.0/4         Class D is for future use, maybe routable, RFC3171
   255.255.255.255/32; // Limited broadcast, RFC919
}; 

options {
   blackhole {
      bogon;
   };
};

As with all these lists, you should read it first. Maybe you want to allow 127.0.0.1/32 when seen from the machine's own interfaces, so you can do "dig @localhost" when investigating issues (and if you want to do that, then BIND has a nice "localhosts" in-built ACL which includes all of the IP addresses of all of the interfaces on the machine [1]). Maybe you use private addressing, and so don't want to filter all of those.

As a side note, a researcher contacted me explaining that I had the first published use of the work "bogon" in a routing context and if I knew its origin. I'm afraid not. It's use was widespread in computing and electrical engineering talk at the time: a spike on a voltage would be described as being caused by a "bogon particle". In a routing context, the mix of "bogus" and "Vogon" caught my imagination (badly behaved routes arriving from beyond the solar system, with poor poetry to boot). As it did for a lot of people at about the same time. The Bogon List from Team Cymru turned it from a quip to a usage, so they are really the etymologcal source.

---
[1] Cisco and Juniper take note. This in-built ACL would make writing ACLs to limit access to the control plane of the router a thousand times simpler.