Open bortzmeyer opened 1 year ago
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)"
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.
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.
$ 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:
bi
for bits, and by
for bytes, might also be tenable.$ 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"
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.
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.
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:
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?