[GH-ISSUE #3041] Validation of RRsets in the Additional section #1116

New issue

Closed

opened 2026-03-16 01:39:08 +03:00 by kerem · 1 comment

kerem commented

2026-03-16 01:39:08 +03:00

Owner

Originally created by @divergentdave on GitHub (Jun 9, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3041

Currently, the recursive and forwarder authorities never include any records in the Additional section. If we are to change this, we'll have to consider how DNSSEC validation will interact with this. I haven't found any special guidance for how to treat different sections when validating messages, but section 3.1.1, about authoritative name servers, says that if a signed RRset is included in the Additional section, the corresponding RRSIG RRs MUST be included as well, unless there is not enough space. If the RRSIGs are excluded for space reasons, then the TC bit MUST NOT be set solely because of the exclusion of those RRSIG RRs. Because of this, I think we'll have to treat sections differently in validating resolvers or forwarders.

Under the status quo, if we saw an RRset with no signatures in the Additional section, we'd start querying for DS records to determine if they are in a signed zone or not. If we found that the zone is signed, then we'd return SERVFAIL for the original recursive query. This seems wrong, as the authoritative name server is operating according to the spec, and there's no way to recover from this error. Some other options:

We could strip bogus RRsets from the Additional section, and send a success response. I don't have an RFC cite to support this, but Additional section records are treated on a best-effort basis in many other situations.
We could skip validation of Additional section records entirely. I'm not sure if this would be spec-compliant.
We could attempt to re-query the RRset in question, in order to get the records and signatures directly from their authoritative server. This seems like an unusual approach.

Originally created by @divergentdave on GitHub (Jun 9, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3041 Currently, the recursive and forwarder authorities never include any records in the Additional section. If we are to change this, we'll have to consider how DNSSEC validation will interact with this. I haven't found any special guidance for how to treat different sections when validating messages, but section 3.1.1, about authoritative name servers, says that if a signed RRset is included in the Additional section, the corresponding RRSIG RRs MUST be included as well, unless there is not enough space. If the RRSIGs are excluded for space reasons, then the TC bit MUST NOT be set solely because of the exclusion of those RRSIG RRs. Because of this, I think we'll have to treat sections differently in validating resolvers or forwarders. Under the status quo, if we saw an RRset with no signatures in the Additional section, we'd start querying for DS records to determine if they are in a signed zone or not. If we found that the zone is signed, then we'd return SERVFAIL for the original recursive query. This seems wrong, as the authoritative name server is operating according to the spec, and there's no way to recover from this error. Some other options: * We could strip bogus RRsets from the Additional section, and send a success response. I don't have an RFC cite to support this, but Additional section records are treated on a best-effort basis in many other situations. * We could skip validation of Additional section records entirely. I'm not sure if this would be spec-compliant. * We could attempt to re-query the RRset in question, in order to get the records and signatures directly from their authoritative server. This seems like an unusual approach.

kerem closed this issue

2026-03-16 01:39:13 +03:00

kerem commented

2026-03-16 01:39:19 +03:00

Author

Owner

@divergentdave commented on GitHub (Jul 3, 2025):

RFC 4033 section 7 and RFC 4035 section 3.2.3 say that the AD bit only indicates that the RRsets in the Answer and Authority were validated. Thus, the second option above is correct. Currently, build_forwarded_response() always leaves the Additional section empty; once we start filling this in, we'll need to rewrite this whole function, but still only set AD based on these first two sections.

@divergentdave commented on GitHub (Jul 3, 2025): [RFC 4033 section 7](https://datatracker.ietf.org/doc/html/rfc4033#section-7) and [RFC 4035 section 3.2.3](https://datatracker.ietf.org/doc/html/rfc4035#section-3.2.3) say that the AD bit only indicates that the RRsets in the Answer and Authority were validated. Thus, the second option above is correct. Currently, `build_forwarded_response()` always leaves the Additional section empty; once we start filling this in, we'll need to rewrite this whole function, but still only set AD based on these first two sections.

kerem referenced this issue

2026-03-16 04:20:12 +03:00

[PR #1116] [MERGED] ignore net2 advisory for now #1985