Dear Colleagues,
In January 2007, the RIPE Document ripe-400 was created to address
lameness in the reverse DNS tree. This RIPE Document can be found online at:
http://www.ripe.net/ripe/docs/ripe-400.html
We have been monitoring name servers for some time now and statistics
from the data gathered are published online each month at:
http://www.ripe.net/info/stats/dns-lameness/
In October 2008, we sent out notifications to a small number of randomly
selected server administrators. Replies to these messages indicated a
need for further refinements to our probes and the interpretation of the
results. Since then, we have made these improvements and fixed some bugs
in our code.
We now have better data and are ready to begin sending email alerts
about lame delegations to name server operators. The email messages will
point to the DNS Lameness FAQs, which explain the possible problems and
give some pointers to help solve them.
The FAQs can be found online at:
http://www.ripe.net/info/stats/dns-lameness/faq.html
We will begin sending small batches of email alerts from Thursday, 26
February 2009, using data collected over the month of February. This
process will continue until all alerts have been sent out. The alerts
will show which zone was checked and what error conditions were detected
for its name servers.
If you have any questions, please contact <dns-help(a)ripe.net>.
Regards,
Anand Buddhdev
DNS Services Manager
RIPE NCC
Dear colleagues,
Last year, this working group wrote to ICANN requesting it implement a
trust-anchor repository for top-level domains which deploy DNSSEC. After a
couple of months of quiet usage by some of you since the RIPE meeting in
Dubai, today we are announcing it publicly.
It is available at https://itar.iana.org/
We of course are very interested in feedback and evolving the service,
implementing any operational experience we gain into future procedures for
key management in the trust anchor repository and the root zone itself.
In its letter, the working group enumerated a number of requirements which I
believe we have addressed in the implementation:
1) The service should be technology neutral, supporting different flavours
of trust anchors: The trust anchor repository supports different algorithms
and digest types, and doesn't seek to unnecessarily prohibit these. We'll
try and adopt any future types and methodologies as they are standardised.
2) The service should be operating system and DNS neutral: There is nothing
we are aware of that makes the trust anchor repository dependent on a
specific implementation. As some implementations don't accept DS records as
trust anchors, we have provided a tool to convert these to DNSKEY records.
3a) The service should verify keying material comes from an authorised
source: We verify all listing requests with the same contacts we use to
verify root zone changes.
3b) The trust anchors should be correctly formatted and consistent with the
TLD zone. We compute the DS record from the DNSKEY records in the child
zone, and ensure it matches before a listing request will succeed.
4) A process is needed to revoke a trust anchor: We have a revocation
process, and we have set up a mailing list to send key revocation
notifications to. Clearly, revoked keys will be removed from the machine
readable formats immediately after they are verified.
5) It should be clear what support is available: ICANN is providing this as
a clearly marked experimental service, with a limited lifespan. Hopefully
events will overtake it and we'll have a signed root zone before we consider
it leaving the experimental state.
6) It should have a clear exit strategy: ICANN has made it clear this is an
interim service (hence the name "ITAR"), and that we will be decommissioning
it after an appropriate time once the root zone is signed.
7) The respective manager must consent to list keying material: It is a
requirement they consent before we list keys. We will not list keys without
their explicit consent, even if we know they exist through other means.
Thanks!
Kim Davies
Internet Assigned Numbers Authority
[Apologies for duplicate e-mails]
Dear colleagues,
We are pleased to announce that the trust anchors of the RIPE NCC's
signed zones are now also available in zone-file format. This file is
suitable for use with the Unbound validating resolver, for example.
The file and its PGP signature are available at:
https://www.ripe.net/projects/disi/keys/index.html
If you have any questions or comments, please send them to
<dns-help(a)ripe.net>.
Regards,
Anand Buddhdev
DNS Services Manager
RIPE NCC
Dear colleagues,
It was brought to our attention that the PGP signature of the trust
anchor file we publish for all our signed zones was failing to verify
with versions of GnuPG 1.4.8 and higher.
This was caused by a combination of the following conditions:
1. A plain text file contains white space at the ends of lines
and
2. A detached signature is generated
In this case, the signature generated by versions of GnuPG lower than
1.4.8 will not verify with GnuPG 1.4.8 and higher.
We have corrected this situation by ensuring that the trust anchor file
we publish does not have extra white space at the end of any line.
Therefore, the signature over this file will verify with any version of
GnuPG.
We have published an updated trust anchor file on the RIPE NCC website.
We also took this opportunity to introduce trust anchors for two new
reverse zones that we signed recently, which are 109.in-addr.arpa and
178.in-addr.arpa. The file and its signature are available at:
https://www.ripe.net/projects/disi/keys/index.html
Regards,
Anand Buddhdev
DNS Services Manager
RIPE NCC
