IMPORTANT: base-dns update (please read!)

Posted by: mstauber Category: General

IMPORTANT UPDATE: If you operate a DNS server om BlueOnyx, please read this!

The following updates have been released:

bind 9.8.2-0.17.rc1.4 (5106R):

This update contains a much newer BIND DNS server than usually found on a BlueOnyx 5106R. Usually an updated CentOS5 has Bind 9.3.2 installed. But we recompiled the BIND from RHEL6 for usage on BlueOnyx 5106R and will from now on distribute it through the BlueOnyx 5106R YUM repository.

base-dns (5106R, 5107R + 5108R):

This is the important update, so please read carefully:

In the past the DNS server on BlueOnyx (once enabled) would by default allow 'cache' or 'recursion' access. So anyone could use it to resolve DNS - even for zones that you did not have DNS records for. Yes, there was the GUI option to disable this. However, many people might not have been aware of the implications of running an open DNS server. So there is a large likelyhood that many BlueOnyx servers that are used for DNS are running as open DNS servers.


Upon installation and if the DNS server is running, it will be modified to only allow 'cache' or 'recursion' access from localhost (''), but not from anyone else. It will still respond to all queries that you have DNS records for. But for nothing else, unless your own server queries itself.

If you have tied other servers or PC's into your BlueOnyx DNS server for general DNS resolving, then their access will be blocked. However, the modified BlueOnyx GUI for DNS management now allows you to specify IP address ranges for which 'cache lookups' or 'recursion access' can be allowed.

This is how the old DNS managements 'advanced' tab looked like:

This is how the new 'advanced' DNS management looks like:

Both screen shots show the 'default' settings and when you click on them, you can see a larger version of these images in a new browser window.

What has changed?

1.) Allow DNS Query Access: Enabled by default. Enables DNS query access in general.

2.) Allow Queries from Everyone: Enabled by default. Allows anyone to query your DNS server.

3.) Allow Queries from these Networks (optional): Default entry is '', which means "localhost', so that your server is allowed to query itself. If you have 'Allow Queries from Everyone' ticked, your DNS config file will automatically be updated to allow access from '' as well, which means everyone in the internet can query your DNS server.

4.) Allow DNS Cache Access: If enabled, your DNS server will allow 'recursion access' or 'cache lookups' and will resolve DNS for zones that you are not authoritative for, too. However, by default only for '', which is 'localhost'. So your BlueOnyx can use your own DNS server to lookup DNS information that you have DNS records for.

BUT: Make sure to enter the IP address '' on your BlueOnyx into 'System Settings' / 'TCP/IP' / 'DNS Servers' as '' and don't use the public IP address of eth0 for that!

5.) Open DNS Server (Not recommended!): This is almost self explaining. If this box is ticked, your DNS server is turned into an open DNS server that can be queried by anyone for everything. Which is bad. We explain further below why this is bad. Do not tick this box unless you have read about the implications!

6.) Allow Cache access from these Networks (optional): In this input field you can enter the network address ranges of servers that are allowed to use your DNS server for 'recursion access' or 'cache lookups'. So here you would enter the IP network address ranges of other servers or PC's that are allowed to use your DNS server for lookups of all domains- even if you don't have records for these zones. By default only '' (i.e.: 'localhost') is entered here.

Why are 'open' DNS servers bad?

By now you might have heard about the ongoing DDoS-attacks that use open DNS servers to harm innocent bystanders. Various BlueOnyx servers (with open or closed DNS servers) have been used in this attack as well.

Some examples of the most recent news:

In a very short summary: DNS servers use the UDP protocol for most communications. UPD packets can easily be spoofed, so that they seem to be from some other source than they really come from. If 'person A' sends a forged UDP DNS request to your server and requests the zone file of the 'root' DNS zone from your DNS server, then your server (if it is open) sends a very large response to this very short question. If the originating IP address of the request was forged, an innocent bystander gets bombarded with your DNS servers response.
Even if 'caching' or 'recursion' is turned off, or restricted to certain trustworthy networks, an attacker can still request the zone file of one of the domains that you are authoritative for. However, that response is a lot smaller than for the 'root' zone, as it contains less data. Still, this is bad enough for you and for the innocent bystander who gets hit during this attack.
This is basically a fundamental design flaw of the DNS protocol itself.
To limit a large degree of that fallout we therefore now enforce that DNS servers on BlueOnyx operate with stricter defaults than before. You can still turn it into an semi-open or fully open DNS server if you want, although we do not recommend that.
To further limit the impact of the DDoS attacks, the new DNS GUI allows you to configure two additonal settings, which were recently added to Bind:
1. ) Rate Limits Enabled: If ticked (by default it is) the new and experimental rate limits in Bind are enforced.
2.) Responses per Second: Responses-per-second is a limit on identical responses instead of a limit on all responses or even all responses to a single client. 10 identical responses per second is a generous limit except perhaps when many clients are using a single IP address via network address translation (NAT). The default limit of zero specifies an unbounded limit to turn off rate-limiting in a view or to only rate-limit NXDOMAIN or other errors.

3.) Window: Rate limiting uses a credit or token bucket scheme. Each identical response has a conceptual account that is given RESPONSES-PER-SECOND and ERRORS-PER-SECOND credits every second. A DNS request triggering some desired response debits the account by one. Responses are not sent while the account is negative. The account cannot become more positive than the per-second limit or more negative than window times the per-second limit. A DNS client that sends requests that are not answered can therefore penalized for up to window seconds even after the abusive query flow stops.

Lastly, you can now enable 'Extended DNS logging', which will log all DNS queries to /var/log/messages. Only enable it for debugging, as it will create a lot of log entries very quickly. Be sure to turn it off again ASAP.


We would like to offer our sincere apology in case that the changed behaviour of your DNS server created any hardships for you. But please understand that it is important that DNS servers need to be properly secured, or the internet as a whole is at risk.

Thank you for reading this and for your understanding. 

Apr 1, 2013 Category: General Posted by: mstauber
Previous page: Development Next page: Mailing List