[GH-ISSUE #1837] Authoritative DNS over QUIC (ADoQ) #788

New issue

Open

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

kerem commented

2026-03-16 00:14:38 +03:00

Owner

Originally created by @HLFH on GitHub (Nov 23, 2022).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1837

Is your feature request related to a problem? Please describe.

Internet Draft: https://datatracker.ietf.org/doc/html/draft-ietf-dprive-unilateral-probing-02

Describe the solution you'd like

An authoritative server SHOULD implement and deploy DNS-over-QUIC (DoQ) on UDP port 853.

Originally created by @HLFH on GitHub (Nov 23, 2022). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1837 **Is your feature request related to a problem? Please describe.** Internet Draft: https://datatracker.ietf.org/doc/html/draft-ietf-dprive-unilateral-probing-02 **Describe the solution you'd like** [An authoritative server SHOULD implement](https://datatracker.ietf.org/doc/html/draft-ietf-dprive-unilateral-probing-02#section-3) and deploy DNS-over-QUIC (DoQ) on UDP port 853.

kerem commented

2026-03-16 00:14:44 +03:00

Author

Owner

@djc commented on GitHub (Nov 23, 2022):

This doesn't read much like a feature request. What do you think we should change about trust-dns to support ADoQ? What did you try that did not work? Can you make this more concrete?

@djc commented on GitHub (Nov 23, 2022): This doesn't read much like a feature request. What do you think we should change about trust-dns to support ADoQ? What did you try that did not work? Can you make this more concrete?

kerem commented

2026-03-16 00:14:49 +03:00

Author

Owner

@HLFH commented on GitHub (Nov 28, 2022):

I created this issue wondering if trust-dns is fully compliant with RFC 9250.
It seems to be quite the case, so if you are confident it is fully compliant with this RFC, should not this support be mentioned in the README file of the project?

Regarding the mentioned Internet Draft, it seems trust-dns is already quite compliant with it, but I have not checked the details.

Before, I had a few issues to be able to answer you directly. But they are now solved.
I packaged trust-dns-git, so I can use trust-dns and the dns cli on Arch Linux.
I am using the last version of trust-dns (main branch).

When I test the dns client on UDP port 53, I get:

dns -p udp -n 127.0.0.1:53 query www.example.com SOA
; using udp:127.0.0.1:53
; sending query: www.example.com IN SOA
; received response
; header 6289:RESPONSE:RD,AA:NoError:QUERY:1/1/1
; edns version: 0 dnssec_ok: true max_payload: 1232 opts: 2
; query
;; www.example.com. IN SOA; mdns_unicast_response: false
; answers 1
example.com. 604800 IN SOA trust-dns.org. root.trust-dns.org. 199609203 28800 7200 604800 86400
; nameservers 1
example.com. 86400 IN NS bbb.example.com.
; additionals 1

When I test the dns client on QUIC port 853, I get:

dns -p quic -n 127.0.0.1:853 -t ns.example.com query www.example.com A  
; using quic:127.0.0.1:853 dns_name:ns.example.com
Error: ProtoError { kind: QuinnConnection(TransportError(Error { code: Code::crypto(2a), frame: None, reason: "invalid peer certificate contents: invalid peer certificate: UnknownIssuer" })), backtrack: None }

But it is probably not a big deal.

@HLFH commented on GitHub (Nov 28, 2022): I created this issue wondering if trust-dns is fully compliant with [RFC 9250](https://datatracker.ietf.org/doc/html/rfc9250). It seems to be quite the case, so if you are confident it is fully compliant with this RFC, should not this support be mentioned in the README file of the project? Regarding the mentioned [Internet Draft](https://datatracker.ietf.org/doc/html/draft-ietf-dprive-unilateral-probing-02), it seems trust-dns is already quite compliant with it, but I have not checked the details. Before, I had a few issues to be able to answer you directly. But they are now solved. I packaged [trust-dns-git](https://aur.archlinux.org/packages/trust-dns-git), so I can use `trust-dns` and the `dns` cli on Arch Linux. I am using the last version of trust-dns (main branch). When I test the `dns` client on UDP port 53, I get: ``` dns -p udp -n 127.0.0.1:53 query www.example.com SOA ; using udp:127.0.0.1:53 ; sending query: www.example.com IN SOA ; received response ; header 6289:RESPONSE:RD,AA:NoError:QUERY:1/1/1 ; edns version: 0 dnssec_ok: true max_payload: 1232 opts: 2 ; query ;; www.example.com. IN SOA; mdns_unicast_response: false ; answers 1 example.com. 604800 IN SOA trust-dns.org. root.trust-dns.org. 199609203 28800 7200 604800 86400 ; nameservers 1 example.com. 86400 IN NS bbb.example.com. ; additionals 1 ``` When I test the `dns` client on QUIC port 853, I get: ``` dns -p quic -n 127.0.0.1:853 -t ns.example.com query www.example.com A ; using quic:127.0.0.1:853 dns_name:ns.example.com Error: ProtoError { kind: QuinnConnection(TransportError(Error { code: Code::crypto(2a), frame: None, reason: "invalid peer certificate contents: invalid peer certificate: UnknownIssuer" })), backtrack: None } ``` But it is probably not a big deal.

kerem commented

2026-03-16 00:14:54 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 29, 2022):

I must have forgotten to list it in the readme. I hacked that in over a weekend for a hackathon with the IETF. If you’d want to submit a PR to update the readme, that would be great.

@bluejekyll commented on GitHub (Nov 29, 2022): I must have forgotten to list it in the readme. I hacked that in over a weekend for a hackathon with the IETF. If you’d want to submit a PR to update the readme, that would be great.

kerem commented

2026-03-16 00:14:59 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 29, 2022):

On your dns client issue, this looks like a certificate issue. Do you know what certificate your using for the trust-dns binary?

An option for the dns client is to ignore the cert with this --do-not-verify-nameserver-cert

@bluejekyll commented on GitHub (Nov 29, 2022): On your dns client issue, this looks like a certificate issue. Do you know what certificate your using for the trust-dns binary? An option for the dns client is to ignore the cert with this `--do-not-verify-nameserver-cert`