Closed ruifung closed 1 year ago
Thanks for the post. Will study the DDR draft once. The issue with supporting unknown params is that the DNS server does not know how to serialize them. The params will eventually be registered and listed by IANA. I will add the relevant param support in coming updates too.
For adding support for generic params will need user to enter hex values. I can add that if that works for you,
That might work, figuring out the correct HEX key value, might be easier then trying to assemble an entire RDATA section by hand to shove into the unknown type I suppose.
Thanks for the clarification regarding the serialization. I haven't quite studied the dns protocol in that much detail.
Well, I've read it in more detail, and yeah, guess it's either HEX and probably HEX for the data too... given how the data format has to be specified in a document too, or maybe just looking into https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml from time to time I suppose. And yeah, dohpath is listed as number 7 there.
Relevant format specifier document: https://www.ietf.org/archive/id/draft-ietf-add-svcb-dns-08.html#name-dohpath
Cheers.
Thanks for the links. Will get this added in the next update.
But I also note that the IANA page has a range "reserved for private use"... so perhaps an option to enter an integer and HEX data for those might be handy.
But I also note that the IANA page has a range "reserved for private use"... so perhaps an option to enter an integer and HEX data for those might be handy.
Yes, that makes sense. Will get it added in next update.
Version 11.3 is now available which adds support for dohpath
SVCB parameter and also option to add generic parameters. Do update and let me know your feedback.
I just updated to 11.3, On the resolver.arpa zone i added multiple record's including the following:
_dns | SVCB | 3600 | Priority: 2 (service mode)
Target Name: dns.*****.org
Params:
Key | Value
alpn | h2
port | 443
ipv4hint | 10.xx.XXX.3,10.xx.YYY.3
dohpath | /dns-query{?dns}
When checking the records i get:
$ dig -t SVCB _dns.resolver.arpa
; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> -t SVCB _dns.resolver.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16045
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_dns.resolver.arpa. IN SVCB
;; ANSWER SECTION:
_dns.resolver.arpa. 3600 IN SVCB 3 dns.*****.org. alpn="dot" port=853 ipv4hint=10.xx.XXX.3,10.xx.YYY.3
_dns.resolver.arpa. 3600 IN SVCB 4 dns.*****.org. alpn="doq" port=853 ipv4hint=10.xx.XXX.3,10.xx.YYY.3
_dns.resolver.arpa. 3600 IN SVCB 2 dns.*****.org. alpn="h2" port=443 ipv4hint=10.xx.XXX.3,10.xx.YYY.3 key7="/dns-query{?dns}"
_dns.resolver.arpa. 3600 IN SVCB 1 dns.*****.org. alpn="h3" port=443 ipv4hint=10.xx.XXX.3,10.xx.YYY.3 key7="/dns-query{?dns}"
;; ADDITIONAL SECTION:
dns.*****.org. 3600 IN A 10.xx.XXX.3
dns.*****.org. 3600 IN A 10.xx.YYY.3
;; Query time: 4 msec
;; SERVER: 10.xx.YYY.3#53(10.xx.YYY.3) (UDP)
;; WHEN: Sun Jul 02 18:11:31 CEST 2023
;; MSG SIZE rcvd: 380
Why does it show key7=
instead of dohpath=
?
Thats just your dig not knowing how to parse it I believe.
I suspect that's indeed the problem, Technitium's internal (web) DNS Client does show the correct info (form&to both servers).
[...]
{
"Name": "_dns.resolver.arpa",
"Type": "SVCB",
"Class": "IN",
"TTL": "3600 (1 hour)",
"RDLENGTH": "68 bytes",
"RDATA": {
"SvcPriority": 2,
"TargetName": "dns.*****.org",
"SvcParams": {
"alpn": "h2",
"port": "443",
"ipv4hint": "10.xx.XXX.3,10.xx.YYY.3",
"dohpath": "/dns-query{?dns}"
}
},
"DnssecStatus": "Disabled"
},
[...]
Thank for the response.
Why does it show
key7=
instead ofdohpath=
?
Yes, as @ruifung mentioned, its just issue with dig which seems not yet been updated.
Continuing from #568
SVCB records for the use case of DDR for DNS over HTTPS, requires a dohpath parameter, and from my understanding of the relevant draft IETF document, the svcParams section is intended to be able to carry additional key/value pairs that may be required for a given application level protocol (for example, the aforementioned dohpath parameter) in addition to the initial set of predefined key/value pairs.
In light of that, perhaps having it maybe accept additional keys might be helpful, or at least the dohpath parameter for the DDR/DoH use case.
See https://datatracker.ietf.org/doc/draft-ietf-add-ddr/, section 3.