[GH-ISSUE #1650] RFC-3655: Authenticated Data (AD) bit #727

New issue

Closed

opened 2026-03-16 00:00:15 +03:00 by kerem · 4 comments

kerem commented

2026-03-16 00:00:15 +03:00

Owner

Originally created by @moparisthebest on GitHub (Feb 28, 2022).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1650

Is your feature request related to a problem? Please describe.
When I'm looking up SRV records for instance, I need to know if the response is DNSSEC signed, because if so I can accept a certificate with the name of the target, and if not, I can't.

Also TLSA records can currently be looked up, but not used, because I have no idea if the zone was signed with DNSSEC or not.

Describe the solution you'd like
The returned Lookup object should either have the entire message Header available on it, or should have authentic_data: bool copied from it.

Describe alternatives you've considered
I can instead have 2 resolvers, the first validating DNSSEC, and fallback to the second if no RRSIGs are present, but this is less than ideal, and may be vulnerable to RRSIG stripping. Also trust-dns doesn't support validating NSEC3 which an upstream resolver could do for me.

Additional context
If you give me guidance on what you'd like the solution to look like, maybe one of my proposals, maybe not, I'd submit a PR implementing the change.

Originally created by @moparisthebest on GitHub (Feb 28, 2022). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1650 **Is your feature request related to a problem? Please describe.** When I'm looking up SRV records for instance, I need to know if the response is DNSSEC signed, because if so I can accept a certificate with the name of the target, and if not, I can't. Also TLSA records can currently be looked up, but not used, because I have no idea if the zone was signed with DNSSEC or not. **Describe the solution you'd like** The returned `Lookup` object should either have the entire message `Header` available on it, or should have `authentic_data: bool` copied from it. **Describe alternatives you've considered** I can instead have 2 resolvers, the first validating DNSSEC, and fallback to the second if no RRSIGs are present, but this is less than ideal, and may be vulnerable to RRSIG stripping. Also trust-dns doesn't support validating NSEC3 which an upstream resolver could do for me. **Additional context** If you give me guidance on what you'd like the solution to look like, maybe one of my proposals, maybe not, I'd submit a PR implementing the change.

kerem

2026-03-16 00:00:15 +03:00

closed this issue
added the
enhance

ops

compliance
labels

kerem commented

2026-03-16 00:00:31 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 1, 2022):

This seems reasonable. One issue I see is if there are any additional requests made (to follow a CNAME chain for example). So we'll need a way to handle that scenario. An excessive option for that would be to copy the header onto each record in the Lookup, or use an Arc<Header> to reduce the overhead, on each Record individually.

Are there any other methods you can think of to achieve what you're looking for? I have been thinking even in the DNSSEC option that we probably need a bit more information associated to the lookups for the reasons you've specified.

@bluejekyll commented on GitHub (Mar 1, 2022): This seems reasonable. One issue I see is if there are any additional requests made (to follow a CNAME chain for example). So we'll need a way to handle that scenario. An excessive option for that would be to copy the header onto each record in the `Lookup`, or use an `Arc<Header>` to reduce the overhead, on each `Record` individually. Are there any other methods you can think of to achieve what you're looking for? I have been thinking even in the DNSSEC option that we probably need a bit more information associated to the lookups for the reasons you've specified.

kerem commented

2026-03-16 00:00:36 +03:00

Author

Owner

@djc commented on GitHub (Sep 1, 2023):

Presumably if we just keep the authenticated_data bit life becomes a lot simpler, because we can fold the authenticated_data in the sense that any CNAME chain element that is not authenticated_data then sets the bit to false, right? That seems like a reasonable route (that avoids stringing all the headers along).

@djc commented on GitHub (Sep 1, 2023): Presumably if we just keep the `authenticated_data` bit life becomes a lot simpler, because we can fold the `authenticated_data` in the sense that any CNAME chain element that is not `authenticated_data` then sets the bit to `false`, right? That seems like a reasonable route (that avoids stringing all the headers along).

kerem commented

2026-03-16 00:00:41 +03:00

Author

Owner

@wez commented on GitHub (Sep 1, 2023):

I tried to add authentic_data: bool into Lookup and then find where we connect a response to creating a lookup.

I started in recursor.rs by threading the flag down into insert_records, but stopped because a lot of the code seems to be built on passing around a tuple of records and expiry and it's not always clear how to connect that AD bit and thread it through to the right places.

I found it hard to navigate the code to find this spot, because I am totally unfamiliar with this code, and I'm unsure of how you all would like this sort of change to be made, so I'm looking for guidance before trying to dive back in.

@wez commented on GitHub (Sep 1, 2023): I tried to add `authentic_data: bool` into Lookup and then find where we connect a response to creating a lookup. I started in recursor.rs by threading the flag down into `insert_records`, but stopped because a lot of the code seems to be built on passing around a tuple of records and expiry and it's not always clear how to connect that AD bit and thread it through to the right places. I found it hard to navigate the code to find this spot, because I am totally unfamiliar with this code, and I'm unsure of how you all would like this sort of change to be made, so I'm looking for guidance before trying to dive back in.

kerem commented

2026-03-16 00:00:47 +03:00

Author

Owner

@bluejekyll commented on GitHub (Sep 3, 2023):

Agreed. Threading through options like this have been hard to make simple.

@bluejekyll commented on GitHub (Sep 3, 2023): Agreed. Threading through options like this have been hard to make simple.