-----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. :) 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt5jxoACgkQJmrRtQ6zKE94eQCghyDn96HG2g7G1MDogj/yy1WB GFQAn22n3a48Mt9ssiwfyqN1Ne0N+X6L =Xt79 -----END PGP SIGNATURE-----
On Mon, 15 Feb 2010, Charles N Wyble 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: http://fanf.livejournal.com/104774.html Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Finch wrote:
On Mon, 15 Feb 2010, Charles N Wyble 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: http://fanf.livejournal.com/104774.html
Tony.
Most interesting. Thanks. - From https://www.dns-oarc.net/oarc/services/replysizetest 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt5mxQACgkQJmrRtQ6zKE99PwCgh5ikE7LRywT610jG4QkkTE4n lyoAoMT67y/fGQHadGC6aHyRzRzQsxZi =K8sW -----END PGP SIGNATURE-----
I haven't run BIND in a number of years. --Curtis On 2/15/2010 2:06 PM, Charles N Wyble wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tony Finch wrote:
On Mon, 15 Feb 2010, Charles N Wyble 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: http://fanf.livejournal.com/104774.html
Tony.
Most interesting. Thanks.
- From https://www.dns-oarc.net/oarc/services/replysizetest
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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkt5mxQACgkQJmrRtQ6zKE99PwCgh5ikE7LRywT610jG4QkkTE4n lyoAoMT67y/fGQHadGC6aHyRzRzQsxZi =K8sW -----END PGP SIGNATURE-----
In message <4B7AF7F5.3030302@xyonet.com>, Curtis Maurand writes:
I haven't run BIND in a number of years.
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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
* 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. :)
Why do you think so? Would you even notice if your webmail provider switches to HTTPS by default (or back to HTTP)?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. :)
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. :) 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt5m4cACgkQJmrRtQ6zKE9y7gCfVRwsS9nIMXP37581d0hsUkDD pHYAoM/3IrNmKbRKdwaEPEbxH1nCyntx =e45k -----END PGP SIGNATURE-----
* 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. 8-)
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. :) 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: http://www.iis.se/docs/Routertester_en.pdf -- amar
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? 8-) 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.
In message <4B798F1E.6080403@knownelement.com>, Charles N Wyble writes:
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. :) 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
- -- 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkt5jxoACgkQJmrRtQ6zKE94eQCghyDn96HG2g7G1MDogj/yy1WB GFQAn22n3a48Mt9ssiwfyqN1Ne0N+X6L =Xt79 -----END PGP SIGNATURE-----
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Andrews wrote:
In message <4B798F1E.6080403@knownelement.com>, Charles N Wyble writes:
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. :) 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 http://www.howtoforge.com/debian_bind9_master_slave_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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt6UCoACgkQJmrRtQ6zKE/bAACgtNtqptEN0X1deA+gbr+HilOx OJ0AoKyLc6soMTi4aKQI4u6HUTWxr7tt =r7yW -----END PGP SIGNATURE-----
In message <4B7A502F.8000204@knownelement.com>, Charles N Wyble writes:
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.
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 http://www.howtoforge.com/debian_bind9_master_slave_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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkt6UCoACgkQJmrRtQ6zKE/bAACgtNtqptEN0X1deA+gbr+HilOx OJ0AoKyLc6soMTi4aKQI4u6HUTWxr7tt =r7yW -----END PGP SIGNATURE-----
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
participants (6)
-
Amar -
Charles N Wyble -
Curtis Maurand -
Florian Weimer -
Mark Andrews -
Tony Finch