summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Gundersen <teg@jklm.no>2015-11-25 22:22:38 +0100
committerTom Gundersen <teg@jklm.no>2015-11-26 04:03:08 +0100
commit09eaf68ce4e19a653ff25312e75c6e226b127fd6 (patch)
treecd34aaafcb7893e4471bd0ccd7d6f66a2f46c5a6
parentaf143e3b692fbba2e68efd2c834711ba518f547a (diff)
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.
-rw-r--r--src/resolve/resolved-dns-packet.c9
1 files changed, 3 insertions, 6 deletions
diff --git a/src/resolve/resolved-dns-packet.c b/src/resolve/resolved-dns-packet.c
index 472486777c..4b6b6afae8 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;