(Apologies in advance for cross-postings)
We've created a new mailing list (based on a proposal approved by
OARC members), that is nanog-like yet professional, and bugtraq-like,
to deal specifically with DNS security issues such as:
Attacks
Security vulnerabilities
Secure configuration
The list concerns all these from the sense of operational problems
rather than system
administrators tech support.
DNS is arguably as important as routing protocols, and yet we rarely
hear details of the attacks going on. The folks dealing with attacks
may be network admins, system admins, or security folks; they deal
with the problems themselves and move on.
Establishing an open yet professional group can be essential to:
1. Form a community of operators.
2. Locate serious people.
3. Find out about problems.
4. Share information.
5. Alert of issues.
6. Move on to more secure environments and meat-space operations.
If interested in subscribing to this open list, the links below will
get you there.
http://lists.oarci.net/mailman/listinfo/
-b
Qmail can't deliver to DNSSEC protected domains. (Repost from edri.org-ML)
Reason:
- qmail send an "ANY IN edri.org" query in order to deliver mail.
* Due to DNSSEC, there are a some signatures catched by ANY so the
response packet size is 605 bytes.
- qmail does not support EDNS extensions for larger UDP packets.
* The response is truncated to 512 bytes and marked "truncated".
- qmail does not support the very old TCP fallback requirement for DNS.
- qmail refuses to deliver the mail
and logs "CNAME_lookup_failed_temporarily."
Overview of packet sizes
question | answer size
-----------------------|--------------
ANY edri.org | 605 byte
MX edri.org | 237 byte
A edri.org | 213 byte
-----------------------|--------------
ANY edri.org +dnssec | 1331 byte
MX edri.org +dnssec | 923 byte
A edri.org +dnssec | 731 byte
-----BEGIN PGP SIGNED MESSAGE-----
In order to extend the deployment of security technology, we switch to
DNSSEC for us and our customers. Usually the collection of SEP keys on
each resolver host is hard to maintain. This is the reason why, we set
up an other DLV zone. The zone is automatically rechecked for new keys
and subentries on each zone. Please allow AXFR (auth by DNSSEC key) to
provide all necessary data. The bind lookaside mechanism is limited to
small steps, so a many DLV entries as possible are needed. I copy also
the data from dlv.verisignlabs.com, so you may even trust them. ;-)
Necessary configuration in /etc/named.conf:
options {
...;
dnssec-enable yes;
dnssec-lookaside "." trust-anchor "dnssec.iks-jena.de";
};
trusted-keys {
"iks-jena.de." 257 3 5 "AQPRteOmx973cbeIMigT7nciz3dcbt8ssZPG
OK2vtPQlEaZO2fKgnm1Fo6FPWcGqKv6O1Zpj
Ew2upKVDnzwMCRHpGe0Qh2TawStviww/jxUt
joZom9Hy6uIkTvo7TxqnWg55LoHlcsl1kxsF
1PsM2Z88F1XhXSrUtkiQnViXbfzR0joDE8xG
J9zRNuzr9Jik+bcv4S4KFOE/Ocn4F5vF7+eo
jz9m3/u0gvQdvgFsb7OHr9cYA5GeG++cJWGG
6xFF+yWEDdWuu2A7IJM3EQFWLr0kGDS6oWo/
5Bz4PlrURjU5wahM1iwLnbKXhQQempzPYnSE
s1CW+KH73WjMa76Dna9B";
};
It's recommended to set up a secondary for "dnssec.iks-jena.de".
We send out notifies, too.
I did not manage to install a web form right now. If you like to
get listed, please send me an email.
I'm looking for a *stable* ipv6 and dnssec able secondary server
for our zones. If you like to exchange secondary DNS service in
different AS, please contact me via OpenPGP mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iQCiAwUBQ+JD3pFeTizbCJMJAQH3+QRmNxR+RIQYqlrEv2IbFBsAheZINPbSbUnw
GkBCUvnTJIHmE9s2em0hxkUR+QQOpaih4szklG2B96aZ04eds5CH9ujovdfTMp0P
rb1ri6SIdvHPez50Yp9EbG51Dsdde/8eQgU3P7HHU8ZXUY9x8d0EkMu9fHrsLgkv
66NNL6ezk9S25aoTknE51FlxknX1
=PyvH
-----END PGP SIGNATURE-----
Dear Colleagues,
The RIPE NCC Training Services Department invites you to register for
one of our upcoming DNS for LIRs Training Courses:
Date: Monday 10 April 2006
Time: 09:00 17:00
Location: London, United Kingdom
And
Date: Thursday 11 May 2006
Time: 09:00 17:00
Location: Amsterdam, Netherlands
And
Date: Tuesday 13 June 2006
Time: 09:00 17:00
Location: Riyadh, Saudi Arabia
Hosted by:ZAJIL International Telecommunications Co. W.L.L.
And
Date: Thursday 22 June 2006
Time: 09:00 17:00
Location: Munich, Germany
The main objective of the DNS for LIRs Training Course is to provide
LIRs with information about the different DNS related services the
RIPE NCC has available for them. It covers reverse DNS procedures and
checks, as well as giving information about DNS Monitoring (DNSMON),
K-Root and anycasting.
The course also covers DNSSEC and the specific procedures set up by
the RIPE NCC to secure the in-addr.arpa zones.
Please note that the DNS for LIRs course focuses on DNS services and
procedures related to being an LIR. The course does: - NOT teach the
basics of DNS - NOT describe how to receive Internet resources from
the RIPE NCC - NOT describe fully how to operate a Local Internet
Registry (LIR)
The course is intended for technical staff of LIRs. It is assumed that
all attendees are familiar with common DNS terminology and have a
practical knowledge of operating DNS servers.
The course is free of charge. We provide lunch and printed training
materials.
We do not cover any of your travel expenses or accommodation. We give
all of our training courses in English.
You can find more information about the course at:
http://www.ripe.net/training/dns
REGISTRATION:
============
To register for this course, please use the LIR Portal or complete the
registration via our website on:
http://www.ripe.net/cgi-bin/trainingform.pl.cgi
If you have any questions please do not hesitate to contact us at
<training(a)ripe.net>.
Kind regards,
Rumy Kanis
Training Services Manager
RIPE NCC
__________
RIPE NCC Online Learning...at your own pace in your own space
https://e-learning.ripe.net
[Apologies for duplicates.]
Dear Colleague,
The RIPE NCC has been moving ahead with the signing of DNSSEC reverse zones.
We are pleased to announce that we have reached the stage where all IPv4
reverse zones are signed. You can find details of the zones and relevant
public keys at:
https://www.ripe.net/projects/disi/keys/
We are now also accepting signed delegations (DS Records) for all IPv4
zones. Details on how to request a secure delegation can be found at:
https://www.ripe.net/rs/reverse/dnssec/registry-procedure.html
During the month of January, we will phase in the signing of IPv6 reverse
zones. Further notification of this will be sent when the process is
complete.
Brett Carr
--
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
Dear Colleagues,
The RIPE NCC Training Services Department invites you to register for
one of our upcoming DNS for LIRs Training Courses:
Date: Friday, 27 January 2006
Time: 09:00 17:00
Location: Limassol, Cyprus
And
Date: Wednesday, 15 February 2006
Time: 09:00 17:00
Location: Manama, Bahrain
Hosted by: 2Connect: http://www.2connectbahrain.com/
The main objective of the DNS for LIRs Training Course is to provide
LIRs with information about the different DNS related services the
RIPE NCC has available for them. It covers reverse DNS procedures and
checks, as well as giving information about DNS Monitoring (DNSMON),
K-Root and anycasting.
The course also covers DNSSEC and the specific procedures set up by
the RIPE NCC to secure the in-addr.arpa zones.
Please note that the DNS for LIRs course focuses on DNS services and
procedures related to being an LIR. The course does: - NOT teach the
basics of DNS - NOT describe how to receive Internet resources from
the RIPE NCC - NOT describe fully how to operate a Local Internet
Registry (LIR)
The course is intended for technical staff of LIRs. It is assumed that
all attendees are familiar with common DNS terminology and have a
practical knowledge of operating DNS servers.
The course is free of charge. We provide lunch and printed training
materials.
We do not cover any of your travel expenses or accommodation. We give
all of our training courses in English.
You can find more information about the course at:
http://www.ripe.net/training/dns
REGISTRATION:
============
To register for this course, please use the LIR Portal or complete the
registration via our website on:
http://www.ripe.net/cgi-bin/trainingform.pl.cgi
If you have any questions please do not hesitate to contact us at
<training(a)ripe.net>.
Kind regards,
Rumy Kanis
Training Services Manager
RIPE NCC
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
>
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.netripencc.comripencc.netripencc.orgripe-ncc.comripe-ncc.netripe-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
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
>
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
