Units and case-sensitivity

[bortzmeyer]

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]

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)"

[bortzmeyer]

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]

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:

• [ ] It might be nice to include or handle decimal and binary prefixes: giga- (10^9) versus gibi- (2^30). (See also Unit prefixes and binary prefixes, with history & commentary)
• [ ] Supporting lowercase only bi for bits, and by for bytes, might also be tenable.

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

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.