11

I have Ubuntu 16 LTS

What is the purpose 0.in-addr.arpa and 255.in-addr.arpa zones in bind's default configuration?(named.conf.default-zones)

I ask here because think that these zone files are common across bind's packages on various GNU/Linux distributions, not Ubuntu specific ones.

Bulat M.
  • 287
  • 1
  • 5
  • 18

2 Answers2

15

This from here (an MS page, but still relevant):

Reverse lookup zones enable the DNS server to be authoritative, that is, to know the answer in advance and to respond immediately to the most common name queries, eliminating unnecessary recursive queries. In accordance with pertinent Requests for Comments (RFCs), by default, the DNS server is authoritative for three reverse lookup zones:

0.in-addr.arpa (0.0.0.0)

127.in-addr.arpa (127.0.0.1 - loopback)

255.in-addr.arpa (255. 255. 255. 255 - broadcast)

In other words; the DNS server will not query an Internet based DNS server for those addresses (as they are all local addresses).

Darren
  • 2,722
  • 1
  • 18
  • 31
  • Darren, I understand how DNS reverse works, and how reverse addersses are specified, but I wonder what is the sense of querying IPs like 0.x.x.x or 255.x.x.x, really odd use case, it seems. What are use cases for it? – Bulat M. Jan 16 '17 at 12:20
  • 3
    @BulatM.: I don't think anyone would do it deliberately, but such addresses may be caught in a more general-purpose tool, or it may happen by accident. When it does, you want the correct results. So why not implement this? – Lightness Races in Orbit Jan 16 '17 at 12:22
  • @Lightness, you mean, it's useful for making kind a "blackhole", to note waste bandwith making meaningless queries? – Bulat M. Jan 16 '17 at 12:41
  • 3
    @BulatM.: I think you're looking at this backwards. You're trying to find a use case. Instead, we do things correctly per specification, then every conceivable and inconceivable use case is covered by default. – Lightness Races in Orbit Jan 16 '17 at 12:50
  • Yes, it is better to stick to some(even not very good) specs than not to stick to any. – Bulat M. Jan 16 '17 at 13:10
  • 1
    Well 255.255.255.255 is a broadcast address so could be used in e.g. network discovery. 0.0.0.0 is a bind address - a service listening on that address in listing on all network interfaces so it's unlikely anything would try to send traffic to that address. – Darren Jan 16 '17 at 13:29
  • 4
    But it's perfectly reasonable to have for example a tool that shows you all listening processes on your pc and the ports, ip-addresses they are bound to and **matching rDNS hostname**. Such a tool will quite often try to find the hostname for "127.0.0.1", "0.0.0.0" etc. And this is just the first example I came up with. – Josef Jan 16 '17 at 14:13
  • 8
    "quite often" is a bit of an understatement. [Up to 7% of the total traffic arriving at some root servers consists of reverse queries for private IP addresses, and a complete routing infrastructure (AS112) has been constructed just to handle this problem](http://archive.oreilly.com/pub/a/sysadmin/2007/04/26/5-basic-mistakes-not-to-make-in-dns.html) – Calimo Jan 16 '17 at 15:18
  • @Darren this is a pretty out of date document, and certainly not definitive w.r.t BIND itself. – Alnitak Jan 17 '17 at 00:04
  • 1
    @Alnitak. Please define "out of date" when we're discussing a protocol that's over 30 years old. I don't think much has changed in the basics of DNS recently. Also, no, not specific to Bind, but all DNS servers. – Darren Jan 17 '17 at 07:10
  • 2
    @Darren it's out of date because the list of zones recommended by the IETF and maintained by IANA contains about 30 entries, not just the 3 mentioned by Microsoft. This particular topic _has_ changed quite a bit recently, and the links I've included in my answer are the definitive references. I can't answer for the other popular resolvers, but BIND does this by default for the whole IANA list. – Alnitak Jan 17 '17 at 09:01
  • 1
    @Alnitak, OK, fair enough. But the original question was only about the ones mentioned in the MS article. – Darren Jan 17 '17 at 09:02
1

The purpose of the default local zones in BIND is to stop queries for those IP ranges from leaking out onto the global internet, and to reduce load on the root name servers, per RFC 6303 "Locally Served DNS Zones".

From the introduction to that RFC:

This recommendation is made because data has shown that significant leakage of queries for these namespaces is occurring, despite instructions to restrict them, and because it has therefore become necessary to deploy sacrificial nameservers to protect the immediate
parent nameservers for these zones from excessive, unintentional query load [AS112] [RFC6304] [RFC6305]. There is every expectation that the query load will continue to increase unless steps are taken as outlined here.

Additionally, queries from clients behind badly configured firewalls that allow outgoing queries for these namespaces, but drop the responses, put a significant load on the root servers (forward zones but not reverse zones are configured). They also cause operational load for the root server operators, as they have to reply to enquiries about why the root servers are "attacking" these clients.

This should be considered the definitive reference, not least because the RFC was written by Mark Andrews, one of the main developers working on BIND.

See also the IANA Registry of Locally Served Zones, which contains the list of all (reverse) zones that should be served like this.

Since the release of BIND 9.9 in 2011, BIND9 automatically creates the default local zones at startup time, unless explicitly turned off with the empty-zones-enable flag in the named.conf file.

The IANA registry is tracked by ISC and new entries added to the current BIND sources as and when they appear.

Community
  • 1
Alnitak
  • 776
  • 6
  • 9
  • So you've said the same thing as my answer but in a different way, but my answer is "out of date"? – Darren Jan 17 '17 at 07:12
  • @Alnitak, so one should include these zones in BIND, so that it can handle such queries without forwarding to root servers? – Bulat M. Jan 17 '17 at 14:14
  • @Alnitak, I mean, one should uncomment //include "/etc/bind/zones.rfc1918"; in /etc/bind/named.conf.local? – Bulat M. Jan 17 '17 at 14:24
  • 1
    @BulatM. with modern BIND versions it shouldn't be necessary - they'll be enabled automatically at start up, unless they've been disabled by your distro package with the `empty-zones-enable` setting in `named.conf`. The list of empty zones should appear in your syslog output when BIND starts. – Alnitak Jan 17 '17 at 14:54
  • 1
    @BulatM. the automatic creation of default local zones was introducing in BIND 9.9, in 2011, BTW. – Alnitak Jan 17 '17 at 14:59
  • And what is the purpose of "include "/etc/bind/zones.rfc1918", if it does the same thing as `empty-zones-enable`? How do they correlate? – Bulat M. Jan 17 '17 at 15:29
  • 1
    @BulatM. depends on the BIND version - if it's 9.9 or later then there's no need for that `include`. – Alnitak Jan 17 '17 at 16:48
  • "They also cause operational load for the root server operators, as they have to reply to enquiries about why the root servers are "attacking" these clients." - I would sure hope that anyone smart enough to detect such an "attack" is smart enough to realise that *replies to requests they sent* aren't actually an attack... – user253751 Jan 18 '17 at 23:14
  • @user20574 you'd be surprised - when I was running technical operations myself I used to hear this sort of complaint all the time. – Alnitak Jan 19 '17 at 10:42