DNSSEC Provisioning for ERX Space Held with ARIN
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, ARIN has just announced that they are now supporting DNSSEC-enabled delegations for their reverse space. For more information, see: https://www.arin.net/announcements/2011/20110321.html This means that RIPE NCC members with ERX space assignments in the ARIN region can now also make use of DNSSEC. To do so, please submit a domain object which includes the ds-rdata field as you would for any other DNSSEC-enabled delegation. For more information on how to do this, see: http://www.ripe.net/data-tools/dns/dnssec/procedure-for-requesting-dnssec-de... We will enable this service for ERX space held in other RIR regions as soon as DNSSEC becomes available with those RIRs. For more information on ERX space in the RIPE NCC service region, see: http://www.ripe.net/lir-services/resource-management/erx Regards, Wolfgang Nagele DNS Group Manager, RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2KFYYACgkQjO7G63Byy8fLrwCfVa6M28DwHHk1xjgpyeFLWdKq +1wAnAk/hIkgK16fbr7iRGeWJgYHwlEM =H3jm -----END PGP SIGNATURE-----
On Mar 23 2011, Wolfgang Nagele wrote:
ARIN has just announced that they are now supporting DNSSEC-enabled delegations for their reverse space.
For more information, see: https://www.arin.net/announcements/2011/20110321.html
This means that RIPE NCC members with ERX space assignments in the ARIN region can now also make use of DNSSEC.
This is excellent news. Thanks to all at RIPE NCC for their persistence with getting this on the road,
To do so, please submit a domain object which includes the ds-rdata field as you would for any other DNSSEC-enabled delegation.
For more information on how to do this, see: http://www.ripe.net/data-tools/dns/dnssec/procedure-for-requesting-dnssec-de...
I was a bit surprised by this section: | These tests will only be done for "ds-rdata:" attributes using | supported digest types [1 section 5.1.3]. Currently we support | digest type 1(SHA1). | | If the "ds-rdata:" attribute uses an unsupported digest type, you | will see a warning message, however the "ds-rdata:" content will | still be copied into the parent zone. Is there some technical reason that you can't check digest type 2 (SHA-256) records? It wouldn't seem to be exactly bleeding edge technology! -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.
Hi,
This is excellent news. Thanks to all at RIPE NCC for their persistence with getting this on the road, We would also like to acknowledge the support of ARIN, without which this could not have been done.
Is there some technical reason that you can't check digest type 2 (SHA-256) records? It wouldn't seem to be exactly bleeding edge technology! Our DelChecker is up for renewal and this will include support for things as SHA-256. It is a bit too early for me to give a release date just yet. Please bear with us.
Until then you can still publish SHA-256 trust anchors. It just means that we will not verify them before publication. A note on the bleeding edge part. While I agree that the technology is not that new, it is unfortunately still the case that on most systems crypto libraries do _not_ support it. OpenSSL on most vanilla Linux distributions is just one example. Regards, Wolfgang
participants (2)
-
Chris Thompson -
Wolfgang Nagele