From: Tom Gundersen <teg@jklm.no>
Date: Wed, 25 Nov 2015 21:22:38 +0000 (+0100)
Subject: resolved: do not reject NSEC records with empty bitmaps
X-Git-Tag: v231~910^2~1
X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=09eaf68ce4e19a653ff25312e75c6e226b127fd6;p=platform%2Fupstream%2Fsystemd.git

resolved: do not reject NSEC records with empty bitmaps

The assumption that no NSEC bitmap could be empty due to the presence of the bit representing
the record itself turns out to be flawed. See (the admittedly experimental) RFC4956 for a
counter example.
---

diff --git a/src/resolve/resolved-dns-packet.c b/src/resolve/resolved-dns-packet.c
index 4724867..4b6b6af 100644
--- a/src/resolve/resolved-dns-packet.c
+++ b/src/resolve/resolved-dns-packet.c
@@ -1746,12 +1746,9 @@ int dns_packet_read_rr(DnsPacket *p, DnsResourceRecord **ret, size_t *start) {
                 if (r < 0)
                         goto fail;
 
-                /* The types bitmap must contain at least the NSEC record itself, so an empty bitmap means
-                   something went wrong */
-                if (bitmap_isclear(rr->nsec.types)) {
-                        r = -EBADMSG;
-                        goto fail;
-                }
+                /* We accept empty NSEC bitmaps. The bit indicating the presence of the NSEC record itself
+                 * is redundant and in e.g., RFC4956 this fact is used to define a use for NSEC records
+                 * without the NSEC bit set. */
 
                 break;