Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Units and case-sensitivity #41

Open
bortzmeyer opened this issue Sep 26, 2022 · 3 comments
Open

Units and case-sensitivity #41

bortzmeyer opened this issue Sep 26, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@bortzmeyer
Copy link

Some units are case-sensitive, for instance MB and Mb are different things. But the DNS is case-insensitive, which means that this behavior is logical, but surprising:

% dig 32GB-Mb.unit @dns.toys

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> 32GB-Mb.unit @dns.toys
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10293
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;32GB-Mb.unit.		IN A

;; ANSWER SECTION:
32GB-Mb.		1 IN TXT "32.00 Gigabyte (GB) = 256000.00 Megabit (Mb)"

;; Query time: 84 msec
;; SERVER: 2604:a880:400:d0::1352:6001#53(dns.toys) (UDP)
;; WHEN: Mon Sep 26 14:01:38 CEST 2022
;; MSG SIZE  rcvd: 94

% dig 32GB-MB.unit @dns.toys

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> 32GB-MB.unit @dns.toys
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37544
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;32GB-MB.unit.		IN A

;; ANSWER SECTION:
32GB-MB.		1 IN TXT "32.00 Gigabyte (GB) = 32000.00 Megabyte (MB)"

;; Query time: 84 msec
;; SERVER: 2604:a880:400:d0::1352:6001#53(dns.toys) (UDP)
;; WHEN: Mon Sep 26 14:01:39 CEST 2022
;; MSG SIZE  rcvd: 94

This is even worse if DNS requests go through a forwarder which downcases everything (a bad idea, but it may happen). May be a word in the documentation?

@knadh
Copy link
Owner

knadh commented Sep 27, 2022

Thanks for pointing this out! How about responding with all possible case combinations?

;; ANSWER SECTION:
32GB-Mb.		1 IN TXT "32.00 Gigabyte (GB) = 256000.00 Megabit (Mb)"
32GB-MB.		1 IN TXT "32.00 Gigabyte (GB) = 32000.00 Megabyte (MB)"

@knadh knadh added the enhancement New feature or request label Sep 27, 2022
@bortzmeyer
Copy link
Author

Thanks for pointing this out! How about responding with all possible case combinations?

It seems an interesting idea.

PS : the problem also arises if the resolver does 0x20 (varying the case to have more entropy, in order to fend off poisoning attempts). Knot does this by default.

@mcint
Copy link

mcint commented Jan 7, 2024

I'm having issues from my dns client evidently lowercasing queries before sending them. I might file bugs there (though it's un-/under-maintained), but it might be nice if dns.toys were robust to this.

So far, I've found that units (digital) and timestamp-from-to conversions error.

Unit (digital)

$ dog @dns.toys 42GB-MB.unit
Status: Server Failure
TXT  1s + "error: unknown unit: gb. 'dig unit' to see list of units."

$ dig @dns.toys 42GB-MB.unit +short
42GB-MB.                1       IN      TXT     "42.00 Gigabyte (GB) = 42000.00 Megabyte (MB)"

Please consider:

Time conversion

$ dog 2023-05-28T14:00-mumbai-paris/fr.time @dns.toys
Status: Server Failure
TXT  1s + "error: invalid time format"

$ dig 2023-05-28T14:00-mumbai-paris/fr.time @dns.toys +short
"Mumbai (Asia/Kolkata, IN) Sun, 28 May 2023 14:00:00 +0530" "=" "Paris (Europe/Paris, FR) Sun, 28 May 2023 10:30:00 +0200"
  • Support lowercased timestamp parsing.
    • 2023-05-28t14:00-mumbai-paris/fr.time (additional)
    • 2023-05-28T14:00-mumbai-paris/fr.time (current)

I'm using dog because I can so conveniently issue request about multiple domains (cross-product) with multiple record types at once.

see

$ dog @1.1 example.com xkcd.com SOA NS TXT

SOA example.com.   1h00m00s   "ns.icann.org." "noc.dns.icann.org." 2022091389 2h00m00s 1h00m00s 14d0h00m00s 1h00m00s
 NS example.com.  22h06m37s   "a.iana-servers.net."
 NS example.com.  22h06m37s   "b.iana-servers.net."
TXT example.com. 1d0h00m00s   "v=spf1 -all"
TXT example.com. 1d0h00m00s   "wgyf8z8cgvm2qmxpnbnldrcltvk4xqfn"
SOA xkcd.com.         1m00s   "dns1.p03.nsone.net." "hostmaster.nsone.net." 1617157317 12h00m00s 2h00m00s 14d0h00m00s 1h00m00s
 NS xkcd.com.      1h00m00s   "dns1.p03.nsone.net."
 NS xkcd.com.      1h00m00s   "dns2.p03.nsone.net."
 NS xkcd.com.      1h00m00s   "dns3.p03.nsone.net."
 NS xkcd.com.      1h00m00s   "dns4.p03.nsone.net."
TXT xkcd.com.      1h00m00s   "v=spf1 include:_spf.google.com include:mailgun.org ~all"
dog trace snippet confirming lowercasing

See line 1 with upper-case, and log starting at line 3, with lowercased domain part
Screenshot_20240107_022113

RFCs: standards on DNS and case-(in)sensitivity

While RFC (4343) titled "Domain Name System (DNS) Case Insensitivity Clarification" (Jan 2006) weighs in on this,

4. Case on Input and Output

While ASCII label comparisons are case insensitive, [STD13] says case
MUST be preserved on output and preserved when convenient on input.
However, this means less than it would appear, since the preservation
of case on output is NOT required when output is optimized by the use
of indirect labels, as explained below.

Perhaps based on advice for handling punycode encoding of Unicode names, per RFC 5890 (2010), this dog DNS client project chooses to lowercase the inputs, which does not seem obviously wrong on its face.

A consequence of the restrictions on valid characters in the native
Unicode character form (see U-labels) turns out to be that mixed-case
annotation, of the sort outlined in Appendix A of RFC 3492 [RFC3492],
is never useful. Therefore, since a valid A-label is the result of
Punycode encoding of a U-label, A-labels should be produced only in
lowercase, despite matching other (mixed-case or uppercase) potential
labels in the DNS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants