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.

hooby3dfx
  • 173
  • 1
  • 6

1 Answers1

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.

Community
  • 1
pete
  • 723
  • 1
  • 7
  • 16
  • 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 07: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
  • Thank you - we noticed this was happening in the first place doing a packet capture. The setup used to troubleshoot so far: Macbook client (OSX) connected to a home Fios Quantum router (192.168.1.1) running nslookup command shows that querying www.google.com would come back as www.google.coM. Querying google using the same DNS servers that the router is using does not exhibit this behavior, so it appears something is going on in the router firmware. The next thing we want to try is a capture of the WAN side, but we need to contact Verizon to enable the ethernet port (right now only coax). – hooby3dfx Feb 26 '16 at 19:45
  • Verizon for the win :P If you restart the router does the case-encoding of the answer change? (i.e, was `google.coM`, but now `gOoGle.COm`, etc) If so it is likely caching the encoding. For diagnostics, the ONT has an ethernet port you can tap into that should be enabled. – pete Feb 26 '16 at 20:03
  • The ONT ethernet port is disabled, it sounds like we need to call Verizon to enable it. However, we did find that simply after disconnecting the coax cable from the router and then attaching it again, name resolution was back to normal (at least google.com was coming back as google.com). We are hoping to see it eventually get mixed up again. So the question still stands though - does this behavior bring the router out of DNS spec? – hooby3dfx Feb 26 '16 at 20:40
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/36285/discussion-between-hooby3dfx-and-pete). – hooby3dfx Feb 26 '16 at 20:51