From paf at cisco.com Fri Nov 2 05:13:15 2007 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Fri, 2 Nov 2007 10:13:15 +0100 Subject: Replacement for me in panel on DNSSEC at IGF in Rio de Janeiro Message-ID: In 1.5 weeks, there will be a panel on DNSSEC hosted by Syracuse University at the IGF in Rio. I accepted being on the panel, but due to scheduling conflicts I can no longer be on it. I have another session at the IGF I have participate on. http://info.intgovforum.org/yoppy.php?poj=33 I do want to suggest a replacement for me on this panel, so I ask whether anyone on this list will be in Rio already, and can help? Regards, Patrik From galvin at elistx.com Mon Nov 5 19:04:52 2007 From: galvin at elistx.com (James M Galvin) Date: Mon, 05 Nov 2007 19:04:52 -0500 Subject: TIME CHANGE: meeting announcement: 7 November 2007 Message-ID: <6DB662FF52CE2C4B8938C8B4@[10.0.0.11]> NOTE WELL - THE TIME HAS CHANGED BOTH BECAUSE OF THE TRANSITION TO/FROM DAYLIGHT STANDARD TIME AND BECAUSE THE TIME HAS MOVED TO BETTER ACCOMMODATE OUR ASIA-PACIFIC PARTICIPANTS. THIS WILL BE OUR NEW USUAL TIME, STILL ON THE FIRST WEDNESDAY OF EACH MONTH. This meeting will be held at the usual time of: 0700 Los Angeles, San Francisco 0800 Phoenix 0800 Salt Lake City 1000 Washington 1500 UTC 1500 London 1600 Netherlands 1700 Israel 0000 Tokyo (the next day) 0200 Melbourne (the next day) The usual teleconference logistics are as follows. These do not change. You will hear music until the moderator joins. USA Toll Free Number: +1 888-221-7341 USA Toll Number: +1 973-935-2305 Passcode: 599 786 # Leader: James Galvin employed by ICANN if speaking to an operator Jabber: dnssec-deployment at conference.jabber.org This is a public room. If your phone does not have a mute capability you can use "*6" to mute and unmute your connection. DIAL OUT: 1. ISC SIP Bridge - contact me for SIP identifiers DRAFT AGENDA * DNSSEC not handled properly by some broadband routers On Friday, 21 September 2007, folks in Sweden discovered that there are routers and clients that cannot handle DNSSEC correctly. The short term solution was to remove DNSSEC from the effected zones. Over the next several days it was discovered that there are broadband routers that do not handle the AD bit flag correctly and that Bind was incorrectly setting the AD bit in some cases. Jacob Schlyter will lead a discussion of the incident, its discovery and resolution, and the efforts to test broadband routers for the problem. Meeting materials can be found here: http://www.dnssec-deployment.org/wg/materials/20071107/ From Joakim.Ahlund at iis.se Wed Nov 7 09:08:29 2007 From: Joakim.Ahlund at iis.se (=?iso-8859-1?Q?Joakim_=C5hlund?=) Date: Wed, 7 Nov 2007 15:08:29 +0100 Subject: No subject Message-ID: <023E9DDFC555E3479AEBF917CE60A0B4E4EEE8@EXCHANGE.office.nic.se> Hi Here is some materiel for todays meeting. It is the test protocol from the 7 routers we have tested so far. Joakim ?hlund FoU .SE (Stiftelsen f?r Internetinfrastruktur) Ringv?gen 100 A 9tr. Box 7399 103 91 Stockholm V?xel: 08 - 452 35 00, direkt: 08 - 452 35 66 E-post: joakim.ahlund at iis.se Webbplats: www.iis.se -------------- next part -------------- A non-text attachment was scrubbed... Name: Test protocol 07-11-07.pdf Type: application/octet-stream Size: 14680 bytes Desc: Test protocol 07-11-07.pdf Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20071107/a029def5/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Test protocol 07-11-07.xls Type: application/vnd.ms-excel Size: 51200 bytes Desc: Test protocol 07-11-07.xls Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20071107/a029def5/attachment.xls From galvin at elistx.com Wed Nov 7 09:54:36 2007 From: galvin at elistx.com (James M Galvin) Date: Wed, 07 Nov 2007 09:54:36 -0500 Subject: [dnssec-deployment] In-Reply-To: References: Message-ID: <3D40807FEA5F542DE0C9A423@[10.0.0.11]> I have uploaded this to the meeting materials space: Jim -- On Wednesday, November 07, 2007 3:08 PM +0100 Joakim ?hlund wrote regarding [dnssec-deployment] -- > Hi > Here is some materiel for todays meeting. It is the test protocol > from the 7 routers we have tested so far. > > Joakim ?hlund > FoU > .SE (Stiftelsen f?r Internetinfrastruktur) Ringv?gen 100 A 9tr. > Box 7399 > 103 91 Stockholm > V?xel: 08 - 452 35 00, direkt: 08 - 452 35 66 > E-post: joakim.ahlund at iis.se > Webbplats: www.iis.se From weiler at tislabs.com Wed Nov 7 10:50:21 2007 From: weiler at tislabs.com (Sam Weiler) Date: Wed, 7 Nov 2007 10:50:21 -0500 (EST) Subject: SOHO router result summary In-Reply-To: References: Message-ID: I pulled the test results onto a single spreadsheet page, to more easily look for trends. -- Sam -------------- next part -------------- A non-text attachment was scrubbed... Name: Test protocol summary.pdf Type: application/pdf Size: 21404 bytes Desc: Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20071107/cb334529/attachment.pdf From steve at shinkuro.com Wed Nov 7 11:13:31 2007 From: steve at shinkuro.com (Crocker Steve) Date: Wed, 7 Nov 2007 11:13:31 -0500 Subject: [dnssec-deployment] SOHO router result summary In-Reply-To: References: Message-ID: Sam, Nice job! Thanks! Steve On Nov 7, 2007, at 10:50 AM, Sam Weiler wrote: > I pulled the test results onto a single spreadsheet page, to more > easily look for trends. > > -- Sam > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: Lists/dnssec-deployment/> > and older material is at > From staffan.hagnell at iis.se Tue Nov 13 05:38:13 2007 From: staffan.hagnell at iis.se (Staffan Hagnell) Date: Tue, 13 Nov 2007 11:38:13 +0100 Subject: SOHO router meeting summary In-Reply-To: References: Message-ID: <023E9DDFC555E3479AEBF917CE60A0B401489B4E@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks for the telephone conference on 7 November about SOHO routers. This is my summary for how the work shall proceed and who will do it. Grateful for your opinions. Best regards, - -Staffan ** AP1 ** - Tests specification for broadband routers We shall make a more generic tests specification for DNS and broadband routers, instead of a specific tests specification for DNSSEC and broadband routers. We shall make a general test specification for DNS (not a specific for DNSSEC). The reason is that the requirements on DNS for IPv6 and ENUM is overlapping and I expect that we will get a better impact on the vendors with one single specification. Patrik Wallstr?m, patrik.wallstrom at iis.se will coordinate this activity. Partik will send the present test specification on relevant lists and ask for input. The activity is expected to be finished with in 14 days. ** AP2 ** - Perform the tests Wait for AP1! .SE will perform the test with the updated test specification for the routers we got. ** AP3 ** Publish the test results Wait for AP2 .SE will send its new test results to James Galvin for publishing on dnssec-deployments web site. Question: With a new and more general test specification, ought the test result also be published on other sites? ** AP4 ** - Report errors to vendors Wait for AP3 .SE will report errors to the vendors for the new test results. ** AP5 ** - An automated scrpt/binary that can be run on OSX/Windows Wait for AP1 Question: Is there any body interesting to do this? ** AP6 ** - Certification of broadband routers Wait for A3 Contact Microsoft (vista seal) and other. Question: Is there any body interesting to do this? -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBRzl+lt4BnYBkDYbAEQKJZACgvMjtih+GJeqrww2TuKARtsJMDcAAoLzu UAASuJYBMQ0SJkypFKvk6bs6 =S4M3 -----END PGP SIGNATURE----- From jaap at NLnetLabs.nl Fri Nov 16 09:54:05 2007 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Fri, 16 Nov 2007 15:54:05 +0100 Subject: DNSSEC survey by the GNSO Message-ID: <200711161454.lAGEs5Gj021571@bartok.nlnetlabs.nl> FYI The GNSO did a survey to: "find out what the cc community has done so far individually regarding DNSSEC, and to take part of their experiences on the matter" and the reults are published on their website: http://www.ccnso.icann.org/surveys/dnssec-survey-report-2007.pdf. jaap From jaap at NLnetLabs.nl Fri Nov 16 09:57:21 2007 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Fri, 16 Nov 2007 15:57:21 +0100 Subject: [dnssec-deployment] DNSSEC survey by the GNSO In-Reply-To: Your message of Fri, 16 Nov 2007 15:54:05 +0100. Message-ID: <200711161457.lAGEvLem022199@bartok.nlnetlabs.nl> The GNSO did a survey to: "find out what the cc community has done Oops, I of copurse meant ccNSO. Soryy about that. jaap From paul at xelerance.com Mon Nov 19 21:31:00 2007 From: paul at xelerance.com (Paul Wouters) Date: Mon, 19 Nov 2007 21:31:00 -0500 (EST) Subject: DNSSEC Deployment Google Map Message-ID: Hi, As part of my DNSSEC Deployment presentation at Sector (http://www.sector.ca) tomorrow, I created a google map of the current DNSSEC deployment, as it is known to me (and the DNS). http://www.xelerance.com/dnssec/ The map lists production zones, testbeds and dead projects. If you have any additions or updates, feel free to email them to me. Paul Wouters Xelerance Corp From steve at shinkuro.com Mon Nov 19 21:32:47 2007 From: steve at shinkuro.com (Crocker Steve) Date: Mon, 19 Nov 2007 21:32:47 -0500 Subject: [dnssec-deployment] DNSSEC Deployment Google Map In-Reply-To: References: Message-ID: This is ultra cool!! Please tell me how this is done. There is undoubtedly more, but not enough to change the basic picture. I'd rather concentrate on how to get the right data to flow so this is maintained and up to date. Steve On Nov 19, 2007, at 9:31 PM, Paul Wouters wrote: > > Hi, > > As part of my DNSSEC Deployment presentation at Sector (http:// > www.sector.ca) > tomorrow, I created a google map of the current DNSSEC deployment, > as it is > known to me (and the DNS). > > http://www.xelerance.com/dnssec/ > > The map lists production zones, testbeds and dead projects. If you > have any > additions or updates, feel free to email them to me. > > Paul Wouters > Xelerance Corp > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: Lists/dnssec-deployment/> > and older material is at > From paul at xelerance.com Mon Nov 19 21:48:56 2007 From: paul at xelerance.com (Paul Wouters) Date: Mon, 19 Nov 2007 21:48:56 -0500 (EST) Subject: [dnssec-deployment] DNSSEC Deployment Google Map In-Reply-To: References: Message-ID: On Mon, 19 Nov 2007, Crocker Steve wrote: > Please tell me how this is done. There is undoubtedly more, but not enough to > change the basic picture. I'd rather concentrate on how to get the right data > to flow so this is maintained and up to date. Well, at this point, it basically AXFR's the root from f and then tries to query for dnskey records for all entries. It then maps those against a list of google KML files and colours its green. I receive an email, so I can hunt down the NIC and DNSSEC information of the TLD and add it to the database. Testlabs are all done by adding the information in a database (except for location of markers and KML files, which are automatically picked up) Over the next few days, after my presentation, I'll add an input box so people can add or update entries into the database that generates the map and markers. Paul From paf at cisco.com Tue Nov 20 00:14:51 2007 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Tue, 20 Nov 2007 06:14:51 +0100 Subject: [dnssec-deployment] DNSSEC Deployment Google Map In-Reply-To: References: Message-ID: On 20 nov 2007, at 03.48, Paul Wouters wrote: > Over the next few days, after my presentation, I'll add an input box > so > people can add or update entries into the database that generates > the map > and markers. Paul, my hat is off to you. Very very cool! Patrik From olaf at NLnetLabs.nl Tue Nov 20 01:30:19 2007 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Tue, 20 Nov 2007 09:30:19 +0300 Subject: [dnssec-deployment] DNSSEC Deployment Google Map In-Reply-To: References: Message-ID: Ceeeeewwwl You may also want to check out Lars less geographical representation of the deployment data: http://utility.nokia.net/~lars/meter/dnssec.html On 20Nov 2007, at 5:31 AM, Paul Wouters wrote: > > Hi, > > As part of my DNSSEC Deployment presentation at Sector (http://www.sector.ca > ) > tomorrow, I created a google map of the current DNSSEC deployment, > as it is > known to me (and the DNS). > > http://www.xelerance.com/dnssec/ > > The map lists production zones, testbeds and dead projects. If you > have any > additions or updates, feel free to email them to me. > > Paul Wouters > Xelerance Corp > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: > > and older material is at > ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 227 bytes Desc: This is a digitally signed message part Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20071120/c9de9ce6/attachment.bin From dave at corecom.com Tue Nov 20 07:53:32 2007 From: dave at corecom.com (Dave Piscitello) Date: Tue, 20 Nov 2007 07:53:32 -0500 Subject: [dnssec-deployment] DNSSEC Deployment Google Map In-Reply-To: References: Message-ID: <4742D8CC.2010101@corecom.com> This is very cool indeed. Nicely done. How would you represent GTLDs? Perhaps GOV could be a pin in DC? MIL a pin in Fort Huahacha:-) What about EU? Not intending to rain on anyone's parade, but an outsider may interpret "discontinued" in a very different way from the DNSSEC-engaged community; for example, it's significant (to me) that DE is "discontinued" (if I read this correctly). Did DE discontinue because it was too difficult to implement on a large scale, or did they lose faith in the global adoption? If I can speculate in this manner, so can nay-sayers. Perhaps some clarity in the labeling would save some confusion and embarrassment? The other negative comments this might attract include "didn't the USG fund DNSSEC projects? Why is no USG-sponsored zone listed?" These comments of course only illustrate how compelling your map truly is: visualizing DNSSEC calls attention to both successes and failures. Paul Wouters wrote: > Hi, > > As part of my DNSSEC Deployment presentation at Sector (http://www.sector.ca) > tomorrow, I created a google map of the current DNSSEC deployment, as it is > known to me (and the DNS). > > http://www.xelerance.com/dnssec/ > > The map lists production zones, testbeds and dead projects. If you have any > additions or updates, feel free to email them to me. > > Paul Wouters > Xelerance Corp > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: > and older material is at > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dave.vcf Type: text/x-vcard Size: 220 bytes Desc: not available Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20071120/29baac75/attachment.vcf From Olivier.Guillard at nic.fr Wed Nov 21 06:48:48 2007 From: Olivier.Guillard at nic.fr (Olivier Guillard / AFNIC) Date: Wed, 21 Nov 2007 12:48:48 +0100 Subject: DNS cache issue Message-ID: <20071121114848.GA1963@james.nic.fr> Colleagues, I'm currently looking at DNSsec. The answer to this question may be trivial for some of you so I ask it here: If I query my NS cache for a list of ns that are normally signed, I don't get it: [guillard]$ dig dnssec.se @dns-cache.nic.fr ns +dnssec +multiline ; <<>> DiG 9.3.1 <<>> dnssec.se @dns-cache.nic.fr ns +dnssec +multiline ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29602 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dnssec.se. IN NS ;; ANSWER SECTION: dnssec.se. 253 IN NS primary.se. dnssec.se. 253 IN NS secondary.se. dnssec.se. 253 IN NS ns.dnssec.se. ;; Query time: 0 msec ;; SERVER: 192.134.4.163#53(192.134.4.163) ;; WHEN: Wed Nov 21 12:31:50 2007 ;; MSG SIZE rcvd: 101 To get the RRSIGs in response, I need to query directly ns.dnssec.se [guillard]$ dig dnssec.se @ns.dnssec.se ns +dnssec +multiline ; <<>> DiG 9.3.1 <<>> dnssec.se @ns.dnssec.se ns +dnssec +multiline ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59523 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dnssec.se. IN NS ;; ANSWER SECTION: dnssec.se. 300 IN NS secondary.se. dnssec.se. 300 IN NS ns.dnssec.se. dnssec.se. 300 IN NS primary.se. dnssec.se. 300 IN RRSIG NS 5 2 300 20071221034602 ( 20071121034602 18476 dnssec.se. v1df/DmzpftcBlMCCjvS8b6K+81S7S08U+8ArfIPpesZ ixPftN29MvGpslOjO4uKAk5GXNySqIK7oyul6vSAIALl /8sG4GJHtlTisz6zHPmkUAIoE6PMoTxOTDU+IFv+6Ceo XSofv01Ay7KM/2PEJpy9obYEH6HKCiOnCndZA5w= ) ...snip... Question: Why ? Have I missed something ? Thanks, -- Olivier From wouter at nlnetlabs.nl Wed Nov 21 07:23:50 2007 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Wed, 21 Nov 2007 13:23:50 +0100 Subject: [dnssec-deployment] DNS cache issue In-Reply-To: References: Message-ID: <47442356.1060206@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Olivier, I guess you have to enable dnssec on the dns-cache server, for bind it is dnssec-enable: yes (and dnssec-validation: yes to actually check those signatures) dnssec-must-be-secure dunno what that option does :) Best regards, Wouter Olivier Guillard / AFNIC wrote: > Colleagues, > > I'm currently looking at DNSsec. > > The answer to this question may be trivial for some of you so I > ask it here: > > If I query my NS cache for a list of ns that are normally signed, > I don't get it: > > ...snip... > > > > Question: Why ? Have I missed something ? > > > Thanks, > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHRCNWkDLqNwOhpPgRAl4FAJ0QcTEywPsARuzNdW4C8PsgT18TJwCdGraO uyIAEJmeqoaOEtdr071ev88= =2b1Q -----END PGP SIGNATURE----- From paul at xelerance.com Wed Nov 21 11:21:26 2007 From: paul at xelerance.com (Paul Wouters) Date: Wed, 21 Nov 2007 11:21:26 -0500 (EST) Subject: [dnssec-deployment] DNS cache issue In-Reply-To: References: Message-ID: On Wed, 21 Nov 2007, W.C.A. Wijngaards wrote: > I guess you have to enable dnssec on the dns-cache server, > for bind it is dnssec-enable: yes > (and dnssec-validation: yes to actually check those signatures) > dnssec-must-be-secure dunno what that option does :) Don't enable that. It causes all verifiable insecure answers into servfail's to protect you in the world were everyone is using DNSSEC :) If you use a redhat/fedora bind 9.5 version, you must also add the option: edns: yes; which redhat patched in, probably after running into bad consumer routers dropping edns packets. Paul From Olivier.Guillard at nic.fr Wed Nov 21 11:52:19 2007 From: Olivier.Guillard at nic.fr (Olivier Guillard) Date: Wed, 21 Nov 2007 17:52:19 +0100 Subject: [dnssec-deployment] DNS cache issue In-Reply-To: <47442356.1060206@nlnetlabs.nl> <79F42435-DA95-4B08-BF51-49528CF0CE5F@NLnetLabs.nl> References: <47442356.1060206@nlnetlabs.nl> <79F42435-DA95-4B08-BF51-49528CF0CE5F@NLnetLabs.nl> Message-ID: <20071121165219.GA9814@james.nic.fr> Thanks ! here was the problem: doc bind 9.3.1 (my cache server) >..snip.. dnssec-enable Enable DNSSEC support in named. Unless set to yes named behaves as if it does not support DNSSEC. The default is no. ^^^^^^^^^^^^^^^^^ bind 9.5 http://www.isc.org/sw/bind/arm95/Bv9ARM-all.html > ..snip.. dnssec-enable Enable DNSSEC support in named. Unless set to yes, named behaves as if it does not support DNSSEC. The default is yes. -> a bit confusing (: If I understand well, the default is now "yes" but it should be set to "yes" anyway since otherwise it would behave as if it would not support DNSSEC ? I like it (: More seriously, I see here a potential issue, since many users on the internet may have to use cache servers without being able to change this bit. Do you see situation where a recursive server operator could need to explicitly set "dnssec-enable" to "no" ? Best, --- Olivier > Don't enable that. It causes all verifiable insecure answers into enebeling it, you are would be sure that all the park wouldn't receive any [wrong] answer: objective met ! (: le mercredi 21 novembre ? 13 H 14 , Olaf M. Kolkman a ecrit : > > Did you set: > > dnssec-enable: yes; > > in the options of the named.conf dns-cache.nic.fr? > > > --Olaf > > > On 21Nov 2007, at 12:48 PM, Olivier Guillard / AFNIC wrote: > > >Colleagues, > > > >I'm currently looking at DNSsec. > > > >The answer to this question may be trivial for some of you so I > >ask it here: > > > >If I query my NS cache for a list of ns that are normally signed, > >I don't get it: > > > >[guillard]$ dig dnssec.se @dns-cache.nic.fr ns +dnssec +multiline > > > >; <<>> DiG 9.3.1 <<>> dnssec.se @dns-cache.nic.fr ns +dnssec > >+multiline > >; (1 server found) > >;; global options: printcmd > >;; Got answer: > >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29602 > >;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > > >;; OPT PSEUDOSECTION: > >; EDNS: version: 0, flags: do; udp: 4096 > >;; QUESTION SECTION: > >;dnssec.se. IN NS > > > >;; ANSWER SECTION: > >dnssec.se. 253 IN NS primary.se. > >dnssec.se. 253 IN NS secondary.se. > >dnssec.se. 253 IN NS ns.dnssec.se. > > > >;; Query time: 0 msec > >;; SERVER: 192.134.4.163#53(192.134.4.163) > >;; WHEN: Wed Nov 21 12:31:50 2007 > >;; MSG SIZE rcvd: 101 > > > >To get the RRSIGs in response, I need to query directly ns.dnssec.se > > > >[guillard]$ dig dnssec.se @ns.dnssec.se ns +dnssec +multiline > >; <<>> DiG 9.3.1 <<>> dnssec.se @ns.dnssec.se ns +dnssec +multiline > >; (1 server found) > >;; global options: printcmd > >;; Got answer: > >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59523 > >;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: > >5 > > > >;; OPT PSEUDOSECTION: > >; EDNS: version: 0, flags: do; udp: 4096 > >;; QUESTION SECTION: > >;dnssec.se. IN NS > > > >;; ANSWER SECTION: > >dnssec.se. 300 IN NS secondary.se. > >dnssec.se. 300 IN NS ns.dnssec.se. > >dnssec.se. 300 IN NS primary.se. > >dnssec.se. 300 IN RRSIG NS 5 2 300 20071221034602 ( > > 20071121034602 18476 dnssec.se. > > v1df/DmzpftcBlMCCjvS8b6K+81S7S08U > >+8ArfIPpesZ > > > >ixPftN29MvGpslOjO4uKAk5GXNySqIK7oyul6vSAIALl > > /8sG4GJHtlTisz6zHPmkUAIoE6PMoTxOTDU > >+IFv+6Ceo > > XSofv01Ay7KM/ > >2PEJpy9obYEH6HKCiOnCndZA5w= ) > >...snip... > > > > > > > >Question: Why ? Have I missed something ? > > > > > >Thanks, > > > >-- > >Olivier > > > >############################################################# > >This message is sent to you because you are subscribed to > > the mailing list . > >To unsubscribe, E-mail to: > >A public archive is available here: > > > >and older material is at > > > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ > > /> le mercredi 21 novembre ? 13 H 23 , W.C.A. Wijngaards a ecrit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Olivier, > > I guess you have to enable dnssec on the dns-cache server, > for bind it is dnssec-enable: yes > (and dnssec-validation: yes to actually check those signatures) > dnssec-must-be-secure dunno what that option does :) > > Best regards, > Wouter > > Olivier Guillard / AFNIC wrote: > > Colleagues, > > > > I'm currently looking at DNSsec. > > > > The answer to this question may be trivial for some of you so I > > ask it here: > > > > If I query my NS cache for a list of ns that are normally signed, > > I don't get it: > > > > ...snip... > > > > > > > > Question: Why ? Have I missed something ? > > > > > > Thanks, > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFHRCNWkDLqNwOhpPgRAl4FAJ0QcTEywPsARuzNdW4C8PsgT18TJwCdGraO > uyIAEJmeqoaOEtdr071ev88= > =2b1Q > -----END PGP SIGNATURE----- le mercredi 21 novembre ? 11 H 21 , Paul Wouters a ecrit : > On Wed, 21 Nov 2007, W.C.A. Wijngaards wrote: > > > I guess you have to enable dnssec on the dns-cache server, > > for bind it is dnssec-enable: yes > > (and dnssec-validation: yes to actually check those signatures) > > dnssec-must-be-secure dunno what that option does :) > > Don't enable that. It causes all verifiable insecure answers into > servfail's to protect you in the world were everyone is using DNSSEC :) > > If you use a redhat/fedora bind 9.5 version, you must also add > the option: > > edns: yes; > > which redhat patched in, probably after running into bad consumer routers > dropping edns packets. > > Paul -- Olivier Guillard --- || AFNIC - Immeuble International || 2 rue Stephenson - Montigny-le-Bretonneux || 78181, Saint-Quentin-en-Yvelines CEDEX, France || http://www.nic.fr/ || mailto:Olivier.Guillard at nic.fr || tel: +33 1 39 30 83 31 From paul at vix.com Wed Nov 21 13:12:21 2007 From: paul at vix.com (Paul Vixie) Date: Wed, 21 Nov 2007 18:12:21 +0000 Subject: DNSSEC came up on slashdot today Message-ID: <95225.1195668741@sa.vix.com> http://it.slashdot.org/comments.pl?sid=366943&cid=21433759 From steve at shinkuro.com Wed Nov 21 13:41:02 2007 From: steve at shinkuro.com (Crocker Steve) Date: Wed, 21 Nov 2007 13:41:02 -0500 Subject: [dnssec-deployment] DNSSEC came up on slashdot today In-Reply-To: References: Message-ID: <41383C9C-FC7E-440F-A310-39CAD78BCF0A@shinkuro.com> Here's the full text of the slashdot posting. > Until TLD's start signing zones, DNSSEC won't see the light of day. > Until registrars figure out how to securely regsister and manage > keys, DNSSEC is DoA > Until zone managers start signing zones, DNSSEC won't achieve > critical mass > Without critical mass, uneven DNSSEC deployment has no value > Without stub resolver support, DNSSEC is meaningless > Until all the above happen, there is no business case for DNSSEC > and TLD owners won't deploy it. I wouldn't choose quite the same language, but I think the specifics are on target. We do indeed need to get the TLDs signed, we do indeed need to have registrars accept keys from registrants -- see below for a bit more -- and we do indeed need for stub (or recursive) resolvers ask for signed responses and make use of them. Here's a few details that suggest the picture is not so bleak. 1. A few TLDs are signed and more are coming. When the NSEC3 RFC is published, more TLDs will sign their zones. 2. We are beginning to work with registrars. In addition to providing a path for enterprises to convey their keys (or fingerprints), there will also have to be support for those registrants who do not manage their own zones. That is, for the many, many registrants who depend on the registrar to manage their zones, the registrars will also have to provide DNSSEC service. I expect to see successful worked examples in six months, give or take. 3. There is work underway to have DNSSEC implemented in the major end user systems. Steve On Nov 21, 2007, at 1:12 PM, Paul Vixie wrote: > http://it.slashdot.org/comments.pl?sid=366943&cid=21433759 > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: Lists/dnssec-deployment/> > and older material is at > From dave at corecom.com Wed Nov 21 13:52:53 2007 From: dave at corecom.com (Dave Piscitello) Date: Wed, 21 Nov 2007 13:52:53 -0500 Subject: [dnssec-deployment] DNSSEC came up on slashdot today In-Reply-To: References: Message-ID: <47447E85.6070400@corecom.com> I like your response. You should post it. Or I will, on my blog, attributing to you. The community suffers when only curmudgeons speak out. Crocker Steve wrote: > Here's the full text of the slashdot posting. > >> Until TLD's start signing zones, DNSSEC won't see the light of day. >> Until registrars figure out how to securely regsister and manage keys, >> DNSSEC is DoA >> Until zone managers start signing zones, DNSSEC won't achieve critical >> mass >> Without critical mass, uneven DNSSEC deployment has no value >> Without stub resolver support, DNSSEC is meaningless >> Until all the above happen, there is no business case for DNSSEC and >> TLD owners won't deploy it. > > I wouldn't choose quite the same language, but I think the specifics are > on target. We do indeed need to get the TLDs signed, we do indeed need > to have registrars accept keys from registrants -- see below for a bit > more -- and we do indeed need for stub (or recursive) resolvers ask for > signed responses and make use of them. > > Here's a few details that suggest the picture is not so bleak. > > 1. A few TLDs are signed and more are coming. When the NSEC3 RFC is > published, more TLDs will sign their zones. > > 2. We are beginning to work with registrars. In addition to providing a > path for enterprises to convey their keys (or fingerprints), there will > also have to be support for those registrants who do not manage their > own zones. That is, for the many, many registrants who depend on the > registrar to manage their zones, the registrars will also have to > provide DNSSEC service. I expect to see successful worked examples in > six months, give or take. > > 3. There is work underway to have DNSSEC implemented in the major end > user systems. > > Steve > > > > > On Nov 21, 2007, at 1:12 PM, Paul Vixie wrote: > >> http://it.slashdot.org/comments.pl?sid=366943&cid=21433759 >> >> ############################################################# >> This message is sent to you because you are subscribed to >> the mailing list . >> To unsubscribe, E-mail to: >> A public archive is available here: >> >> and older material is at >> > > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: > > and older material is at > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dave.vcf Type: text/x-vcard Size: 220 bytes Desc: not available Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20071121/189a3d84/attachment.vcf From jaap at NLnetLabs.nl Wed Nov 21 14:08:14 2007 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 21 Nov 2007 20:08:14 +0100 Subject: [dnssec-deployment] DNS cache issue In-Reply-To: Your message of Wed, 21 Nov 2007 17:52:19 +0100. Message-ID: <200711211908.lALJ8E8b079937@bartok.nlnetlabs.nl> More seriously, I see here a potential issue, since many users on the internet may have to use cache servers without being able to change this bit. Do you see situation where a recursive server operator could need to explicitly set "dnssec-enable" to "no" ? Earlier versions of bind has dnssec-enable default set to "no", later versions have it set default to "yes" (and the arm languages is indeed unclear). My expectation is that when the ISPs haven't updated older BIND versions they likely have other security issues to worry about as well. jaap From brettcarr at gmail.com Wed Nov 21 17:54:06 2007 From: brettcarr at gmail.com (Brett) Date: Wed, 21 Nov 2007 22:54:06 +0000 Subject: DNSSEC came up on The Register aswell today Message-ID: <314dbe240711211454h160f6b6ekbe2a764e0d6cbf3d@mail.gmail.com> Some of you may be interested to know there was an article in the English IT press today touching on the subject of dnssec aswell. http://www.theregister.co.uk/2007/11/20/dns_security_survey/comments/ Brett From Olivier.Guillard at nic.fr Wed Nov 21 18:02:12 2007 From: Olivier.Guillard at nic.fr (Olivier Guillard) Date: Thu, 22 Nov 2007 00:02:12 +0100 Subject: [dnssec-deployment] DNS cache issue In-Reply-To: <200711211908.lALJ8E8b079937@bartok.nlnetlabs.nl> References: <200711211908.lALJ8E8b079937@bartok.nlnetlabs.nl> Message-ID: <20071121230212.GA16408@james.nic.fr> Hi Jaap, > Earlier versions of bind has dnssec-enable default set to "no", > later versions have it set default to "yes" (and the arm languages > is indeed unclear). Yes, documentation is a hard job, I'm honnestly always impressed by the hudge energy put in and amount of work performed to keep it up to date. > My expectation is that when the ISPs haven't > updated older BIND versions they likely have other security issues > to worry about as well. +1 > to explicitly set "dnssec-enable" to "no" ? Having thought about it, I see no reason not to have this flag available. --- Olivier le mercredi 21 novembre ? 20 H 08 , Jaap Akkerhuis a ecrit : > > More seriously, I see here a potential issue, since many users > on the internet may have to use cache servers without being able > to change this bit. > > Do you see situation where a recursive server operator could need > to explicitly set "dnssec-enable" to "no" ? > > Earlier versions of bind has dnssec-enable default set to "no", > later versions have it set default to "yes" (and the arm languages > is indeed unclear). My expectation is that when the ISPs haven't > updated older BIND versions they likely have other security issues > to worry about as well. > > jaap -- Olivier Guillard --- || AFNIC - Immeuble International || 2 rue Stephenson - Montigny-le-Bretonneux || 78181, Saint-Quentin-en-Yvelines CEDEX, France || http://www.nic.fr/ || mailto:Olivier.Guillard at nic.fr From paul at xelerance.com Thu Nov 22 00:52:28 2007 From: paul at xelerance.com (Paul Wouters) Date: Thu, 22 Nov 2007 00:52:28 -0500 (EST) Subject: [dnssec-deployment] DNS cache issue In-Reply-To: <200711211908.lALJ8E8b079937@bartok.nlnetlabs.nl> References: <200711211908.lALJ8E8b079937@bartok.nlnetlabs.nl> Message-ID: On Wed, 21 Nov 2007, Jaap Akkerhuis wrote: > Do you see situation where a recursive server operator could need > to explicitly set "dnssec-enable" to "no" ? > > Earlier versions of bind has dnssec-enable default set to "no", > later versions have it set default to "yes" (and the arm languages > is indeed unclear). My expectation is that when the ISPs haven't > updated older BIND versions they likely have other security issues > to worry about as well. Yes, but they don't worry as much about security issues, as they do about endusers calling them that their DNS is "down" :) Though an ISP should have the resources to read a Changelog :P Paul From paul at xelerance.com Thu Nov 22 01:11:51 2007 From: paul at xelerance.com (Paul Wouters) Date: Thu, 22 Nov 2007 01:11:51 -0500 (EST) Subject: [dnssec-deployment] DNSSEC Deployment Google Map In-Reply-To: <4742D8CC.2010101@corecom.com> References: <4742D8CC.2010101@corecom.com> Message-ID: On Tue, 20 Nov 2007, Dave Piscitello wrote: > How would you represent GTLDs? Perhaps GOV could be a pin in DC? MIL a pin in > Fort Huahacha:-) What about EU? I've used different colour pins for GTLD's, but indeed, putting them on the map might prove to be difficult in the future. I'll gladly handle that problem when it happens though. It means DNSSEC is getting deployed.... The .eu pin would probably be put into Brussels :) > Not intending to rain on anyone's parade, but an outsider may interpret > "discontinued" in a very different way from the DNSSEC-engaged community; for > example, it's significant (to me) that DE is "discontinued" (if I read this > correctly). Uhm. It was .nl that was discontinued, not .ge. > Did DE discontinue because it was too difficult to implement on a > large scale, or did they lose faith in the global adoption? If I can speculate > in this manner, so can nay-sayers. Perhaps some clarity in the labeling would > save some confusion and embarrassment? I have no official statement from .nl. But from what I've heard (I stopped attending .nl NIC meetings a few years ago because I felt misrepresented) it was more a matter of priorities, resources and reorganisation, combined with two new versions of registration systems that caused a lot of urgent operational issues. The new registration system, at the time still in the design phase, did not have DNSSEC requirements in its design, despite the .nl.nl and the shadow tree experiments being very successful. Neither did the latest registration system (DRS 4.1), released a few weeks ago. > The other negative comments this might attract include "didn't the USG fund > DNSSEC projects? Why is no USG-sponsored zone listed?" I've added .gov and the root, after being informed of those testing zones. I did not add all the arpa zones seperately. > These comments of course only illustrate how compelling your map truly is: > visualizing DNSSEC calls attention to both successes and failures. If I look at the current deployment, and the statistics from the ccNSO report, then things are looking realy promising for the new DNSSEC deployments in the next year. I am hoping NSEC3 issues will be resolved soon (Vancouver?) and that we can convince NAT router vendors to upgrade their firmwares. The presentation I gave yesterday at SecTor was also promising. People from banks told me that they were keeping tabs on DNSSEC developments. And some people contacted me later and said they now understood DNSSEC a lot better, and were much more positive about DNSSEC then before. Let the snowball effect runs its course :) My presentation available at: http://www.xelerance.com/talks/sector2007/Sector2007DNSSEC.pdf Paul From Mats.Dufberg at teliasonera.com Thu Nov 22 04:21:15 2007 From: Mats.Dufberg at teliasonera.com (Mats.Dufberg at teliasonera.com) Date: Thu, 22 Nov 2007 10:21:15 +0100 Subject: [dnssec-deployment] DNSSEC came up on slashdot today In-Reply-To: References: Message-ID: > From: DNSSEC deployment > [mailto:dnssec-deployment at shinkuro.com] On Behalf Of Crocker Steve > Sent: den 21 november 2007 19:41 (...) > > Without stub resolver support, DNSSEC is meaningless (...) > below for a bit more -- and we do indeed need for stub (or > recursive) > resolvers ask for signed responses and make use of them. I think that the original author of the blog says that DNSsec is meaningless until the client computer does the validation. I think it is important that we point out that that is the goal, but that having the dedicated, recursive nameserver doing the validation makes DNSsec useful. But you should use a recursive nameserver as close to the client as possible. If we would wait for the complete implementation of DNSsec before we start implementing DNSsec we would wait forever... Mats ------------------------------------------ Mats Dufberg TeliaSonera Networks N&P, Infrastructure Server Production SMD ServerNet +46-70-2582588 mats.dufberg at teliasonera.com ------------------------------------------ From eoster at cs.ucla.edu Thu Nov 22 19:53:30 2007 From: eoster at cs.ucla.edu (Eric Osterweil) Date: Thu, 22 Nov 2007 16:53:30 -0800 Subject: [dnssec-deployment] DNSSEC Deployment Google Map In-Reply-To: References: Message-ID: <05782BF0-0B33-4349-BB63-CAF36ABC4CE4@cs.ucla.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 19, 2007, at 6:48 PM, Paul Wouters wrote: > On Mon, 19 Nov 2007, Crocker Steve wrote: > >> Please tell me how this is done. There is undoubtedly more, but >> not enough to >> change the basic picture. I'd rather concentrate on how to get >> the right data >> to flow so this is maintained and up to date. > > Well, at this point, it basically AXFR's the root from f and then > tries > to query for dnskey records for all entries. It then maps those > against > a list of google KML files and colours its green. I receive an email, > so I can hunt down the NIC and DNSSEC information of the TLD and > add it > to the database. > > Testlabs are all done by adding the information in a database > (except for > location of markers and KML files, which are automatically picked up) > > Over the next few days, after my presentation, I'll add an input > box so > people can add or update entries into the database that generates > the map > and markers. Would you be interested in getting a feed, or pulling from SecSpider? Maybe with a couple of cross-links to each other we could handle the registration and any discovery for you (as we do this anyway)? :) Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHRiSOK/tq6CJjZQIRAh/gAJ0WWK0IDe2O9vSsIR6gvsHZykUiDQCglpwh oc8kgJTU/u/NNgAZWcICpQc= =RYjN -----END PGP SIGNATURE----- From galvin at elistx.com Sat Nov 24 15:01:47 2007 From: galvin at elistx.com (James M Galvin) Date: Sat, 24 Nov 2007 15:01:47 -0500 Subject: next meeting: 13 December 2007 Message-ID: <389527C3C4FDB2666BF986C0@[10.0.0.11]> Our next regular, first Wednesday of the month meeting would be 5 December. However, as this is during the week of the IETF we are going to push this meeting. Also, because of other conflicts, we are going to schedule this meeting on Thursday, 13 December 2007, at 10am Eastern (1500 UTC). Please make a note of it. The topic for discussion will be: Algorithm Rollover We are currently arranging speakers so there will be more to say the week before the meeting. Similarly, the first meeting of the new year would ordinarily be on Wednesday, 2 January 2008. Because of holiday schedules we are going to push this meeting to Wednesdaay, 9 January 2008, at 10am Eastern (1500 UTC). Please make a note of it. Jim From lutz at iks-jena.de Tue Nov 27 06:45:39 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 27 Nov 2007 12:45:39 +0100 Subject: My personal DNSSEC key distribution Message-ID: [This message has also been posted to de.comp.security.misc,comp.security.misc.] In order to provide an alternative starting point for validation DNSSEC key chains, I put the list of the DNSSEC keys, I'm responsible for, into the famous world wide web: https://www.iks-jena.de/leistungen/keys.txt Have fun. -- If you are not interested in DNSSEC, please killfile me. From galvin at elistx.com Fri Nov 30 17:37:56 2007 From: galvin at elistx.com (James M Galvin) Date: Fri, 30 Nov 2007 17:37:56 -0500 Subject: meeting announcement: 13 December 2007 Message-ID: <898D2D86567110D95B871ABD@[192.168.1.3]> This meeting will be held at the *SPECIAL* time of Thursday, 13 December, 1500 UTC as follows. 0700 Los Angeles, San Francisco 0800 Phoenix 0800 Salt Lake City 1000 Washington 1500 UTC 1500 London 1600 Netherlands 1700 Israel 0000 Tokyo (the next day) 0200 Melbourne (the next day) TELECONFERENCE LOGISTICS ARE CHANGING. SORRY BUT I DO NOT YET KNOW WHAT THE NEW LOGISTICS WILL BE. I WILL SEND A FOLLOWUP NOTE WHEN I HAVE THE INFORMATION. USA Toll Free Number: TBD USA Toll Number: TBD Passcode: TBD Leader: James Galvin employed by ICANN if speaking to an operator Jabber: dnssec-deployment at conference.jabber.org This is a public room. DIAL OUT: 1. ISC SIP Bridge - contact me for SIP identifiers DRAFT AGENDA * Algorithm Rollover Over a period of time, the lengths of the keys and the choices of algorithms used in DNSSEC will need to change.? The current specification uses RSA in lengths from 1024 bits to 4096 -- as documented in RFC3110 and SHA-1.? Over a period of time, the suggested minimal key lengths and the maximal key length a resolver is required to accept presumably will increase.? More interestingly, SHA-1 will be replaced with some other algorithm, probably SHA-256 in the SHA-2 family.? Also, it's been suggested that ECC (elliptic curve crypto) replace RSA because it uses much shorter keys with the same crypto strength.? As the RSA key sizes grow to keep up with the requirements for adequate strength, the computational cost grows too. ECC is partially encumbered by patents.? It's ok to use it now without paying royalties, but the fastest implementations require patented methods.? The patents will expire in a few years, so this will mean a step function improvement in performance. This will be structured similar to a panel session at a conference. We have several guests who have been invited to speak on the issue and then we will have a discussion based on questions from other participants. The invited guests are as follows. Olaf Kolkman Olaf ?lafur Gu?mundsson Russ Housley Sam Hartman Tim Polk The following questions have been suggested to the panelists to help start and guide the discussion. ? * Do you agree with the statements above?? Is any of this documented in a way that's accessible to the broad community? * What is the method for deciding when the limits and algorithms should change?? Who does this and by what process? How is such information promulgated? * What is the interaction with the IETF process?? Do these changes get documented in RFCs?? Standards track?? Informational?? Best Practices?? Protocol Parameter Registry? * What are the dependencies in the process?? Presumably resolvers have to be able to accept new key lengths and algorithms before they're used in zones.? The algorithms have to be available in the libraries on the relevant platforms -- Windows, Linux, Mac, etc. -- before the resolver code can make use of them.? We need some sort of road map showing the dependencies and some sort of method of testing readiness locally and perhaps some additional means of measuring readiness globally. * Is there a way to label products to show their conformance to the current details of key size and algorithms? If a box says "Implements RFCs 4033, 4034 and 4035," the buyer won't know whether it meets the current key size and algorithm requirements.