Domain Name System Security Extensions (DNSSEC) secures the Domain Name System (DNS), right?
Yes, but that’s not the whole story. DNSSEC can also introduce troubles into your DNS server.
Recently, a BIND bug caused by a missing RRSIG record, which is a part of DNSSEC, was fixed by a patch from the Internet Systems Consortium (ISC). This bug affects all versions of BIND recursive servers, and can cause a denial of service (DoS.)
This potential DoS vulnerability is caused by a RUNTIME CHECK error in Resolver.c when handling the DNS query response AUTHORITY section without covering RRSIG. In this post we will examine the BIND source codes and expose the root cause of this vulnerability.
The RRSIG record (record type 46) holds a DNSSEC signature for records with the same name and type. DNS Resolvers use this cryptographic signature to verify that a zone has signed these records.
The RDATA field of RRSIG record has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type Covered | Algorithm | Labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature Expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature Inception | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Signature / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The "Type Covered" field in the RDATA field above indicates the type of the record covered by the RRSIG record. It is important to know that there may be several records with the same name as the RRSIG record, which causes a problem for DNSSEC.
If DNSSEC is enabled, an RRSIG record should cover every record in the DNS response ANSWER section and the AUTHORITY section. However, for records with the same name, BIND named fails to check the match in the AUTHORITY section between the record and the covering RRSIG, which causes a RUNTIME CHECK error in resolver.c and forces named to exit.
The following code snippet was taken from BIND version 9.10.4-P4. Comments added by me have been highlighted.
resolver.c:
//cache the record name in the ANSWER section of DNS response
5246 static inline isc_result_t
5247 cache_name(fetchctx_t *fctx, dns_name_t *name, dns_adbaddrinfo_t *addrinfo,
5248 isc_stdtime_t now)
5249 {
....
5603 if (ANSWER(rdataset) &&
5604 rdataset->type != dns_rdatatype_rrsig) {
5605 isc_result_t tresult;
5606 dns_name_t *noqname = NULL;
//extract the records from AUTHORITY section and store it in "noqname".
5607 tresult = findnoqname(fctx, name,
5608 rdataset->type, &noqname);
The malformed AUTHORITY section has the following form:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NESC3 record | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | covering RRSIG for NESC3 record | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NESC record without covering RRSIG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The BIND named links all the records with the same name in a list and manipulates them by checking the list in a loop. In the example above, three records in the AUTHORITY section have the same name and will be linked in one list. This list is used as "nsec->list" and "name->list" in the following codes.
resolver.c:
5119 findnoqname(fetchctx_t *fctx, dns_name_t *name, dns_rdatatype_t type,
5120 dns_name_t **noqnamep)
5121 {
....
5183 section = DNS_SECTION_AUTHORITY;
//check the records in AUTHORITY section one by one in a loop
5184 for (result = dns_message_firstname(fctx->rmessage, section);
5185 result == ISC_R_SUCCESS;
5186 result = dns_message_nextname(fctx->rmessage, section)) {
5187 dns_name_t *nsec = NULL;
5188 dns_message_currentname(fctx->rmessage, section, &nsec);
5189 for (nrdataset = ISC_LIST_HEAD(nsec->list);
5190 nrdataset != NULL; nrdataset = next) {
....
5212 //parse the NSEC3 record at first and return successfully, "noqname" will be set the "name" of the NSEC3 record.
5213 if (nrdataset->type == dns_rdatatype_nsec3 &&
5214 NXND(dns_nsec3_noexistnodata(type, name, nsec,
5215 nrdataset, zonename,
5216 &exists, &data,
5217 &optout, &unknown,
5218 &setclosest,
5219 &setnearest,
5220 closest, nearest,
5221 fctx_log, fctx)))
5222 {
5223 if (!exists && setnearest) {
5224 noqname = nsec;
5225