starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-24 18:55:55 +03:00

[GH-ISSUE #1309] Clarification regarding `Authority` #647

New issue

Open

opened 2026-03-15 23:39:59 +03:00 by kerem · 5 comments

kerem commented

2026-03-15 23:39:59 +03:00

Owner

Originally created by @jonasbb on GitHub (Dec 2, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1309

Currently, I am trying to implement an authoritative DNS server with the help of trust-dns-server. I am not sure what exactly the difference between Authority::lookup and Authority::search is. It sounds like the only difference is if I give it a query with separate name and type components or combined into a LowerQuery.

However, this is not the case for the InMemoryAuthority (implementation).
search forwards to lookup in some cases but also implements some additional logic.
Some parts, for example the handling of SOA entries, I do not understand.
github.com/bluejekyll/trust-dns@028ac68ee0/crates/server/src/store/in_memory/authority.rs (L990-L993)
This code snippet always returns a SOA record for the zone root, if the query is of type SOA but ignoring the query name.

This is not how SOAs are usually processed. A SOA is included in a NODATA response because the miminum value of the SOA is needed for the negative caching. The SOA is in the authority section. The InMemoryAuthority::search function from above will, however, put the SOA in the answer section.

So my question is what is the intended difference between these two functions?

$ dig @ns1.google.com soa www.google.com

; <<>> DiG 9.11.24-RedHat-9.11.24-2.fc33 <<>> @ns1.google.com soa www.google.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2887
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.google.com.			IN	SOA

;; AUTHORITY SECTION:
google.com.		60	IN	SOA	ns1.google.com. dns-admin.google.com. 345197775 900 900 1800 60

;; Query time: 57 msec
;; SERVER: 2001:4860:4802:32::a#53(2001:4860:4802:32::a)
;; WHEN: Mi Dez 02 23:34:13 CET 2020
;; MSG SIZE  rcvd: 93

Originally created by @jonasbb on GitHub (Dec 2, 2020). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1309 Currently, I am trying to implement an authoritative DNS server with the help of `trust-dns-server`. I am not sure what exactly the difference between [`Authority::lookup`](https://docs.rs/trust-dns-server/0.20.0-alpha.3/trust_dns_server/authority/trait.Authority.html#tymethod.lookup) and [`Authority::search`](https://docs.rs/trust-dns-server/0.20.0-alpha.3/trust_dns_server/authority/trait.Authority.html#tymethod.search) is. It sounds like the only difference is if I give it a query with separate name and type components or combined into a `LowerQuery`. However, this is not the case for the `InMemoryAuthority` ([implementation](https://github.com/bluejekyll/trust-dns/blob/028ac68ee016c1b5d92366ee5fe6661f6132de4d/crates/server/src/store/in_memory/authority.rs#L962)). `search` forwards to `lookup` in some cases but also implements some additional logic. Some parts, for example the handling of `SOA` entries, I do not understand. https://github.com/bluejekyll/trust-dns/blob/028ac68ee016c1b5d92366ee5fe6661f6132de4d/crates/server/src/store/in_memory/authority.rs#L990-L993 This code snippet always returns a SOA record for the zone root, if the query is of type SOA but ignoring the query name. This is not how SOAs are usually processed. A SOA is included in a NODATA response because the miminum value of the SOA is needed for the negative caching. The SOA is in the authority section. The `InMemoryAuthority::search` function from above will, however, put the SOA in the answer section. So my question is what is the intended difference between these two functions? ```text $ dig @ns1.google.com soa www.google.com ; <<>> DiG 9.11.24-RedHat-9.11.24-2.fc33 <<>> @ns1.google.com soa www.google.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2887 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.google.com. IN SOA ;; AUTHORITY SECTION: google.com. 60 IN SOA ns1.google.com. dns-admin.google.com. 345197775 900 900 1800 60 ;; Query time: 57 msec ;; SERVER: 2001:4860:4802:32::a#53(2001:4860:4802:32::a) ;; WHEN: Mi Dez 02 23:34:13 CET 2020 ;; MSG SIZE rcvd: 93 ```

kerem added the

question

label

2026-03-15 23:39:59 +03:00

kerem commented

2026-03-15 23:40:10 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 29, 2020):

Late reply. There may be a degenerate case here that's happening? The intention is to reply with the SOA in any case where a record is not found, which I thought was standard practice.

In terms of the difference between query and lookup, there may be little to no difference. Back when I refactored the code to allow for different types of authorities, I was trying to share as much code as possible, so it might be left over from that and perhaps one isn't needed and can be removed? We'll have to do some code spelunking to figure that out.

@bluejekyll commented on GitHub (Dec 29, 2020): Late reply. There may be a degenerate case here that's happening? The intention is to reply with the SOA in any case where a record is not found, which I thought was standard practice. In terms of the difference between `query` and `lookup`, there may be little to no difference. Back when I refactored the code to allow for different types of authorities, I was trying to share as much code as possible, so it might be left over from that and perhaps one isn't needed and can be removed? We'll have to do some code spelunking to figure that out.

kerem commented

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

Author

Owner

@jonasbb commented on GitHub (Dec 29, 2020):

Hi, thanks for the reply.

The intention is to reply with the SOA in any case where a record is not found, which I thought was standard practice.

Yes it is standard practice to include a SOA in this case. The SOA should go into the authority section in this case. The code will put the SOA into the answer section though.

From the initial post:

This is not how SOAs are usually processed. A SOA is included in a NODATA response because the miminum value of the SOA is needed for the negative caching. The SOA is in the authority section. The InMemoryAuthority::search function from above will, however, put the SOA in the answer section.

In terms of the difference between query and lookup, [...]

Just to clarify, you mean search here instead of query, right?

@jonasbb commented on GitHub (Dec 29, 2020): Hi, thanks for the reply. > The intention is to reply with the SOA in any case where a record is not found, which I thought was standard practice. Yes it is standard practice to include a SOA in this case. The SOA should go into the authority section in this case. The code will put the SOA into the answer section though. From the initial post: > This is not how SOAs are usually processed. A SOA is included in a NODATA response because the miminum value of the SOA is needed for the negative caching. The SOA is in the authority section. The `InMemoryAuthority::search` function from above will, however, put the SOA in the answer section. --- > In terms of the difference between `query` and `lookup`, [...] Just to clarify, you mean `search` here instead of `query`, right?

kerem commented

2026-03-15 23:40:21 +03:00

Author

Owner

@djc commented on GitHub (Dec 29, 2020):

@jonasbb doing a bunch of refactoring in the server recently, I'd be happy to work with you to figure out how the current design can be simplified.

@djc commented on GitHub (Dec 29, 2020): @jonasbb doing a bunch of refactoring in the server recently, I'd be happy to work with you to figure out how the current design can be simplified.

kerem commented

2026-03-15 23:40:26 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 29, 2020):

Yes it is standard practice to include a SOA in this case. The SOA should go into the authority section in this case. The code will put the SOA into the answer section though.

Ah, yes, that should be fixed. Thanks for catching that.

Just to clarify, you mean search here instead of query, right?

Yes. I was looking at the code and the only difference in the signatures is that one takes Query and the other a LowerName and RecordType. So I confused myself in the response to your question. Again, I'm not sure when/why I decided that made sense...

@bluejekyll commented on GitHub (Dec 29, 2020): > Yes it is standard practice to include a SOA in this case. The SOA should go into the authority section in this case. The code will put the SOA into the answer section though. Ah, yes, that should be fixed. Thanks for catching that. > Just to clarify, you mean search here instead of query, right? Yes. I was looking at the code and the only difference in the signatures is that one takes `Query` and the other a `LowerName` and `RecordType`. So I confused myself in the response to your question. Again, I'm not sure when/why I decided that made sense...

kerem commented

2026-03-15 23:40:31 +03:00

Author

Owner

@jonasbb commented on GitHub (Dec 30, 2020):

@djc Thanks for the info. I also saw the new release. I will check out what kind of changes there are. I also joined the Discord channel, so I am happy to discuss stuff either there or on GitHub.

For my use case I had trouble getting the standard MessageResponse to work for me, since due to the embedded lifetimes I found it hard to dynamically create a response. That is, having a function, which given a QNAME (and maybe a QTYPE) return a MessageResponse which has some dynamic value, e.g., the current time. I'm happy to expand on my use cases.

@jonasbb commented on GitHub (Dec 30, 2020): @djc Thanks for the info. I also saw the new release. I will check out what kind of changes there are. I also joined the Discord channel, so I am happy to discuss stuff either there or on GitHub. For my use case I had trouble getting the standard `MessageResponse` to work for me, since due to the embedded lifetimes I found it hard to dynamically create a response. That is, having a function, which given a QNAME (and maybe a QTYPE) return a `MessageResponse` which has some dynamic value, e.g., the current time. I'm happy to expand on my use cases.

kerem referenced this issue

2026-03-16 02:13:48 +03:00

[PR #647] [MERGED] Add SSHFP and OPENPGPKEY support #1572