starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-26 03:35:52 +03:00

[GH-ISSUE #2415] CAA RDATA should hold invalid issuer names as-is #983

New issue

Closed

opened 2026-03-16 01:10:13 +03:00 by kerem · 4 comments

kerem commented

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

Owner

Originally created by @divergentdave on GitHub (Sep 3, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2415

Is your feature request related to a problem? Please describe.
I set up an environment with Unbound serving hickory-dns.testing. 86400 IN CAA 0 issue "%%%%%" for a zone, and with Hickory DNS acting as a recursive resolver. This record is based on an example in this figure from the CAA RFC. If I request the CAA record from the Unbound authoritative server, I get it back as-is in the answer section. If I request the same thing from the resolver, I get back an empty answer section, with a status of NOERROR, after five seconds. Hickory's logs include a line saying that it dropped a malformed response message, due to a "Label contains invalid characters" error. This is a problem because CAs are supposed to treat this invalid issue-value "the same as one specifying an empty issuer-domain-name", and refuse to issue certificates for whatever zone holds this CAA record. Returning a NOERROR message with no CAA records would result in a CA relying on this response to instead allow certificate issuance.

Describe the solution you'd like
This could be addressed by adding an enum somewhere in the internal representation of this RDATA to hold uninterpreted bytes, if they do not match the ABNF syntax. This would keep the proto layer from returning an error when parsing a response message, and allow sending the same record, with an invalid issuer name, back to the original client. This would also provide a way to address the \.\. problem identified in #2353, though that would require using stricter checks than those in Name::parse() to trigger using the invalid variant.

Describe alternatives you've considered
Alternately, the recursor (and the stub resolver) could skip parsing any RDATA types that are not relevant to recursive resolution or DNSSEC validation, and carry CAA, TXT, SVCB, HTTPS, etc. around as vectors of bytes. I think this would require a recursor-specific alternative to the hickory_proto::rr::RData enum. This would simplify the data path for a lot of the more complicated record types, and make many potential recursor/resolver correctness bugs impossible.

Consumers using the hickory_proto or hickory_client crates directly would still be affected by the above inability to parse records with certain invalid issuer names, so it may make sense to make both changes.

Originally created by @divergentdave on GitHub (Sep 3, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2415 **Is your feature request related to a problem? Please describe.** I set up an environment with Unbound serving `hickory-dns.testing. 86400 IN CAA 0 issue "%%%%%"` for a zone, and with Hickory DNS acting as a recursive resolver. This record is based on an example in [this figure](https://www.rfc-editor.org/rfc/rfc8659#section-4.2-12) from the CAA RFC. If I request the CAA record from the Unbound authoritative server, I get it back as-is in the answer section. If I request the same thing from the resolver, I get back an empty answer section, with a status of `NOERROR`, after five seconds. Hickory's logs include a line saying that it dropped a malformed response message, due to a "Label contains invalid characters" error. This is a problem because CAs are supposed to treat this invalid issue-value "the same as one specifying an empty issuer-domain-name", and refuse to issue certificates for whatever zone holds this CAA record. Returning a NOERROR message with no CAA records would result in a CA relying on this response to instead allow certificate issuance. **Describe the solution you'd like** This could be addressed by adding an enum somewhere in the internal representation of this RDATA to hold uninterpreted bytes, if they do not match the ABNF syntax. This would keep the proto layer from returning an error when parsing a response message, and allow sending the same record, with an invalid issuer name, back to the original client. This would also provide a way to address the `\.\.` problem identified in #2353, though that would require using stricter checks than those in `Name::parse()` to trigger using the invalid variant. **Describe alternatives you've considered** Alternately, the recursor (and the stub resolver) could skip parsing any RDATA types that are not relevant to recursive resolution or DNSSEC validation, and carry `CAA`, `TXT`, `SVCB`, `HTTPS`, etc. around as vectors of bytes. I think this would require a recursor-specific alternative to the `hickory_proto::rr::RData` enum. This would simplify the data path for a lot of the more complicated record types, and make many potential recursor/resolver correctness bugs impossible. Consumers using the `hickory_proto` or `hickory_client` crates directly would still be affected by the above inability to parse records with certain invalid issuer names, so it may make sense to make both changes.

kerem closed this issue

2026-03-16 01:10:18 +03:00

kerem commented

2026-03-16 01:10:23 +03:00

Author

Owner

@djc commented on GitHub (Sep 4, 2024):

This is a problem because CAs are supposed to treat this invalid issue-value "the same as one specifying an empty issuer-domain-name", and refuse to issue certificates for whatever zone holds this CAA record. Returning a NOERROR message with no CAA records would result in a CA relying on this response to instead allow certificate issuance.

So what would a response "specifying an empty issuer-domain-name" look like, and would it make more sense to synthesize that instead?

Alternately, the recursor (and the stub resolver) could skip parsing any RDATA types that are not relevant to recursive resolution or DNSSEC validation, and carry CAA, TXT, SVCB, HTTPS, etc. around as vectors of bytes. I think this would require a recursor-specific alternative to the hickory_proto::rr::RData enum. This would simplify the data path for a lot of the more complicated record types, and make many potential recursor/resolver correctness bugs impossible.

This seems interesting but also (if I understand correctly) potentially a large change? I think you're suggesting to decouple the proto-layer transferring of these record types from "higher-level" knowledge on how to parse these, right, and moving the parsing out to the outer edges of the API?

@marcus0x62, @bluejekyll any thoughts?

@djc commented on GitHub (Sep 4, 2024): > This is a problem because CAs are supposed to treat this invalid issue-value "the same as one specifying an empty issuer-domain-name", and refuse to issue certificates for whatever zone holds this CAA record. Returning a NOERROR message with no CAA records would result in a CA relying on this response to instead allow certificate issuance. So what would a response "specifying an empty issuer-domain-name" look like, and would it make more sense to synthesize that instead? > Alternately, the recursor (and the stub resolver) could skip parsing any RDATA types that are not relevant to recursive resolution or DNSSEC validation, and carry `CAA`, `TXT`, `SVCB`, `HTTPS`, etc. around as vectors of bytes. I think this would require a recursor-specific alternative to the `hickory_proto::rr::RData` enum. This would simplify the data path for a lot of the more complicated record types, and make many potential recursor/resolver correctness bugs impossible. This seems interesting but also (if I understand correctly) potentially a large change? I think you're suggesting to decouple the proto-layer transferring of these record types from "higher-level" knowledge on how to parse these, right, and moving the parsing out to the outer edges of the API? @marcus0x62, @bluejekyll any thoughts?

kerem commented

2026-03-16 01:10:29 +03:00

Author

Owner

@divergentdave commented on GitHub (Sep 4, 2024):

So what would a response "specifying an empty issuer-domain-name" look like, and would it make more sense to synthesize that instead?

The typical way is with example.com CAA 0 issue ";". I think it would generally be better to pass records through as-is, rather than try to transform them, for LangSec reasons.

This seems interesting but also (if I understand correctly) potentially a large change? I think you're suggesting to decouple the proto-layer transferring of these record types from "higher-level" knowledge on how to parse these, right, and moving the parsing out to the outer edges of the API?

Yeah, that would be a big change. Deferring parsing would be one way to do it. Alternately if hickory_client was generic over the record type or record data type, then we could swap in an enum that parses relevant record types and leaves others uninterpreted.

@divergentdave commented on GitHub (Sep 4, 2024): > So what would a response "specifying an empty issuer-domain-name" look like, and would it make more sense to synthesize that instead? The typical way is with `example.com CAA 0 issue ";"`. I think it would generally be better to pass records through as-is, rather than try to transform them, for LangSec reasons. > This seems interesting but also (if I understand correctly) potentially a large change? I think you're suggesting to decouple the proto-layer transferring of these record types from "higher-level" knowledge on how to parse these, right, and moving the parsing out to the outer edges of the API? Yeah, that would be a big change. Deferring parsing would be one way to do it. Alternately if `hickory_client` was generic over the record type or record data type, then we could swap in an enum that parses relevant record types and leaves others uninterpreted.

kerem commented

2026-03-16 01:10:34 +03:00

Author

Owner

@divergentdave commented on GitHub (Sep 4, 2024):

Actually, we already have Value::Unknown, using that with the known property tags would provide a more comprehensive fallback. This would also address cases where, say, the issuer name is valid, but issuer parameters are encoded incorrectly.

@divergentdave commented on GitHub (Sep 4, 2024): Actually, we already have `Value::Unknown`, using that with the known property tags would provide a more comprehensive fallback. This would also address cases where, say, the issuer name is valid, but issuer parameters are encoded incorrectly.

kerem commented

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

Author

Owner

@marcus0x62 commented on GitHub (Sep 4, 2024):

Yeah, I deleted my last message when I saw this record is already wrapped in an enum with an Unknown variant. Leaving the error propagation in read_issuer but wrapping the call in read_value like so:

            if let Ok(value) = read_issuer(slice) {
                Ok(Value::Issuer(value.0, value.1))
            } else {
                Ok(Value::Unknown(slice.to_vec()))
            }
        }

seems to do the trick without adding any extra complexity to the valid-issuer case.

@marcus0x62 commented on GitHub (Sep 4, 2024): Yeah, I deleted my last message when I saw this record is already wrapped in an enum with an Unknown variant. Leaving the error propagation in read_issuer but wrapping the call in read_value like so: ``` if let Ok(value) = read_issuer(slice) { Ok(Value::Issuer(value.0, value.1)) } else { Ok(Value::Unknown(slice.to_vec())) } } ``` seems to do the trick without adding any extra complexity to the valid-issuer case.

kerem referenced this issue

2026-03-16 02:28:55 +03:00

[PR #983] [MERGED] Fix trust dns 0.18.1 #1840