Delegation Checker Modifications

Introduction

Net::DNS::DelCheck is a perl module that checks on the quality of the DNS set up before making delegations.

The library is used in the whois update module but is also available on the RIPE Website and through a command line interface.

The code is found under CVS (CVSROOT=/ncc/cvsroot REPOSITORY=ops/delcheck). It was developed at the RIPE NCC by Lee Wilmot and updated by Olaf Kolkman. In the future, the Software and Engineering Department will maintain it.

The error codes are maintained in the XML/delcheck-master-template.xml file in CVS repository.

Test Behaviour

At delegation, the checker currently is called with the name of the domain and the nameservers that are authoritative for that domain.

In the future the checker will need to be called with the DS RRs that are intended to be included in the delegating zone.

The following tests are to be performend:

• When querying each nameserver for the SOA RR the DO bit needs to be set on the outgoing query.
  o Do all servers respond with the DNSSEC data (RRSIGs in the authority section as per RFCs). If not this is an indication of severe server misconfiguration couses a ERROR (PROBLEM_NOT_ALL_SERVERS_RETURN_DNSSECDATA). Note that DNSSEC data itself should not yet be analyzed and that the data returned in the RRSIG does not need to be the same.
  
  
• Query all servers for the DNSKEY RRset
  o Do all servers respond with the same DNSKEY RRset. If not, causes a ERROR. ( PROBLEM_INCONSISTENT_DNSKEY_LISTING,

similar to PROBLEM_INCONSISTENT_NS_LISTING

• Is there a DNSKEY for each DS (algorithm/keytag)
  o Security lameness. ERROR if there are DNSKEYs missing (PROBLEM_NO_MATCHING_DNSKEY_FOR_DS).

Internally tag the keys to which the DS RRs are pointing. (we will call them Tagged Keys below)

• Are there any keys with the SEP flag set in the DNSKEY RRset?
  o if yes (there are SEP keys set): Test that all Tagged Keys have the SEP bit set and issue a WARNING if this is not the case. (PROBLEM_DS_POINTING_TO_NON_SEP_DNSKEY)
  o if not: Issue an INFO message suggesting the usage of SEP keys. (PROBLEM_SEP_FLAG_NOT_USED)
  
  
• Test if the Tagged keys all sign the DNSKEY RR set
  o If one or more keys are not used to sign the keyset: ERROR to upload (PROBLEM_KEY_SIGNING_KEY_NOT_SELF_SIGNED)
  
  
• Test if the DS hashes are correct (for each known algorithm)
  o Issue an INFO if the DS contains an unknown DIGEST algorithm (PROBLEM_DS_HASH_ALGORITHM_NOT_KNOWN)
  o ERROR if the digesest and the DNSKEY do not match (PROBLEM_DS_AND_DNSKEYRR_DO_NOT_MATCH)
  
  
• Follow each possible chain of trust from DS to SOA. (There can be more, e.g. multiple DS RRs, multiple ZSKs)
• o For each algorithm for which a DS is available:
  * Issue an INFO if the Delchecker does not implement an algorithm and continue with the next.(PROBLEM_DNSSEC_ALTORITHM_NOT_IMPLEMENTED)
  * Follow all possible chains of trust for that particular algorithm
  ** Issue an INFO if a chain of trust does not validate (PROBLEM_CHAIN_OF_TRUST_DOES_NOT_VALIDATE)
  ** FAILURE if none of the chains of trust validate (PROBLEM_NO_CHAINS_OF_TRUST_VALIDATE)
  
• Tests on the signature validity intervall on the SOA RR.
  o Issue a INFO if the signature has passed 4/5th (arbitrary vallue) of its validity interval (PROBLEM_SIGNATURE_VALIDITY_NEARS_EXPIRATION)
  o Issue a WARNING if the TTL > Validity interval/2 (ref operational-practices 4.1.1) (PROBLEM_TTL_LARGE_FRACTION_OF_SIGNATURE_VALIDITY)