RIPE NCC DNSSEC on the reverse tree update.
Dear Colleagues, As part of the project to deploy DNSSEC in the RIPE NCC service region, the RIPE NCC has further expanded the signing of zones from the reverse tree. The following zones are now signed: ripe.net ripencc.com ripencc.net ripencc.org ripe-ncc.com ripe-ncc.net ripe-ncc.org 89.in-addr.arpa 90.in-addr.arpa 213.in-addr.arpa 213.in-addr.arpa. 193.in-addr.arpa. 195.in-addr.arpa. 212.in-addr.arpa. 194.in-addr.arpa. 145.in-addr.arpa. If you want to configure your resolvers to verify these zones using DNSSEC, *key signing keys* for these zones are available at: https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys.txt For information about how to use the keys, and for further details about DNSSEC deployment at the RIPE NCC, please see: http://www.ripe.net/projects/disi/keys/ The following zones will now accept secure delegations (DS Records) via the addition of a "ds-rdata:" record in the whois domain object for the zone: 89.in-addr.arpa. 90.in-addr.arpa. 213.in-addr.arpa. 193.in-addr.arpa. 195.in-addr.arpa. Regards Brett Carr RIPE NCC
On Thu, 24 Nov 2005 14:13:29 +0100, "Brett Carr" <brettcarr@ripe.net> said:
The following zones will now accept secure delegations (DS Records) via the addition of a "ds-rdata:" record in the whois domain object for the zone:
89.in-addr.arpa. 90.in-addr.arpa. 213.in-addr.arpa. 193.in-addr.arpa. 195.in-addr.arpa.
I tried to add add a ds-rdata attribute to 176.195.in-addr.arpa, but I got: ***Error: DS records are not accepted for this zone. -- Alex
-----Original Message----- From: Alexander Gall [mailto:gall@switch.ch] Sent: 25 November 2005 08:59 To: Brett Carr Cc: dns-wg@ripe.net Subject: Re: [dns-wg] RIPE NCC DNSSEC on the reverse tree update.
On Thu, 24 Nov 2005 14:13:29 +0100, "Brett Carr" <brettcarr@ripe.net> said:
The following zones will now accept secure delegations (DS Records) via the addition of a "ds-rdata:" record in the whois domain object for the zone:
89.in-addr.arpa. 90.in-addr.arpa. 213.in-addr.arpa. 193.in-addr.arpa. 195.in-addr.arpa.
I tried to add add a ds-rdata attribute to 176.195.in-addr.arpa, but I got:
***Error: DS records are not accepted for this zone.
Mmm thats odd, I'll look into it. Will get back to you. -- Brett Carr RIPE Network Coordination Centre Systems Engineer -- Operations Group Amsterdam, Netherlands GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8
On Fri, 25 Nov 2005 09:17:14 +0100, "Brett Carr" <brettcarr@ripe.net> said:
-----Original Message----- From: Alexander Gall [mailto:gall@switch.ch] Sent: 25 November 2005 08:59 To: Brett Carr Cc: dns-wg@ripe.net Subject: Re: [dns-wg] RIPE NCC DNSSEC on the reverse tree update.
On Thu, 24 Nov 2005 14:13:29 +0100, "Brett Carr" <brettcarr@ripe.net> said:
The following zones will now accept secure delegations (DS Records) via the addition of a "ds-rdata:" record in the whois domain object for the zone:
89.in-addr.arpa. 90.in-addr.arpa. 213.in-addr.arpa. 193.in-addr.arpa. 195.in-addr.arpa.
I tried to add add a ds-rdata attribute to 176.195.in-addr.arpa, but I got:
***Error: DS records are not accepted for this zone.
Mmm thats odd, I'll look into it. Will get back to you.
Thanks. Maybe I should add that I submitted the request yesterday at around 12:30, i.e. before you posted the announcement (precognition can be a pain ;-) Since I got the reply from the robot at midnight, I figured that this shouldn't have mattered, but maybe it did and the request was actually processed before the service was enabled? In that case, I should probably just retry. -- Alex
-----Original Message----- From: Alexander Gall [mailto:gall@switch.ch] Sent: 25 November 2005 10:07 To: Brett Carr Cc: dns-wg@ripe.net Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update.
I tried to add add a ds-rdata attribute to 176.195.in-addr.arpa, but I got:
***Error: DS records are not accepted for this zone.
Mmm thats odd, I'll look into it. Will get back to you.
Thanks. Maybe I should add that I submitted the request yesterday at around 12:30, i.e. before you posted the announcement (precognition can be a pain ;-) Since I got the reply from the robot at midnight, I figured that this shouldn't have mattered, but maybe it did and the request was actually processed before the service was enabled? In that case, I should probably just retry.
Alex, yes I should try it again if I were you. I was literally configuring it as I sent the e-mail to the dns-wg. Let me know if it doesnt work and I'll look into it. Thanks Brett.. -- Brett Carr RIPE Network Coordination Centre Systems Engineer -- Operations Group Amsterdam, Netherlands GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8
Brett, On Fri, 25 Nov 2005 10:25:42 +0100, "Brett Carr" <brettcarr@ripe.net> said:
-----Original Message----- From: Alexander Gall [mailto:gall@switch.ch] Sent: 25 November 2005 10:07 To: Brett Carr Cc: dns-wg@ripe.net Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update.
I tried to add add a ds-rdata attribute to 176.195.in-addr.arpa, but I got:
***Error: DS records are not accepted for this zone.
Mmm thats odd, I'll look into it. Will get back to you.
Thanks. Maybe I should add that I submitted the request yesterday at around 12:30, i.e. before you posted the announcement (precognition can be a pain ;-) Since I got the reply from the robot at midnight, I figured that this shouldn't have mattered, but maybe it did and the request was actually processed before the service was enabled? In that case, I should probably just retry.
Alex, yes I should try it again if I were you. I was literally configuring it as I sent the e-mail to the dns-wg. Let me know if it doesnt work and I'll look into it.
I submitted another request and this one succeeded :-) However, I think there is a problem with ns.ripe.net. It doesn't return DNSSEC RRsets when the DO flag is set in the query: ; <<>> DiG 9.4.0a2 <<>> @ns.ripe.net 176.195.in-addr.arpa. soa +dnssec +norec +noauth +noadd ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 567 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;176.195.in-addr.arpa. IN SOA ;; ANSWER SECTION: 176.195.in-addr.arpa. 86400 IN SOA scsnms.switch.ch. hostmaster.switch.ch. 2005112409 28800 7200 604800 1800 ;; Query time: 59 msec ;; SERVER: 2001:610:240:0:53::193#53(2001:610:240:0:53::193) ;; WHEN: Fri Nov 25 11:43:12 2005 ;; MSG SIZE rcvd: 172 This should include the RRSIG(SOA) record in the answer section, which is actually there if you ask for it directly ; <<>> DiG 9.4.0a2 <<>> @ns.ripe.net 176.195.in-addr.arpa. rrsig +norec +noauth +noadd ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 328 ;; flags: qr aa; QUERY: 1, ANSWER: 5, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;176.195.in-addr.arpa. IN RRSIG ;; ANSWER SECTION: 176.195.in-addr.arpa. 86400 IN RRSIG SOA 5 4 86400 20051208112546 20051124112546 1691 176.195.in-addr.arpa. HRGiKQmRLK4Y26jWLH7GQSVCJTRu0g2H12orAIQyhAszpOAJNDWG0BZc YkX+ung8S6kv3009VaJfO7DfXprbXaypVJ6RVug6XKDAgD7iU4/aEhCx btQ/yGRnKLzKU3D6psoGoY0TddDD+Em9yXKAHnAB+J77D1gyV5BAd3op A6Y= 176.195.in-addr.arpa. 86400 IN RRSIG NS 5 4 86400 20051208075925 20051124075925 1691 176.195.in-addr.arpa. noQW84vwzB2YSVOA/wCwDDya9os0PYtjkXOki6BuV44RzSI76L13t0zu aC3QA+5Ho9e09o+zCoU2t4Lt+FYMKIUjFE2lC+lDhGTdU1RWUfMQkcxp GIbeH769p4BFPtNesFetJO5GObAHns40aWVavd2ev4sAzu9tqrYks93O A7s= 176.195.in-addr.arpa. 1800 IN RRSIG NSEC 5 4 1800 20051207142856 20051123142856 1691 176.195.in-addr.arpa. v/qm+7NZ448b5ahe59QopUtUeQv2epIda67gmGEc0R8wDdUB4b+CRo29 Wjbe15NN8Awv3eFX9Vffc7OZe4X4bcirqVKBFdzgCzYtjxcWxrwb3Q1q 3Ddpqv/P4ep4jUvbhcOyGxE4xinLiP8Ht00uvi7uMQPgQPLe+yi76PBc 2Tg= 176.195.in-addr.arpa. 86400 IN RRSIG DNSKEY 5 4 86400 20051208112546 20051124112546 1691 176.195.in-addr.arpa. L7BegdxxrNKBdPQ6xhL2zDdDB4CyNq+E6hIIoA0wuIRXx3AEhchTvN+J whx0YcPAcagGPlcbxMk8rFWhLqAQOacV1CYLAGGbpd/NEa6SHou0zbKg ZxYVtBr0yzEWLyuDd2F9wLLzsGiy/i+AestM1hlzm/wxOn8cq/9Em+ag oNE= 176.195.in-addr.arpa. 86400 IN RRSIG DNSKEY 5 4 86400 20051208112546 20051124112546 36555 176.195.in-addr.arpa. qBfqrQHCjdW2PV7XaabuYimfkl8lVYGZvO5EvxFSlA1TSwGzlx3F9ZFi 7kMwmTYH1ANJM9ZpEGHPr9bxeQPYWnMCV5PpwzaynUxALY8t0s1P5KFO yWmzQrXusGK+mkj8YF3SzCcSh0GUIxgJsAHLy2VKJUI4WMNAmPXeuWug IjoTgu/heYi3vJvtq3Gh53M8pLHSmGfbeiFn7glKvL3Ypb4FxlWs/W97 57TNODdnXBUFDALyDf7OTW3Mh6rUhBYGCns4j/9NYlSHvkyTd/ipbSiQ JDVtu1JqS++IZkFQh3C/diWBn/OImjalYWIjqm4GLBWpHRaLQAn0p6UM dDng9A== ;; Query time: 53 msec ;; SERVER: 2001:610:240:0:53::193#53(2001:610:240:0:53::193) ;; WHEN: Fri Nov 25 11:46:02 2005 ;; MSG SIZE rcvd: 1142 It looks to me like DNSSEC isn't enabled on ns.ripe.net. This also causes all sorts of errors being flagged by the delegation checker (<http://www.ripe.net/cgi-bin/delcheck/delcheck2.cgi>) that aren't really there. That tool seems to have some trouble with DO queries to our name servers as well :-( You might want to have a look at this. Actually, if this delegation checker is the one being used by the robot that process the inverse delegation requests, I don't understand why my request succeeded at all. Regards, Alex
-----Original Message----- From: Alexander Gall [mailto:gall@switch.ch] Sent: 25 November 2005 11:48 To: Brett Carr Cc: dns-wg@ripe.net Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update.
Brett,
Alex, yes I should try it again if I were you. I was literally configuring it as I sent the e-mail to the dns-wg. Let me know if it doesnt work and I'll look into it.
I submitted another request and this one succeeded :-)
However, I think there is a problem with ns.ripe.net. It doesn't return DNSSEC RRsets when the DO flag is set in the query:
; <<>> DiG 9.4.0a2 <<>> @ns.ripe.net 176.195.in-addr.arpa. soa +dnssec +norec +noauth +noadd ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 567 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;176.195.in-addr.arpa. IN SOA
;; ANSWER SECTION: 176.195.in-addr.arpa. 86400 IN SOA scsnms.switch.ch. hostmaster.switch.ch. 2005112409 28800 7200 604800 1800
;; Query time: 59 msec ;; SERVER: 2001:610:240:0:53::193#53(2001:610:240:0:53::193) ;; WHEN: Fri Nov 25 11:43:12 2005 ;; MSG SIZE rcvd: 172
This should include the RRSIG(SOA) record in the answer section, which is actually there if you ask for it directly
Alex, I found a small config typo, which I have fixed, it should be ok now though. Thanks for the feedback. Brett.. -- Brett Carr RIPE Network Coordination Centre Systems Engineer -- Operations Group Amsterdam, Netherlands GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8
Brett, On Fri, 25 Nov 2005 14:41:34 +0100, "Brett Carr" <brettcarr@ripe.net> said:
-----Original Message----- From: Alexander Gall [mailto:gall@switch.ch] Sent: 25 November 2005 11:48 To: Brett Carr Cc: dns-wg@ripe.net Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update.
[...]
However, I think there is a problem with ns.ripe.net. It doesn't return DNSSEC RRsets when the DO flag is set in the query:
[...]
I found a small config typo, which I have fixed, it should be ok now though.
Thanks, it looks good now. Did you have a chance to look (or have somebody else have a look :-) at <https://www.ripe.net/cgi-bin/delcheck/delcheck2.cgi> for the zone 176.195.in-addr.arpa? I can see two problems: - For some reason, the tool doesn't get replies to queries for NS and DNSKEY records at our name servers {merapi,scsnms}.switch.ch with the DO flag set. The tool then (erroneously) concludes that these RRsets are inconsistent among the servers for the zone. I see the queries coming in on our servers from 193.0.0.214. Could it be that the replies are filtered somwhere in your network (having strange flags and all that)? - It complains about the SEP Key (i.e. KSK) not being self-signed. I suppose this means that there is no RRSIG(DNSKEY) by the KSK. However, I'm pretty sure there are valid RRSIGs from both the ZSK and KSK. Regards, Alex
-----Original Message----- From: Alexander Gall [mailto:gall@switch.ch] Sent: 25 November 2005 15:22 To: Brett Carr Cc: dns-wg@ripe.net Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update.
Brett,
On Fri, 25 Nov 2005 14:41:34 +0100, "Brett Carr" <brettcarr@ripe.net> said:
-----Original Message----- From: Alexander Gall [mailto:gall@switch.ch] Sent: 25 November 2005 11:48 To: Brett Carr Cc: dns-wg@ripe.net Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update.
[...]
However, I think there is a problem with ns.ripe.net. It doesn't return DNSSEC RRsets when the DO flag is set in the query:
[...]
I found a small config typo, which I have fixed, it should be ok now though.
Thanks, it looks good now.
Did you have a chance to look (or have somebody else have a look :-) at <https://www.ripe.net/cgi-bin/delcheck/delcheck2.cgi> for the zone 176.195.in-addr.arpa? I can see two problems:
- For some reason, the tool doesn't get replies to queries for NS and DNSKEY records at our name servers {merapi,scsnms}.switch.ch with the DO flag set. The tool then (erroneously) concludes that these RRsets are inconsistent among the servers for the zone.
I see the queries coming in on our servers from 193.0.0.214. Could it be that the replies are filtered somwhere in your network (having strange flags and all that)?
We have now fixed this after finding some strange (udp fragment) filtering behaviour on our Juniper router, We will be carrying out more (lab based) tests on this and will report the results to Juniper. Regards Brett -- Brett Carr RIPE Network Coordination Centre Systems Engineer -- Operations Group Amsterdam, Netherlands GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8
On Tue, 29 Nov 2005 16:38:58 +0100, "Brett Carr" <brettcarr@ripe.net> said:
Did you have a chance to look (or have somebody else have a look :-) at <https://www.ripe.net/cgi-bin/delcheck/delcheck2.cgi> for the zone 176.195.in-addr.arpa? I can see two problems:
- For some reason, the tool doesn't get replies to queries for NS and DNSKEY records at our name servers {merapi,scsnms}.switch.ch with the DO flag set. The tool then (erroneously) concludes that these RRsets are inconsistent among the servers for the zone.
I see the queries coming in on our servers from 193.0.0.214. Could it be that the replies are filtered somwhere in your network (having strange flags and all that)?
We have now fixed this after finding some strange (udp fragment) filtering behaviour on our Juniper router, We will be carrying out more (lab based) tests on this and will report the results to Juniper.
Thanks! -- Alex
Brett, What's going on with 195.in-addr.arpa? All DNSSEC records are gone, e.g. ; <<>> DiG 9.4.0a2 <<>> @193.0.0.195 195.in-addr.arpa. dnskey ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1037 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recusion requested but not available ;; QUESTION SECTION: ;195.in-addr.arpa. IN DNSKEY ;; AUTHORITY SECTION: 195.in-addr.arpa. 7200 IN SOA ns-pri.ripe.net. ops.ripe.net. 2005112722 43200 7200 1209600 7200 ;; Query time: 49 msec ;; SERVER: 193.0.0.195#53(193.0.0.195) ;; WHEN: Mon Nov 28 08:41:30 2005 ;; MSG SIZE rcvd: 89 The same happened to {193,194,212}.in-addr.arpa, but the other inverse zones are fine. -- Alex On Thu, 24 Nov 2005 14:13:29 +0100, "Brett Carr" <brettcarr@ripe.net> said:
Dear Colleagues, As part of the project to deploy DNSSEC in the RIPE NCC service region, the RIPE NCC has further expanded the signing of zones from the reverse tree.
The following zones are now signed:
ripe.net ripencc.com ripencc.net ripencc.org ripe-ncc.com ripe-ncc.net ripe-ncc.org 89.in-addr.arpa 90.in-addr.arpa 213.in-addr.arpa 213.in-addr.arpa. 193.in-addr.arpa. 195.in-addr.arpa. 212.in-addr.arpa. 194.in-addr.arpa. 145.in-addr.arpa.
If you want to configure your resolvers to verify these zones using DNSSEC, *key signing keys* for these zones are available at: https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys.txt
For information about how to use the keys, and for further details about DNSSEC deployment at the RIPE NCC, please see: http://www.ripe.net/projects/disi/keys/
The following zones will now accept secure delegations (DS Records) via the addition of a "ds-rdata:" record in the whois domain object for the zone:
89.in-addr.arpa. 90.in-addr.arpa. 213.in-addr.arpa. 193.in-addr.arpa. 195.in-addr.arpa.
Regards
Brett Carr RIPE NCC
-----Original Message----- From: Alexander Gall [mailto:gall@switch.ch] Sent: 28 November 2005 08:47 To: Brett Carr Cc: dns-wg@ripe.net Subject: Re: [dns-wg] RIPE NCC DNSSEC on the reverse tree update.
Brett,
What's going on with 195.in-addr.arpa? All DNSSEC records are gone, e.g.
We saw some zone file corruption during the early hours of the morning, this caused a failsafe operation to takeover and hence the zones were published without signatures. I've investigated and fixed the corruption and so now everything is back to normal. Regards Brett -- Brett Carr RIPE Network Coordination Centre Systems Engineer -- Operations Group Amsterdam, Netherlands GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8
On Mon, 28 Nov 2005 11:24:45 +0100, "Brett Carr" <brettcarr@ripe.net> said:
-----Original Message----- From: Alexander Gall [mailto:gall@switch.ch] Sent: 28 November 2005 08:47 To: Brett Carr Cc: dns-wg@ripe.net Subject: Re: [dns-wg] RIPE NCC DNSSEC on the reverse tree update.
Brett,
What's going on with 195.in-addr.arpa? All DNSSEC records are gone, e.g.
We saw some zone file corruption during the early hours of the morning, this caused a failsafe operation to takeover and hence the zones were published without signatures. I've investigated and fixed the corruption and so now everything is back to normal.
Thanks. Having such a failsafe procedure is probably a good idea. However, it caused my sub-zone to be marked as bogus, which is bad (i.e. my cache with only the key for 195.in-addr.arpa configured as trusted key returned SERVFAIL for all queries within 176.195.in-addr.arpa). I think that you must not leave the DS records in the zone when all other DNSSEC RRsets are removed (and the DS record for my zone was definitely there). Otherwise, a verifier will find a DS record but is unable to check its authenticity and has to declare the zone as bogus. -- Alex
We saw some zone file corruption during the early hours of the morning, this caused a failsafe operation to takeover and hence the zones were published without signatures.
considering the obvious attack paths this opens, one assumes that this 'failsafe' would not be part of the operation of a secure zone in normal, as opposed to trial, operation. randy
participants (3)
-
Alexander Gall -
Brett Carr -
Randy Bush