Domain Name System protection

Mailman List Mirror (Read Only)
1

Hi,

We are trying to extend our DNS service system in near
future. In current stage, it consist of 2 SUN FIRE
Server with Solaris8 and BIND9 installed. Each server
is configured with a IP address which is known to our
customers. The DNS server is set up as Cache Server
because it only servers our customers to lookup domain
names.

We noticed there is continous name resolution requests
from IP address outside of our address pool and also
there is requests not conforming to DNS documents (
like those from 10/8, 192.168/16 or something for
microsoft proxy server name). We think these request
waste our resource and we don't want these system
stable, secure and high performance.

The amount of DNS requests processed in past week is
about 0.8Billion.

What I'm not sure with designing new Cache Server farm
is :

1. Is that really required to protect DNS server by
firewall? How does those ISPs, e.g. AT&T, Sprint,mae
their DNS system highly available? Could we do that
by filtering traffic besides port destinated to port
53?

2. How could we extend our server farm by adding new
servers while announcing the same IP addresses to our
customers?

3. Is there any evaluation result of DNS server
software? e.g. performance, resource required,
stability, security etc.?

4. Which hardware/OS platform is better for DNS
service?

5. Is that possible to filter those requests not
conforming to DNS documents?

Each word will be highly appreciated!

Joe

2

1. Is that really required to protect DNS server by

    > firewall?

Yes, it's a very, very good idea to do so.

    > How does those ISPs, e.g. AT&T, Sprint,mae
    > their DNS system highly available?

By protecting it with a firewall. :slight_smile:

    > Could we do that
    > by filtering traffic besides port destinated to port
    > 53?

Yes, exactly. And possibly also by creating two different pools of DNS
servers: one pool which is accessible from everywhere, and which is
authoritative for your and your customers' domains; the other which is
accessible only to your customers, and which performs recursive resolution
on their behalf.

    > 2. How could we extend our server farm by adding new
    > servers while announcing the same IP addresses to our
    > customers?

By doing exactly that. Sharing one IP address across many servers is
called "anycast" and is standard practice for DNS service provision.

    > 4. Which hardware/OS platform is better for DNS
    > service?

The combination you've got, Solaris 8 and BIND 9, is fine. Some people
would use other DNS server software, and some people would use FreeBSD or
NetBSD, but you've got a very mainstream combination. We run Solaris 9
and Bind 9 on about forty DNS servers, for instance.

    > 5. Is that possible to filter those requests not
    > conforming to DNS documents?

That's a lot tougher. Are you asking whether it's possible to have an
application-layer firewall screen out mal-formed requests _before they get
to your DNS server_? That's theoretically possible, but I don't know of
anyone who does it. Once the queries have arrived at the DNS server, the
DNS server application may be able to filter them in different ways, and
discard different classes of queries with different kinds of logging or
notification.

                                -Bill

3

Joe Shen wrote:

We noticed there is continous name resolution requests
from IP address outside of our address pool and also
there is requests not conforming to DNS documents (
like those from 10/8, 192.168/16 or something for
microsoft proxy server name). We think these request
waste our resource and we don't want these system
stable, secure and high performance.

If the resolver caches are only supposed to be accessed from your IP space, I am sure you can easily throw in a router ACL to accept connections on port 53 only from these IPs.

Oh, and filter out bogons at your borders while you are at it (like for example rfc1918 source addresses from outside your network)

  srs

4

See, for example:

   http://www.isc.org/pubs/tn/isc-tn-2004-1.html
   http://www.isc.org/pubs/tn/isc-tn-2004-1.txt

   http://www.isc.org/pubs/pres/USENIX/2004/usenix-isc-dns-dist.pdf
   http://www.isc.org/pubs/pres/USENIX/2004/usenix-dns-dist-pres.pdf

Joe

5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Suresh Ramasubramanian wrote:

Joe Shen wrote:

We noticed there is continous name resolution requests
from IP address outside of our address pool and also
there is requests not conforming to DNS documents (
like those from 10/8, 192.168/16 or something for
microsoft proxy server name). We think these request
waste our resource and we don't want these system
stable, secure and high performance.

If the resolver caches are only supposed to be accessed from your IP
space, I am sure you can easily throw in a router ACL to accept
connections on port 53 only from these IPs.

Oh, and filter out bogons at your borders while you are at it (like for
example rfc1918 source addresses from outside your network)

And check out the CYMRU Secure Bind template at
http://www.cymru.com/Documents/secure-bind-template.html

- --

6

Hi,

thanks for your help on my question.

After reading carefully those comments, I reach the
following conclusion:

1. ISPs use firewall to protect their DNS server;

2. ACL on router may be a good solution for protecting
DNS servers, the policy could be "only pass those
packets, whose originate from incustomers' IP address
blocks and destinate to UDP port 53 of DNS server";

3. Currently, it maybe a little difficult for firewall
to filter DNS requests not conforming to DNS document;
but, Nominum's product could;

4. Anycast is the most scalable and standard solution
for dispersed DNS server farm, while layer-4 switch
could deal could do with centralized server farm;

5. 'bogon'in BIND configuration could be used to
filter requests from RFC1918 address;

6. Firewall may become bottleneck of DNS server farm
in situation of DoS attack or situation of high
session rate;

7. It's good solution to divide DNS servers into two
groups, one for recursive lookup the other for
no-recuresive;

8. BIND should be configured carefully and there is
BIND secure template to follow

Have I missed something? And, I got another two
questions:

a) If firewall is used to protect DNS server farm,
could it do more than router's ACL while reaching the
same performance-cost ratio ? which one is usually
chosen by those ISPs having big customer numbers? (we
noticed DNS requests from our customers keep increase
in past months)

b) Is there any public available performance
evaluation on Nominum's product?

Any of your words will be highly appreciated.

Joe

7

If you are looking for firewall-esque devices to protected name servers, look into Riverhead (purchased by cisco recently).

8

1. ISPs use firewall to protect their DNS server;

  some do, some don't

4. Anycast is the most scalable and standard solution
for dispersed DNS server farm, while layer-4 switch
could deal could do with centralized server farm;

  its not a standard.

5. 'bogon'in BIND configuration could be used to
filter requests from RFC1918 address;

  this should be pushed to
  the router. don't waste CPU cycles
  on the Nameserver.

6. Firewall may become bottleneck of DNS server farm
in situation of DoS attack or situation of high
session rate;

  yes

7. It's good solution to divide DNS servers into two
groups, one for recursive lookup the other for
no-recuresive;

  yes

8. BIND should be configured carefully and there is
BIND secure template to follow

  altho the template will not meet every case.

a) If firewall is used to protect DNS server farm,
could it do more than router's ACL while reaching the
same performance-cost ratio ? which one is usually
chosen by those ISPs having big customer numbers? (we
noticed DNS requests from our customers keep increase
in past months)

  general rule - drop undesired traffic as far
  upstream as possible.

b) Is there any public available performance
evaluation on Nominum's product?

  you should check w/ the Nominum staff on any
  performance evaluations.

9

<ftp://ftp.rfc-editor.org/in-notes/rfc1546.txt>, aka _Host Anycasting Service_

Looks pretty standard to me.

Not to mention being used in production on several major networks for over half a decade (read: "forever") on the Internet is pretty well tested technology.

10

>>4. Anycast is the most scalable and standard solution
>>for dispersed DNS server farm, while layer-4 switch
>>could deal could do with centralized server farm;
>
> its not a standard.

<ftp://ftp.rfc-editor.org/in-notes/rfc1546.txt&gt;, aka _Host Anycasting
Service_

Looks pretty standard to me.

  Nope. Its -INFORMATIONAL- e.g. Not a Standard.

Not to mention being used in production on several major networks for
over half a decade (read: "forever") on the Internet is pretty well
tested technology.

  true enough. but not "the most scaleable and standard solution"

11

4. Anycast is the most scalable and standard solution
for dispersed DNS server farm, while layer-4 switch
could deal could do with centralized server farm;

  its not a standard.

<ftp://ftp.rfc-editor.org/in-notes/rfc1546.txt&gt;, aka _Host Anycasting
Service_

Looks pretty standard to me.

  Nope. Its -INFORMATIONAL- e.g. Not a Standard.

Ahhh, I see.

Not to mention being used in production on several major networks for
over half a decade (read: "forever") on the Internet is pretty well
tested technology.

  true enough. but not "the most scaleable and standard solution"

Yeah, well, neither is HTTP for that matter. But most people would consider both of them pretty standard(ized?).

I'm perfectly happy for someone to quote even an _informational_ RFC as a "standard". Guess I'm weird.

Sorry if everyone thinks differently.

12

1. ISPs use firewall to protect their DNS server;

Depends. You don't normally need a full fledged (stateful) firewall.
Normal (stateless) router access lists are just fine.

2. ACL on router may be a good solution for protecting
DNS servers, the policy could be "only pass those
packets, whose originate from incustomers' IP address
blocks and destinate to UDP port 53 of DNS server";

In general, allow only relevant traffic. That may be a bit more than
just UDP port 53: You really want to allow TCP based DNS queries also,
and your name server probably needs SSH, NTP and similar.

5. 'bogon'in BIND configuration could be used to
filter requests from RFC1918 address;

Better to do it on the router.

6. Firewall may become bottleneck of DNS server farm
in situation of DoS attack or situation of high
session rate;

Routers with hardware based access lists. No problem.

b) Is there any public available performance
evaluation on Nominum's product?

See Brad Knowles' tests:

http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-dns-dnscomp.pdf

We currently have the Nominum CNS on trial here, and we are very
impressed. It performs much better than BIND 8/9 - our measurements
show even greater differences than Brad Knowles' tests. Example: One
server running BIND 9 shows more than 30% CPU usage during peak hours,
but only 2-3% with Nominum CNS. We also have the issue that BIND 9
seems to start *failing* when it reaches a certain cache size (as in:
Some queries are either not answered at all, or they are answered
with SERVFAIL).

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

13

I think "a Standard" was just an example of one of the things it is not. It is also not a pressure washer, a small rodent native of south-east Asia or the cornerstone of a successful marketing campaign for hand soap.

Joe

14

Hi,

> in situation of DoS attack or situation of high
> session rate;

Routers with hardware based access lists. No
problem.

What I'm not sure about ACL on router is, how to
survive DNS server under DoS/DDos attack. We suffered
from DoS attack last year, and we found the source IPs
of that attack locate in our customers IP address
blocks. ACL on router could only filter those traffic
not meaningful to DNS server, but how about those DDoS
attacking packets?

We currently have the Nominum CNS on trial here, and
we are very
impressed. It performs much better than BIND 8/9 -
our measurements
show even greater differences than Brad Knowles'
tests. Example: One
server running BIND 9 shows more than 30% CPU usage
during peak hours,
but only 2-3% with Nominum CNS. We also have the
issue that BIND 9
seems to start *failing* when it reaches a certain
cache size (as in:
Some queries are either not answered at all, or they
are answered
with SERVFAIL).

Impressive! What's the peak value of concurrent DNS
requests in your trial?

Thanks.

Joe

15

>> Nope. Its -INFORMATIONAL- e.g. Not a Standard.
>
> P.S. That would be "i.e.". If you are going to argue semantic points,

> you should get your grammar right. =)

I think "a Standard" was just an example of one of the things it is
not. It is also not a pressure washer, a small rodent native of
south-east Asia or the cornerstone of a successful marketing campaign
for hand soap.

e.g. exemplia gratia
In English this means "free example" but we more commonly say
"for example" because most of us don't know Latin any more.

i.e. id est
In English this means "it is" but we more commonly say
"that is <pause>" because it seems more natural somehow.

In any case, try these two possibilities on for size and
choose your favourite.

Nope. It's -INFORMATIONAL- that is, Not a Standard.

Nope. It's -INFORMATIONAL- for example, Not a Standard.

My money is on the former. More punch. More pizzaz!

P.S. A farmer is a man, outstanding in his field.

16

What I'm not sure about ACL on router is, how to
survive DNS server under DoS/DDos attack. We suffered
from DoS attack last year, and we found the source IPs
of that attack locate in our customers IP address
blocks. ACL on router could only filter those traffic
not meaningful to DNS server, but how about those DDoS
attacking packets?

Your router can presumably rate limit the traffic towards the name
server to a level the name server can handle. On the name server
you can perform further rate limiting on an IP address basis, with
for instance FreeBSD ipfw.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

17

Hosts tend to be a faster writeoff cycle than routers in companies I've
worked at, therefore getting the benefit of moores law about 25% faster
than the routers. Turn on firewalling in the host. That said, I do
filter 1918 at my edge.

/vijay

18

> this should be pushed to
> the router. don't waste CPU cycles
> on the Nameserver.

Hosts tend to be a faster writeoff cycle than routers in companies I've
worked at, therefore getting the benefit of moores law about 25% faster
than the routers. Turn on firewalling in the host.

If you have a choice between access lists on a software forwarding
based router and firewall on a host, this may be a good choice. If
your routers have hardware forwarding, I'd go for the router every
time...

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

19

Seems like the most sensible option is "defense in depth", tailored
to your specific mix of equipment and clue. Throw away what you
can at the edge (e.g., uRPF), spread the load (e.g., anycast), and
firewall, as appropriate. Many routers with "hardware forwarding"
have potentially significant limits when it comes to ACLs. Even
the more capable devices don't necessarily give you the ability to
look arbitrarily deep inside incoming packets, at least not without
expensive additional cards. A firewall can usually perform that
level of inspection, which means it will catch "bad" packets that
the router didn't. None of these steps alone is perfect, but the
combination can be fairly effective.

One size does not have to fit all.

--Jeff

20

That said, I do filter 1918 at my edge.

/vijay

ok everybody, vijay says the snapshot below didn't come from him.
who wants to claim it, then?

# tcpdump -n -c 25 net 10 or net 192.168 or net 172.16.0.0/12
tcpdump: listening on fxp0
19:52:53.787244 10.9.10.250.53 > 192.5.5.241.53: 29644 MX? rogers.com. (29)
19:52:53.789098 10.9.10.250.53 > 192.5.5.241.53: 29643 A? tock.usno.navy.mil. (36)
19:52:53.790367 10.9.10.250.53 > 192.5.5.241.53: 29642 MX? nygh.on.ca. (29)
19:52:53.791023 10.9.10.250.53 > 192.5.5.241.53: 29641 MX? sympatico.ca. (31)
19:52:54.000576 10.6.166.16.35067 > 192.5.5.241.53: 51520 PTR? 23.180.243.65.in-addr.arpa. (44) (DF)
19:52:54.000591 10.6.166.16.35067 > 192.5.5.241.53: 39692 MX? wedweb.cc. (27) (DF)
19:52:54.049835 10.21.13.50.32769 > 192.5.5.241.53: 19542 NS? . (17) (DF)
19:52:54.167651 10.1.10.8.53 > 192.5.5.241.53: 17611 PTR? 1.18.32.10.in-addr.arpa. (41)
19:52:54.227294 172.22.26.5.53 > 192.5.5.241.53: 5298 A? autodesk.com. (30)
19:52:54.327460 10.48.10.250.53 > 192.5.5.241.53: 29477 MX? unco.edu. (27)
19:52:54.328475 10.48.10.250.53 > 192.5.5.241.53: 29476 MX? unco.edu. (27)
19:52:54.329118 10.48.10.250.53 > 192.5.5.241.53: 29475 MX? icella.com. (29)
19:52:54.329736 10.48.10.250.53 > 192.5.5.241.53: 29474 MX? att.net. (26)
19:52:54.487335 10.40.1.29.53 > 192.5.5.241.53: 10970 [b2&3=0x400] A? czdm01.bauholding.com. (39)
19:52:54.490662 10.40.1.29.53 > 192.5.5.241.53: 10971 A? IBM-4406B6DF58E.bauholding.com. (48)
19:52:54.491791 192.168.0.2.1033 > 192.5.5.241.53: 4574 A? velu.neuro6.com. (33)
19:52:54.493123 192.168.0.2.1033 > 192.5.5.241.53: 4580 A? velu.neuro6.com. (33)
19:52:54.495051 192.168.0.2.1033 > 192.5.5.241.53: 12777 A? velu.neuro6.com. (33)
19:52:54.508596 172.23.3.39.1057 > 192.5.5.241.53: 2240 A? download.windowsupdate.com. (44)
19:52:54.511223 172.23.3.39.1057 > 192.5.5.241.53: 14538 A? download.windowsupdate.com. (44)
19:52:54.513568 172.23.3.39.1057 > 192.5.5.241.53: 6358 A? download.windowsupdate.com. (44)
19:52:54.527938 10.26.0.10.32769 > 192.5.5.241.53: 53702 A? nuyoo.utm.mx. (30) (DF) [tos 0x4]
19:52:54.553784 192.168.192.49.47768 > 192.5.5.241.53: 34671 PTR? 36.7.7.4.in-addr.arpa. (39) (DF)
19:52:54.605368 10.26.0.10.32769 > 192.5.5.241.53: 60698 A? uumail.unt.edu.ar. (35) (DF) [tos 0x4]
19:52:54.634115 10.26.0.10.32769 > 192.5.5.241.53: 30349[|domain] (DF) [tos 0x4]
2410 packets received by filter
0 packets dropped by kernel

note: in 106 days of uptime, this particular host inside the f-root cluster
has discarded the following:

        rule# packets --octets-- -------------rule--------------------
        00400 6446004 428112547 deny ip from 10.0.0.0/8 to any in
        00500 5874604 369667080 deny ip from 172.16.0.0/12 to any in
        00600 8367728 546972348 deny ip from 192.168.0.0/16 to any in

this seems excessive, and so i've been assuming that it was all vijay's
fault. but apparently it's not him. so which one of you isn't filtering
1918 at your edge? (oops, it's all of you, isn't it?)