[dns-operations] Question to DNSSEC and DLV policy

David Conrad drc at virtualized.org
Fri Mar 20 00:08:36 UTC 2009


Hi,

On Mar 19, 2009, at 4:13 AM, Mark Andrews wrote:
>> So DLV, ITAR and NCC are all the same, just from different sources?

No.

> 	DLV and ITAR are third party collections of trust anchors.
> 	NCC is a first party collection of trust anchors.

I don't know what is meant by third party vs. first party here.

ITAR is a mechanism used by IANA to take trust anchors provided by the  
authorized contacts of the TLDs and publish them in a reasonably  
secure manner.  Since IANA only interacts with TLD administrators (in  
this context), the only contents of IANA's ITAR are TLD trust  
anchors.  Caching name server operators are expected to obtain, verify  
(via PGP), and install the trust anchors from the IANA ITAR in their  
name server configuration themselves (presumably automatically via a  
script, but you can also do it manually if you like to run the risk of  
forgetting and having stale information).

I don't know the mechanisms RIPE-NCC's uses to create its trust anchor  
repository so I won't comment on it.

ISC's DLV is actually two things:

- a non-standard protocol modification (see RFC 4431 for something  
like ISC's DLV, but not actually ISC's DLV.  I guess ISC's DLV is  
documented in http://ftp.isc.org/isc/pubs/tn/isc-tn-2006-1.txt, but  
folks from ISC would be more authoritative (pun intended)).  DLV is  
implemented in very recent version of BIND and (I gather) Unbound.
- a repository of trust anchors either provided by administrators of  
the zone (however that is established) or obtained from places like  
IANA's ITAR.

One other major point of difference is that since the trust anchors  
are configured directly in the caching name server, the use of IANA's  
ITAR and RIPE-NCC's TAR do not require queries to ISC's infrastructure  
during validation.  The implication of this is that ISC's DLV is more  
dynamic but also requires caching name server operators to accept  
(some) additional latency and the need to trust additional external  
infrastructure.

Regards,
-drc




More information about the dns-operations mailing list