From 09eaf68ce4e19a653ff25312e75c6e226b127fd6 Mon Sep 17 00:00:00 2001 From: Tom Gundersen Date: Wed, 25 Nov 2015 22:22:38 +0100 Subject: [PATCH] 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. --- src/resolve/resolved-dns-packet.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/src/resolve/resolved-dns-packet.c b/src/resolve/resolved-dns-packet.c index 472486777c1..4b6b6afae8b 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; -- 2.39.2