Open eminence opened 3 years ago
Currently dog will set use_std3_ascii_rules: true when doing IDNA label conversion:
dog
use_std3_ascii_rules: true
dns/src/strings.rs:25:
#[cfg(feature = "with_idna")] fn label_to_ascii(label: &str) -> Result<String, unic_idna::Errors> { let flags = unic_idna::Flags{use_std3_ascii_rules: true, transitional_processing: false, verify_dns_length: true}; unic_idna::to_ascii(label, flags) }
This prevents domain names with an underscore (_) from being resolved. Underscores are common in SRV records.
Here is an example of dog in its current state:
$ cargo run -- _xmpp-client._tcp.gmail.com SRV Finished dev [unoptimized] target(s) in 0.28s Running `target/debug/dog _xmpp-client._tcp.gmail.com SRV` dog: Invalid options: Invalid domain "_xmpp-client._tcp.gmail.com"
Here's what dig will return for the same domain:
dig
$ dig _xmpp-client._tcp.gmail.com SRV +nostats +nocomments ; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> _xmpp-client._tcp.gmail.com SRV +nostats +nocomments ;; global options: +cmd ;_xmpp-client._tcp.gmail.com. IN SRV _xmpp-client._tcp.gmail.com. 839 IN SRV 20 0 5222 alt3.xmpp.l.google.com. _xmpp-client._tcp.gmail.com. 839 IN SRV 20 0 5222 alt4.xmpp.l.google.com. _xmpp-client._tcp.gmail.com. 839 IN SRV 20 0 5222 alt2.xmpp.l.google.com. _xmpp-client._tcp.gmail.com. 839 IN SRV 5 0 5222 xmpp.l.google.com. _xmpp-client._tcp.gmail.com. 839 IN SRV 20 0 5222 alt1.xmpp.l.google.com.
If dog is modified to not enforce std3 ascii rules, we get the output expected:
$ cargo run -- _xmpp-client._tcp.gmail.com SRV Finished dev [unoptimized] target(s) in 0.19s Running `target/debug/dog _xmpp-client._tcp.gmail.com SRV` SRV _xmpp-client._tcp.gmail.com. 13m13s 20 0 "alt1.xmpp.l.google.com.":5222 SRV _xmpp-client._tcp.gmail.com. 13m13s 20 0 "alt3.xmpp.l.google.com.":5222 SRV _xmpp-client._tcp.gmail.com. 13m13s 20 0 "alt4.xmpp.l.google.com.":5222 SRV _xmpp-client._tcp.gmail.com. 13m13s 20 0 "alt2.xmpp.l.google.com.":5222 SRV _xmpp-client._tcp.gmail.com. 13m13s 5 0 "xmpp.l.google.com.":5222
Thanks!
See also: https://www.unicode.org/reports/tr46/#UseSTD3ASCIIRules
Ran into this issue today, and had to resort to using dig to resolve a subdomain containing an underscore.
Currently
dog
will setuse_std3_ascii_rules: true
when doing IDNA label conversion:dns/src/strings.rs:25:
This prevents domain names with an underscore (_) from being resolved. Underscores are common in SRV records.
Here is an example of
dog
in its current state:Here's what
dig
will return for the same domain:If
dog
is modified to not enforce std3 ascii rules, we get the output expected:Thanks!
See also: https://www.unicode.org/reports/tr46/#UseSTD3ASCIIRules