IPv6 AAAA records corrupting IPv4 entry in dns host cache

sylvain.munaut · ‎06-21-2011

Hi,

I have a 1812 router configured to do DNS caching. It runs 15.1(4)M (but the same issue was seen with 15.1(3)T).

What happens is that "in some cases" (but repeatably), when an AAAA record is fetched/cached, it corrupts the IPv4 entry.

Here's a repeatable example:

First clear off any trace of it:

router#clear host www.ovh.com

router#clear host ovh.com

router#show hosts www.ovh.com

Host Port Flags Age Type Address(es)

Then we do a ping www.ovh.com from a network machine to fetch the IPv4 entry (which is a CNAME to ovh.com)

router#show hosts www.ovh.com

Host Port Flags Age Type Address(es)

ovh.com None (temp, OK) 0 IP 213.186.33.34

And then we do a ping6 www.ovh.com to fetch the IPv6 record.

router#show hosts www.ovh.com

Host Port Flags Age Type Address(es)

www.ovh.com None (temp, OK) 0 IP 0.0.3.4

ovh.com None (temp, OK) 0 IPv6 2001:41D0:1:1B00:213:186:33:34

And as you can see the IPv4 entry now has 0.0.3.4 as value ... which happens to be the last part of the ipv6 "0034" (16 bits somehow expanded to BCD representation ???).

You can also notice that the numbering scheme of that company is to map ipv4 to ipv4 (the last 4 groups of 16 bits of the IPv6 displayed in hex are a match to the IPv4 213:186:33:34 ~ 213.186.33.34). No idea if it's related or not.

It doesn't have the same behavior for all the domains (actually ovh.com is the only one I noticed the problem).

bash$ host www.ovh.com 195.238.2.21

Using domain server:

Name: 195.238.2.21

Address: 195.238.2.21#53

Aliases:

www.ovh.com is an alias for ovh.com.

ovh.com has address 213.186.33.34

ovh.com has IPv6 address 2001:41d0:1:1b00:213:186:33:34

ovh.com mail is handled by 5 mx2.ovh.net.

ovh.com mail is handled by 100 mxb.ovh.net.

ovh.com mail is handled by 1 mx1.ovh.net.

Also, it seems the CNAME is required for the bug to happen because the problem only appears on www.ovh.com and not ovh.com

Cheers,

Sylvain

Phillip Remaker · ‎07-06-2011

Looking at the packet traces you have in the spawned case, it looks like the device performing the NAT might be doing incorrect things with the DNS lookups and translations. The 1812 seems to just be absorbing and displaying the incorrect information as seen on the wire?

Not sure why the PC does not see the same thing. The packet traces are certainly curious.

sylvain.munaut · ‎07-06-2011

I don't understand what you mean.

The capture file 'capture-router-wan.pcap' is from the router 1921/1812 (I tried both, the capture is from a 1921) to the opendns server (10.192.1.70 -> 208.67.222.222).

This capture shows the DNS query send by the router and both the querie and answer looks perfect.

The capture file 'capture-pc-router.pcap' is from my laptop to the same router 1921. This capture shows the DNS queries I send with my PC to the IOS embedded DNS server. And on this capture you can see that the IOS DNS server serves the proper response on the first query (A), then serves the correct response for the second query (PTR for ipv6), then for the third query, it serves back garbage (because the PTR query for an ipv6 ip somehow internally corrupted the router mapping table between hostname and IPs. My theory at least).

(both capture were done at the same time, capturing the same queries, just two different sides of the 1921)

Phillip Remaker · ‎07-08-2011

OK, I didn't understand that the issue was involving the embedded IOS DNS server. Looking back at the thread, I'm not sure how I misunderstood that, sorry.

Looks very bug like. The TAC engineer should be able to refer to to the IOS DNS server group if we can readily reproduce it. Good job digging up all the details so clearly.