[Apologies for duplicate mails]
Dear colleagues,
It was agreed at RIPE 59 in Lisbon that reverse DNS zones in the RIPE
Database should not have child objects. Documentation relating to this
decision and the discussion surrounding it can be found in the minutes
of the RIPE 59 DNS and Database Working Groups:
http://www.ripe.net/ripe/wg/dns/r59-minutes.htmlhttp://www.ripe.net/ripe/wg/db/minutes/ripe-59.html
The RIPE NCC is now ready to deploy this change and clean-up the
existing data. This will be done in the week commencing 13 December
2010. After deployment it will not be possible to create a reverse DNS
DOMAIN object in the RIPE Database if either a more or less specific
object already exists.
During the data clean-up you may receive a notification that your DOMAIN
object has been deleted. If this is the case there will be a less
specific DOMAIN object in the database. Your object was only for
documentation purposes and did not have any effect on reverse DNS.
If you have any questions please contact us at <ripe-dbm(a)ripe.net>.
Regards,
Denis Walker
Business Analyst
RIPE NCC Database Group
-------- Original Message --------
Subject: FYI: ARPA DS record in the root
Date: Tue, 7 Dec 2010 09:26:57 +0100
From: IAB Chair <iab-chair(a)iab.org>
To: IETF Announcement list <ietf-announce(a)ietf.org>
Dear Colleagues,
The ARPA DS RRset has been published in the root zone as of serial
number 2010120601.
This allows signed reverse address RRsets to be validated by DNSSEC
aware recursive name servers that have the root configured as their
trust-anchor.
--Olaf Kolkman
IAB Chair
-----------------------------------
The Internet Architecture Board
www.iab.org
iab-chair(a)iab.org
_______________________________________________
IETF-Announce mailing list
IETF-Announce(a)ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
I don't know whether this is the most appropriate forum to raise
this issue --- but if RIRs can be persuaded to support the alternate
form of reverse zone delegation suggested here, perhaps other
authorities would do the same.
Fragmentation of IPv4 space leads to organisations having lots of
little reverse zones, each of which requires: managing the contents,
maintaining the registration, organising official slaves, DNSSEC
signing ... There is much uneconomic effort involved.
Locally we have been using a scheme to map such reverse lookups into
a single common zone, described at
http://people.pwf.cam.ac.uk/cet1/prune-reverse-zones
To take full advantage of this, however, requires promoting DNAMEs
into the parent reverse zone.
Logically, administrators of such zones ought to be delighted to
replace delegations (multiple NS records, maybe DS records as well)
with a single DNAME. But of course it has not been standard practice
to support that.
As DNAMEs do not redirect the name itself, there would be a problem
for reverse zones containing significant records at the apex, e.g.
PTR records pointing to a gateway host. (I think that practice,
recommended in RFC 1033, has pretty much fallen into disuse.) If the
IETF DNSEXT WG ever get their act together on "XNAME"/"CNAME+DNAME",
that would cover that particular point, but meanwhile no-one would
be obliged to use DNAMEs if they didn't want to.
Anyway, I would welcome opinions on this idea.
--
Chris Thompson University of Cambridge Computing Service,
Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom.
