please review Bv9ARM-book changes for integrating AusCERT AL-1999.004

[Andras Salamon]

Jeremy,

On Thu, Apr 26, 2007 at 01:01:54PM -0500, you wrote:
> What shouldn't be included in the 
> Bv9ARM-book.xml? What needs to be rewritten or improved? Does the AusCERT 
> AL-1999.004 even matter in 2007?

A lot of this is redundant considering the rest of the ARM.

> ??? TODO: is above still true? relevant?

As far as I know, yes -- but I am not familiar with how widely used
ingress filtering has become in the intervening period.  The people
on DNSOP might be able to help with that.  My impression is that this
is less of an issue than it used to be, and that DDoS vectors have
mostly moved on to other services.

> 9.2.1 (1) Queries for Any Name
> 
> Allow queries from "trusted" sources only. Trusted 
> sources are defined as hosts for which the DNS server 
> provides recursive DNS name resolution. These hosts 
> would usually lie within an ISP's or enterprise's 
> network. These hosts usually have the DNS server listed 
> in a configuration file such as /etc/resolv.conf or 
> supplied to it in a PPP, DHCP or BOOTP response. Allow 
> no zone transfers.

"Queries for Any Name" is misleading.  What is discussed here is
recursive service, when the "Recursion Desired" flag is set in
the query.  Bad terminology then leads to incorrect conclusions in
this section.

Recalling that the section title is:

> 9.2 Preventing Denial of Service (DoS) attacks

not allowing zone transfers seems completely unnecessary to address
the concern about DDoS.  Zone transfers are done via TCP, which
means attempts at zone transfers will fail (whether allowed or not)
as soon as the target receives the first packet from the name server.
I don't think there is any significant difference in the traffic
generated by attempts to transfer a zone initiated by a faked IP
address, whether the transfer is allowed or disallowed.  There might
be good reasons to disallow zone transfers but these have little to
do with preventing DDoS.

Moreover, there is no reliable way to identify a query with a fake
source IP address by just looking at the packet itself.  This is why
the real way to fix the DDoS problem (which affects all services, not
just DNS), is via ingress filtering at the ISP.  The ISP can easily
prevent packets with bogus source addresses from getting into the
network in the first place, since they know the range of addresses
they are expecting from a gien link, but once these packets are in
the network it is essentially impossible to identify them in isolation.

> A "primary zone" is a zone for which a server has the 
> DNS master file described in RFC1035 and the server is 
> one of the name servers that has been delegated the domain.

"Primary" is now obsolete terminology.  This should be "authoritative".
Also, whether the name server has been delegated or not is irrelevant.
The main issue is whether the server itself thinks it has a copy of
the zone file.  Many servers are authoritative for some zones and
also provide recursive service, some servers are auth-only and others
are recursive-only.

By splitting off the various variants of how people might use
authoritative servers into separate largely redundant sections,
the main issues are obscured.

The example for the authoritative case also misses the point of the
"bogon" list in the first example.  The bogon list applies equally
well to all servers on a public network, perhaps with exceptions for
blackholing private RFC1918 networks if the server is accessible both
from the Internet and private networks using RFC1918 addresses.

> 9.2.3 (3) Queries for Names in Official Secondary Zones

"Secondary" is not only old terminology but the distinction
primary/secondary is irrelevant, see "authoritative" above.

> 9.2.4 (4) Queries for Names in Stealth Secondary Zones

Ditto.

> It is administratively useful to allow DNS zone 
> transfers between all primary and secondary DNS 
> servers. This eases the debugging of zone transfer faults.

Why put this kind of text in a section about preventing DDoS?

General advice about designing name service for a site, such as
considering splitting recursive and auth-only servers, is valuable
in a document like the ARM.  But it doesn't belong in this section.

> *** TODO: check this: A C source code patch must be applied 
> to all BIND 8.2.1 servers for the configuration 

I seem to recall BIND 8.4.7 was the last release of BIND 8, 8.2.1 is
almost certainly deprecated.

> 9.3 Limiting Version Number Availability
> 
> Allowing the version number of any software to be known 
> to everyone is usually undesirable.

This is a point that can be debated.  An example of how to turn it
off is useful, a diatribe about why it should be turned off is not.

> 9.5 Controlling Visibility of DNS Servers
> 
> As a result, these servers can be used to amplify 
> DNS-based denial of service attacks even if all the DNS 
> servers owned by the ISP regulate the source of DNS queries.

More simply, many organizations may want to consider blocking UDP
queries to port 53 directed to hosts inside their network.  The easiest
way to achieve this is to place the delegated name servers outside
any kind of firewall, then block incoming UDP to port 53.  DNS is
the same as any other service in this regard.  The only issue that
is special is that some name servers (for instance, older versions of
BIND) issue queries from port 53, and these need to be worked around
either as filter exceptions or through redesigning how queries are
forwarded (for instance, older servers can be configured to send all
recursive queries to a BIND 9 server which then makes queries using
dynamic ports > 1023).

Regards,

-- Andras Salamon                   andras at dns.net