November 2005 - dns-wg - mailman.ripe.net

unsubscribe jkuijer@dds.nl
by jkuijer＠dds.nl 30 Nov '05

30 Nov '05

Citeren dns-wg-request(a)ripe.net: > Send dns-wg mailing list submissions to > dns-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/dns-wg > or, via email, send a message with subject or body 'help' to > dns-wg-request(a)ripe.net > > You can reach the person managing the list at > dns-wg-admin(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dns-wg digest..." > > > Today's Topics: > > 1. unsubscribe jkuijer(a)dds.nl (jkuijer(a)dds.nl) > 2. RE: RIPE NCC DNSSEC on the reverse tree update. (Brett Carr) > 3. RE: RIPE NCC DNSSEC on the reverse tree update. (Alexander Gall) > > --__--__-- > > Message: 1 > Date: Tue, 29 Nov 2005 12:24:05 +0100 > From: jkuijer(a)dds.nl > To: dns-wg(a)ripe.net > Subject: [dns-wg] unsubscribe jkuijer(a)dds.nl > > Citeren dns-wg-request(a)ripe.net: > > > Send dns-wg mailing list submissions to > > dns-wg(a)ripe.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://www.ripe.net/mailman/listinfo/dns-wg > > or, via email, send a message with subject or body 'help' to > > dns-wg-request(a)ripe.net > > > > You can reach the person managing the list at > > dns-wg-admin(a)ripe.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of dns-wg digest..." > > > > > > Today's Topics: > > > > 1. RE: RIPE NCC DNSSEC on the reverse tree update. (Alexander Gall) > > 2. RE: RIPE NCC DNSSEC on the reverse tree update. (Randy Bush) > > > > -- __--__-- > > > > Message: 1 > > From: Alexander Gall <gall(a)switch.ch> > > Date: Mon, 28 Nov 2005 12:02:49 +0100 > > To: "Brett Carr" <brettcarr(a)ripe.net> > > Cc: <dns-wg(a)ripe.net> > > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > > > On Mon, 28 Nov 2005 11:24:45 +0100, "Brett Carr" <brettcarr(a)ripe.net> said: > > > > >> -----Original Message----- > > >> From: Alexander Gall [mailto:gall@switch.ch] > > >> Sent: 28 November 2005 08:47 > > >> To: Brett Carr > > >> Cc: dns-wg(a)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 > > > > > > > > -- __--__-- > > > > Message: 2 > > From: Randy Bush <randy(a)psg.com> > > Date: Mon, 28 Nov 2005 06:01:50 -1000 > > To: "Brett Carr" <brettcarr(a)ripe.net> > > Cc: dns-wg(a)ripe.net > > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > > > > 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 > > > > > > > > > > End of dns-wg Digest > > > > > > > --__--__-- > > Message: 2 > From: "Brett Carr" <brettcarr(a)ripe.net> > To: "'Alexander Gall'" <gall(a)switch.ch> > Cc: <dns-wg(a)ripe.net> > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > Date: Tue, 29 Nov 2005 16:38:58 +0100 > > > > > -----Original Message----- > > From: Alexander Gall [mailto:gall@switch.ch] > > Sent: 25 November 2005 15:22 > > To: Brett Carr > > Cc: dns-wg(a)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(a)ripe.net> said: > > > > >> -----Original Message----- > > >> From: Alexander Gall [mailto:gall@switch.ch] > > >> Sent: 25 November 2005 11:48 > > >> To: Brett Carr > > >> Cc: dns-wg(a)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 > > > > > --__--__-- > > Message: 3 > From: Alexander Gall <gall(a)switch.ch> > Date: Wed, 30 Nov 2005 08:59:37 +0100 > To: "Brett Carr" <brettcarr(a)ripe.net> > Cc: <dns-wg(a)ripe.net> > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > On Tue, 29 Nov 2005 16:38:58 +0100, "Brett Carr" <brettcarr(a)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 > > > > > End of dns-wg Digest >

1 0

RIPE NCC DNSSEC on the reverse tree update.
by Brett Carr 30 Nov '05

30 Nov '05

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

3 13

unsubscribe jkuijer@dds.nl
by jkuijer＠dds.nl 29 Nov '05

29 Nov '05

Citeren dns-wg-request(a)ripe.net: > Send dns-wg mailing list submissions to > dns-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/dns-wg > or, via email, send a message with subject or body 'help' to > dns-wg-request(a)ripe.net > > You can reach the person managing the list at > dns-wg-admin(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dns-wg digest..." > > > Today's Topics: > > 1. RE: RIPE NCC DNSSEC on the reverse tree update. (Alexander Gall) > 2. RE: RIPE NCC DNSSEC on the reverse tree update. (Randy Bush) > > --__--__-- > > Message: 1 > From: Alexander Gall <gall(a)switch.ch> > Date: Mon, 28 Nov 2005 12:02:49 +0100 > To: "Brett Carr" <brettcarr(a)ripe.net> > Cc: <dns-wg(a)ripe.net> > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > On Mon, 28 Nov 2005 11:24:45 +0100, "Brett Carr" <brettcarr(a)ripe.net> said: > > >> -----Original Message----- > >> From: Alexander Gall [mailto:gall@switch.ch] > >> Sent: 28 November 2005 08:47 > >> To: Brett Carr > >> Cc: dns-wg(a)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 > > > > --__--__-- > > Message: 2 > From: Randy Bush <randy(a)psg.com> > Date: Mon, 28 Nov 2005 06:01:50 -1000 > To: "Brett Carr" <brettcarr(a)ripe.net> > Cc: dns-wg(a)ripe.net > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > > 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 > > > > > End of dns-wg Digest >

1 0

Announcing a covering prefix for the K-root server
by Andrei Robachevsky 07 Nov '05

07 Nov '05

Dear Colleagues, As you probably know, the RIPE NCC have been deploying two types of anycast mirror instances of K-root server: global nodes and so-called local nodes, intended to serve only a local ISP community. To limit propagation of the K-root prefix for the local nodes we are using a NO_EXPORT community. Unfortunately this may lead to a situation when some of multihomed networks don't see K-root prefix at all, even for a global node. For more detailed description see http://www.merit.edu/mail.archives/nanog/msg13358.html. Thank you, Randy, for spotting this. This is not specific to anycast and has never appeared to be particularly widespread. To remedy this problem we plan to start announcing a covering prefix 193.0.14.0/23 from AS25152 from our global node to our peers at AMS-IX without the NO_EXPORT community. We will announce the covering prefix at 10:00 UTC on Thursday, 10th November 2005. In parallel we will be monitoring and measuring changes in traffic distribution for further analysis. We will then proceed with other global nodes. Regards, Andrei Robachevsky RIPE NCC

2 1

RIPE NCC Start Signing selected in-addr.arpa. zones
by Brett Carr 03 Nov '05

03 Nov '05

Dear Colleagues, As part of the project to deploy DNSSEC in the RIPE NCC Service region, the RIPE NCC has started signing three 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 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/ We will shortly start accepting secure delegations. There will be more information about this soon. Regards Brett Carr RIPE NCC

1 0

Planned network maintenance 3-11-2005
by Ruud de Kooter 02 Nov '05

02 Nov '05

Dear Colleagues, This is to let you know that we will carry out planned network maintenance tomorrow, Thursday, 3 November from 20:00 to 22:00 UTC. We don't expect this to disrupt any RIPE NCC services, though you may notice some small delays. This maintenance is necessary after a high load on one of our border routers caused some service disruption on 29 September 2005. Since then, we have made configuration changes to improve load balancing between the border routers. Unfortunately this has not been as beneficial as we had hoped, and the load continues to increase. The router is approaching its maximum capacity. We have decided to replace the router with a more powerful one. We apologise for inconvenience this may cause. If you have any questions, please send e-mail to <ops(a)ripe.net>. Regards, Ruud de Kooter

1 0