1

Example (1) of an expected DNS lookup result:

nslookup google.com
Server:  192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: google.com
Address: 173.194.123.41
Name: google.com
Address: 173.194.123.33
...

Example (2) of what I am asking is valid or not:

nslookup google.com
Server:  192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: google.coM
Address: 173.194.123.33
Name: google.coM
Address: 173.194.123.34
...

Note the last letter M in the second example. This was noticed recently on a network with Verizon Fios Quantum.

Does the DNS spec says its acceptable to get a response different than what you request? I know DNS is case insensitive in the respect that if you type in www.GooGLe.cOM you will get the same IP address as www.google.com, but I would think in both of these cases the response should/must match the query exactly.

3

In your case, it is likely that a resolver is adding 0x20 encoding to your request, and this encoding is being cached and served locally contrary to common practice:

While the use of mixed case is allowed in DNS, and leveraged by the IETF draft, "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity" as a DNS forgery/poisoning mitigation technique, it is not enforced by the DNS specification - a server is not obligated to return the exact character encoding, albeit rare; this is a potential issue discussed within the draft.

Because all** DNS implementations copy the request exactly into the response (in practice), a request for a domain in mixed-case is returned as such. A client can randomize the character case, and compare the response by the server, which should match:

(Section 2.2) For example, the following question names will be treated as equal by a responder, but can be treated as unequal by a requestor:

www.ietf.org
WwW.iEtF.oRg
wWw.IeTf.OrG
WWW.IETF.ORG

An attacker would need to successfully guess the random encoding or the client will ignore it. As the strength of the encoding is related to the length of the domain name, a longer domain provides greater security - more characters, more entropy.


It is possible with a non-0x20 implemented client (and after eliminating the likelihood of a middleman introducing encoding,) that a response returned with encoding not in the original request -could- be the result of a poisoning attempt.

| improve this answer | |
  • 1
    But if you're doing *0x20 encoding" you're supposed to restore the casing in what you return to your requestor to whatever their question looked like, right? – Håkan Lindqvist Feb 26 '16 at 7:47
  • Exactly where I was going - how does my own code/client trust that it's request gets a safe response if it doesn't match exactly? – hooby3dfx Feb 26 '16 at 12:53
  • @hooby3dfx - thats an inherent trust - if you're using a library that checks 0x20 then it should generate an error, and not accept the answer; otherwise it doesn't mean much - and without knowing more about the chain of software between you and the server its difficult to answer. Its possible the mismatch is a cached answer at your resolver. What OS/version is your nslookup, and what is operating at 192.168.1.1? – pete Feb 26 '16 at 16:01
  • @HåkanLindqvist You are technically correct: Section 6.4 Suggests a fallback strategy where if 0x20 fails verification, other servers are attempted with new 0x20 encoding - in this case the requester can ignore the encoding discrepancy. Section 5.4 refers to restoring the original request after stripping verified 0x20 encoding, to prevent mucking up the cache if compression pointers in the answer point back to the encoded question - To me this implies that if pointers are not used, its possible for an answer to retain the 0x20 even though the original question was stripped. – pete Feb 26 '16 at 16:16
  • @hooby3dfx - Also, being Verizon, its more than likely that they are doing stupid things with their DNS, and this might be a result of that. To know for sure you would need to capture packets on your network and analyze the requests to find where the encoding was generated, or lost. – pete Feb 26 '16 at 16:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.