DNSSEC Readiness

Mailman List Mirror (Read Only)
1

All,

How are folks verifying DNSSEC readiness of their environments? Any
existing testing methodologies / resources that folks are using?

It seems like this is something that will become a front and center
issue for help desks everywhere pretty quick. :slight_smile: Ideally the more we can
stave off issues through proactive testing/fixing the better.

- --
Charles N Wyble
Linux Systems Engineer
charles@knownelement.com (818)280-7059
http://www.knownelement.com
Unless agreed upon, assume everything in this e-mail might be blogged.

2

Here's my summary of the situation (as of a couple of months ago) with
links to a few key resources: http://fanf.livejournal.com/104774.html

Tony.

3

* Charles N. Wyble:

How are folks verifying DNSSEC readiness of their environments? Any
existing testing methodologies / resources that folks are using?

For now, running (with a real resolver address instead of 192.0.2.1)

  dig @192.0.2.1 $RANDOM. +dnssec

and checking if a certain percentage of the responses include DNSSEC
data. This means that your resolver can get data from DURZ-enabled
servers, so you should be fine when the root is signed.

If your resolvers are not security-aware, use

  dig @192.0.2.1 . NSEC
  dig @192.0.2.1 . RRSIG
  dig @192.0.2.1 . DNSKEY

but you can run this variant of the test only once per day.

If you never, ever get any DNSSEC data for these queries, you will
very likely have a problem once all root servers have switched to
serving DURZ (and later DNSSEC) data.

It seems like this is something that will become a front and center
issue for help desks everywhere pretty quick. :slight_smile:

Why do you think so? Would you even notice if your webmail provider
switches to HTTPS by default (or back to HTTP)?

4

Tony Finch wrote:

How are folks verifying DNSSEC readiness of their environments? Any
existing testing methodologies / resources that folks are using?

Here's my summary of the situation (as of a couple of months ago) with
links to a few key resources: Signing the root zone. - Tony Finch's blog — LiveJournal

Tony.

Most interesting. Thanks.

- From OARC's DNS Reply Size Test Server | DNS-OARC

charles@charles-laptop:~] dig +short rs.dns-oarc.net txt
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"8.0.23.143 sent EDNS buffer size 4096"
"8.0.23.143 DNS reply size limit is at least 3843"
"Tested at 2010-02-15 19:03:47 UTC"
charles@charles-laptop:~]

I have a local BIND server I use for DNS. It's whatever Ubuntu 9.10
installs with apt-get, and a cisco 1841 as my edge router.

I imagine that is a pretty standard setup in a lot of user sites (linux
with bind and a cisco router of some sort).

Will do further investigation.

- --
Charles N Wyble
Linux Systems Engineer
charles@knownelement.com (818)280-7059
http://www.knownelement.com
Unless agreed upon, assume everything in this e-mail might be blogged.

5

Florian Weimer wrote:

* Charles N. Wyble:

It seems like this is something that will become a front and center
issue for help desks everywhere pretty quick. :slight_smile:

Why do you think so? Would you even notice if your webmail provider
switches to HTTPS by default (or back to HTTP)?

Well I would, but most users won't. :slight_smile:

However they will certainly start complaining when DNS stops working. Of
course they won't know that's what the issue is, but they will call
saying the internet is down.

- --
Charles N Wyble
Linux Systems Engineer
charles@knownelement.com (818)280-7059
http://www.knownelement.com
Unless agreed upon, assume everything in this e-mail might be blogged.

6

* Charles N. Wyble:

However they will certainly start complaining when DNS stops working. Of
course they won't know that's what the issue is, but they will call
saying the internet is down.

Okay, then the first way I mentioned for checking should be
sufficient. Well, perhaps make it

  dig $RANDOM.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. +dnssec

instead, so that you'll receive an even larger response.

But actually, you already know that your DNS can cope with responses

512 bytes, if you look at this:

  dig @k.root-servers.net +trace +all +dnssec aol.com MX

Certainly, your users would complain if they couldn't send mail to
AOL. :sunglasses:

7

Charles N Wyble wrote:

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

All,

How are folks verifying DNSSEC readiness of their environments? Any
existing testing methodologies / resources that folks are using?

It seems like this is something that will become a front and center
issue for help desks everywhere pretty quick. :slight_smile: Ideally the more we can
stave off issues through proactive testing/fixing the better.

FWIW - .se did some consumer research during their
DNSSec launch. I belive there will be a new study.

Tests of Consumer Broadband Routers in Sweden (DNSSEC)
in 2008:

-- amar

8

FWIW - .se did some consumer research during their

DNSSec launch. I belive there will be a new study.

Tests of Consumer Broadband Routers in Sweden (DNSSEC)
in 2008:
http://www.iis.se/docs/Routertester_en.pdf

Seriously, who puts recursive DNS resolvers behind consumer broadband
routers? :sunglasses:

Seriously, these studies measure the wrong thing. I don't think any
vendor has announced yet to switch on DNSSEC validation in stub
resolvers by default.

9

All,

How are folks verifying DNSSEC readiness of their environments? Any
existing testing methodologies / resources that folks are using?

It seems like this is something that will become a front and center
issue for help desks everywhere pretty quick. :slight_smile: Ideally the more we can
stave off issues through proactive testing/fixing the better.

Make the following queries from your recursive servers. If you
force the query source in the nameserver add a "-b <address>" to
match.

dig -4 ns . +norec @l.root-servers.net
dig -4 ns . +dnssec +cd +norec @l.root-servers.net
dig -4 any . +dnssec +cd +norec @l.root-servers.net
dig -4 any . +dnssec +cd +norec @l.root-servers.net +vc

If any of them fail you need to fix your middleware and / or firewall
on the box.

The first +dnssec query checks that unfragmented DNSSEC responses
over 512 bytes are passed. I get 801 bytes today when I run this
test.

The second +dnssec query checks that fragmented DNSSEC responses are
passed. I get 1906 bytes today when I run this test.

The third +dnsec query checks that DNSSEC responses over TCP are
passed.

The non +dnssec query is a control query to check that you can reach
l.root-servers.net.

Repeat for IPv6.

dig -6 ns . +norec @l.root-servers.net
dig -6 ns . +dnssec +cd +norec @l.root-servers.net
dig -6 any . +dnssec +cd +norec @l.root-servers.net
dig -6 any . +dnssec +cd +norec @l.root-servers.net +vc

Mark

10

Mark Andrews wrote:

All,

How are folks verifying DNSSEC readiness of their environments? Any
existing testing methodologies / resources that folks are using?

It seems like this is something that will become a front and center
issue for help desks everywhere pretty quick. :slight_smile: Ideally the more we can
stave off issues through proactive testing/fixing the better.

Make the following queries from your recursive servers. If you
force the query source in the nameserver add a "-b <address>" to
match.

dig -4 ns . +norec @l.root-servers.net
dig -4 ns . +dnssec +cd +norec @l.root-servers.net
dig -4 any . +dnssec +cd +norec @l.root-servers.net
dig -4 any . +dnssec +cd +norec @l.root-servers.net +vc

If any of them fail you need to fix your middleware and / or firewall
on the box.

The first +dnssec query checks that unfragmented DNSSEC responses
over 512 bytes are passed. I get 801 bytes today when I run this
test.

The second +dnssec query checks that fragmented DNSSEC responses are
passed. I get 1906 bytes today when I run this test.

The third +dnsec query checks that DNSSEC responses over TCP are
passed.

The non +dnssec query is a control query to check that you can reach
l.root-servers.net.

Repeat for IPv6.

dig -6 ns . +norec @l.root-servers.net
dig -6 ns . +dnssec +cd +norec @l.root-servers.net
dig -6 any . +dnssec +cd +norec @l.root-servers.net
dig -6 any . +dnssec +cd +norec @l.root-servers.net +vc

Mark

Thank you. That's a nice quick/dirty test.

All 4 commands worked.

If folks are curious, my setup is Ubuntu 9.10 client, Ubuntu 9.10 server
running bind and a cisco 1841 running 12.4(18). I don't have a Windows
box handy to test on. How would one test with nslookup anyway? Or does
it only matter if the local DNS server can do the lookup and clients
will just work? Though one would still need to test from Windows if you
have AD for DNS I suppose. *shrugs*

Ok.... that's the client side.

How about the server side?

I'm currently using my registrars DNS servers. I haven't seen anything
in their control panel about DNSSEC. One item on my TODO list is to move
DNS to my BIND servers.

Quick search turns up
[Debian Sarge] Installing A Bind9 Master/Slave DNS System which
mentions a few commands and couple stanzas. Is that all it takes?
How do you verify that you are .... compliant? complete? I mean SSL
based PKI is pretty straightforward and I understand it and can verify
that I'm compliant/complete (run my own ca, issue certs, delegate trust
etc). Guess I need to do more reading on DNSSEC and how to integrate
into the global DNSSEC infrastructure (such as it is and will emerge to
be). I have a test domain that I use for things like this. I would like
to setup DNSSEC and then positively/negatively test it. Just not sure
how. Presumably one should attempt to MITM the request and make sure the
resolver complains yes?

This is at my home network and as such I have a great degree of
latitude. For folks who have managers to report to, what are the
justifications for deploying DNSSEC?

I think one would do it in stages

1)Make sure their infrastructure can at least handle the DNS protocol
changes that DNSSEC brings about (ie the 4 test commands above pass)

2)Implement a parallel environment with and without DNSSEC (is this
possible/desirable?)

3)Sign their records.

Anyway just some thoughts.

Thanks to folks who have responded so far.

11

> Repeat for IPv6.
>
> dig -6 ns . +norec @l.root-servers.net
> dig -6 ns . +dnssec +cd +norec @l.root-servers.net
> dig -6 any . +dnssec +cd +norec @l.root-servers.net
> dig -6 any . +dnssec +cd +norec @l.root-servers.net +vc
>
> Mark

Thank you. That's a nice quick/dirty test.

All 4 commands worked.

If folks are curious, my setup is Ubuntu 9.10 client, Ubuntu 9.10 server
running bind and a cisco 1841 running 12.4(18). I don't have a Windows
box handy to test on. How would one test with nslookup anyway? Or does
it only matter if the local DNS server can do the lookup and clients
will just work? Though one would still need to test from Windows if you
have AD for DNS I suppose. *shrugs*

Ok.... that's the client side.

That's a path test. Next are system tests. You should get answers
to all of below and you should have "ad" set in the "se" query.

named.test.conf:

trusted-keys {
  dlv.isc.org. 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URkY62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboMQKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VStTDN0YUuWrBNh";
};

options {
  listen-on port 4444 { 127.0.0.1; };
  dnssec-enable yes;
  dnssec-validation yes;
  dnssec-lookaside . trust-anchor dlv.isc.org;
};

dig -p 4444 @127.0.0.1 +dnssec se soa
dig -p 4444 @127.0.0.1 +dnssec .
dig -p 4444 @127.0.0.1 +dnssec www.microsoft.com

Once you are confident you can add these to you normal named.conf.
See https://www.isc.org/solutions/dlv for more details and subscribe
to dlv-announce@isc.org so you will get reminders about when to
update the trusted-keys statement.

When the root is signed you will want to add a trusted-keys clause
for it as well. I wouldn't suggest tracking more trusted keys than
that for the moment.

12

I haven't run BIND in a number of years.

--Curtis

13

There are a number of vendors that support DNSSEC on both the server
side and on the client side. Check with your vendor about what they
support.

Mark