[dns-operations] Odd behaviour on one node in I root-server (facebook, youtube & twitter)
Roy Arends
roy at dnss.ec
Wed Mar 24 20:27:31 UTC 2010
On Mar 24, 2010, at 11:22 AM, Mauricio Vergara Ereche wrote:
> Hi there!
>
> A local ISP has told us that there's some strange behavior with at least one
> node in i.root-servers.net (traceroute shows mostly China)
> It seems that when you ask A records for facebook, youtube or twitter, you get
> an IP and not the referral for .com
>
> It doesn't happen every time, but we have confirmed this on 4 different
> connectivity places (3 in Chile, one in California)
>
> This problem has been reported to Autonomica/Netnod but I don't know if anyone
> else is seeing this issue.
I've seen it before. Here is the study I've done on this last year. I wanted to keep this internal, however, the cat is out of the bag now.
Here is the an excerpt of my research:
(dated January 3rd, 2010)
In the past few weeks, I've been researching an odd phenomenon. A good friend saw multiple responses to a single query. I was asked for my help to investigate it further.
The Odd Phenomenon:
A query for mgcxxx.com gets multiple responses. You can check it yourself, just send a query for mgcxxx.com to 121.14.70.7. The responses are as follows:
08:46:42.942678 IP 121.14.70.7.53 > 192.168.1.4.62553: 40159 1/0/0 A 37.61.54.158 (44)
08:46:42.942899 IP 121.14.70.7.53 > 192.168.1.4.62553: 40159* 1/0/0 SOA (54)
08:46:42.943656 IP 121.14.70.7.53 > 192.168.1.4.62553: 40159* 1/0/0 SOA (54)
08:46:42.943858 IP 121.14.70.7.53 > 192.168.1.4.62553: 40159* 1/0/0 SOA (54)
08:46:47.906630 IP 121.14.70.7.53 > 192.168.1.4.62553: 40159*- 1/0/0 SOA (102)
Investigating the individual packets:
Assuming the last packet is The Real Thing, lets try to identify which implementation it is:
Last packet:
0x0010: 9cdf 8400 .....5.Y.n1.....
0x0020: 0001 0001 0000 0000 066d 6763 7878 7803 .........mgcxxx.
0x0030: 636f 6d00 0006 0001 c00c 0006 0001 0000 com.............
0x0040: 0e10 003e 036e 7332 0978 696e 6e65 7464 ...>.ns2.xinnetd
0x0050: 6e73 0363 6f6d 000a 686f 7374 6d61 7374 ns.com..hostmast
0x0060: 6572 0978 696e 6e65 7464 6e73 c013 408f er.xinnetdns.. at .
0x0070: 39b4 0000 0e10 0000 0708 0009 3a80 0000 9...........:...
0x0080: 1c20 ..
Which translates to:
hdr: 8400 (QR RA) QUERY NOERROR
Que: 1 mgcxxx.com SOA IN
Ans: 1 mgcxxx.com (compressed) SOA IN 3600 (etc)
There is nothing wrong with this, all in spec. What is a dead giveaway though, is the compression pointer in the SOA RNAME and not in the SOA MNAME (for the .com part): NSD would compress the 'com' in the MNAME, and the 'xinnetdns.com' in the RNAME, and would have no problem to allow a pointer towards the MNAME in the SOA RDATA. BIND does it _exactly_ as above, it won't compress the MNAME, and refuses to have compression pointers point towards it. So, I'm pretty sure this is BIND.
A look at the other four packets:
First packet:
0x0010: 9cdf 8180 .....5.Y.4......
0x0020: 0001 0001 0000 0000 066d 6763 7878 7803 .........mgcxxx.
0x0030: 636f 6d00 0006 0001 c00c 0001 0001 0000 com.............
0x0040: 012c 0004 253d 369e .,..%=6.
Which translates to:
hdr: 8180 (QR RD RA) QUERY NOERROR
Que: 1 mgcxxx.com SOA IN
Ans: 1 mgcxxx.com (compressed) A IN 300 37.61.54.158
Aut: 0
Add: 0
What is wrong with this? It sets the RD bit which was not set in the query. Also, it responds (unsolicited) with an v4 address type (A) RDATA instead of SOA RDATA.
The second, third and fourth packet:
These are exactly the same, even down to the identifier in the IP header.
0x0010: 9cdf 8580 .....5.Y.>\.....
0x0020: 0001 0001 0000 0000 066d 6763 7878 7803 .........mgcxxx.
0x0030: 636f 6d00 0006 0001 066d 6763 7878 7803 com......mgcxxx.
0x0040: 636f 6d00 0006 0001 0001 5180 0004 253d com.......Q...%=
0x0050: 369e 6.
Which translates to:
hdr: 8580 (QR AA RD RA) QUERY NOERROR
Que: 1 mgcxxx.com SOA IN
Ans: 1 mgcxxx.com SOA IN 86400 (4) 25 3D 36 9E (37.61.54.158)
Aut: 0
Add: 0
What is wrong with this? It too sets the RD bit. It also does not do compression, as seen in the previous packet. The answer section is broken, as it pretends to be a SOA record, but the RDATA matches the previous packet (37.61.54.158).
So far the protocol invariance.
The range of spoofing:
What is impressive is that queries to all servers responsible for mgcxxx.com get spoofed: mgcxxx.com is hosted on ns2.xinnet.cn and ns2.xinnetdns.com. Which have the following listed addresses:
121.14.70.5
121.14.70.7
121.14.70.9
121.14.70.11
202.10.73.5
202.10.73.7
58.211.74.203
However, entire address spaces get spoofed:
Queries to ANYTHING in 121.8/13 get spoofed responses.
Queries to 121.14.70.[5|7|9|11] get spoofed responses PLUS the real response.
Queries to ANYTHING in 202.10.64/20 get spoofed responses.
Queries to 202.10.73.[5|7] get spoofed responses PLUS the real response.
Queries to ANYTHING in 58.128/9 get spoofed responses.
Queries to 58.211.74.203 get spoofed responses PLUS the real response.
These are very large ranges! There are plenty more networks that are being spoofed:
I've seen spoofed responses coming from the following ranges (some are big, some small, just an indication of the wider range, I do have the full specific ranges, but am reluctant to publish them as such).
58.*
59.*
60.*
78.*
110.*
112.*
113.*
120.*
121.*
122.*
125.*
202.*
203.*
210.*
211.*
What is being spoofed:
The spoofing occurs for names that contain xxx.com. Try xxx.com.dnss.ec or any other variant with xxx.com in it. The dot can actually be a real dot, not a label separator. So, maxxx.com.dnss.ec. works just a well as maxxx\.com.opendnssec.org. (i.e. when send to one of the networks... to try, use one of the specific ranges listed above).
Other names that will trigger spoofing are:
****** REMOVED ******* (to protect against identification, the list is currently about 20 entries long)
The spoofing is very effective against QTYPE of A. Note that the address I get might be different from the one you get, but is from a set of 15 or so addresses.
****
The above is an excerpt from a larger paper I've send around for discussion. I'm concerned to release it right now as it contains some fairly controversial conclusions.
With Kind Regards,
Roy
More information about the dns-operations
mailing list