Leakage to 1.0.0.0/8 - comment on known source
Hello, I just joined this group today so wasn't part of the earlier discussion, but saw the mention of leakage in to 1.0.0.0/8 earlier. I thought I'd bring up a particular issue I've seen in the past involving the address 1.0.0.0 . The issue is that the DLink DSL-502T router as shipped in large numbers by Xtra has a flaw in the DNS resolver. If a DNS request for an AAAA record is sent to the router, I've observed it sending back a malformed response packed. This would only be a minor irritation, except that it seems to corrupt the DNS cache such that subsequent requests for A records return the address 1.0.0.0 . I have observed this occurring at two different premises, both with this same router and both having received it as part of Xtra subscription packages. The issue was reported through the standard service desk, but I was unsure of where else it could be reported to. Of course, even if fixed it is unlikely that many shipped units would be updated. Just thought I'd let people know that we have a possibly significant national source of this traffic. While probably fairly low in volume at the moment, it would be entirely possible for example that an update to Windows could trigger a sudden increase. Cheers, Tim
Timothy Goddard wrote:
The issue is that the DLink DSL-502T router as shipped in large numbers by Xtra has a flaw in the DNS resolver. If a DNS request for an AAAA record is sent to the router, I've observed it sending back a malformed response packed. This would only be a minor irritation, except that it seems to corrupt the DNS cache such that subsequent requests for A records return the address 1.0.0.0 .
Just thought I'd let people know that we have a possibly significant national source of this traffic. While probably fairly low in volume at the moment, it would be entirely possible for example that an update to Windows could trigger a sudden increase.
Interesting - I imagine it's a worldwide problem unless there's something NZ-specific about the software Xtra has deployed? I guess it also means it won't do v6 correctly.... Study on 1/8 traffic here: http://www.potaroo.net/studies/1slash8/1slash8.html An interesting read.
The issue is that the DLink DSL-502T router as shipped in large numbers by
Xtra has a flaw in the DNS resolver. If a DNS request for an AAAA record is sent to the router, I've observed it sending back a malformed response packed. T http://list.waikato.ac.nz/mailman/listinfo/nznog
I presume this is probably firmware specific. Have you tested with various firmwares to confirm the problem? That router has build chain available publicly I believe. While not going to solve the issue for a majority of users it should be easily fixable with a firmware update by those who want to fix it.
On Thu, 15 Apr 2010 01:15:26 Joel Wiramu Pauling wrote:
The issue is that the DLink DSL-502T router as shipped in large numbers by
Xtra has a flaw in the DNS resolver. If a DNS request for an AAAA record is sent to the router, I've observed it sending back a malformed response packed. T http://list.waikato.ac.nz/mailman/listinfo/nznog
I presume this is probably firmware specific. Have you tested with various firmwares to confirm the problem?
That router has build chain available publicly I believe. While not going to solve the issue for a majority of users it should be easily fixable with a firmware update by those who want to fix it.
I've managed to well and truly brick the Xtra-updated DSL-302T model before by installing original manufacturer's firmware, making me somewhat reluctant to experiment with others of the same family, especially when owned by other people. I know of two routers which definitely have this problem and can find out the firmware revision of one this weekend. Cheers, Tim
On 2010-04-15 09:55, Timothy Goddard wrote:
On Thu, 15 Apr 2010 01:15:26 Joel Wiramu Pauling wrote:
The issue is that the DLink DSL-502T router as shipped in large numbers by
Xtra has a flaw in the DNS resolver. If a DNS request for an AAAA record is sent to the router, I've observed it sending back a malformed response packed. T http://list.waikato.ac.nz/mailman/listinfo/nznog
I presume this is probably firmware specific. Have you tested with various firmwares to confirm the problem?
I suspect not. This problem would explain some very bizarre DNS problems I've experienced at home when using IPv6, with another DSL box from the same vendor, not used with Xtra. I never diagnosed it, but I bypassed it by disabling use of the resolver in the CPE and going straight to the ISP's resolver. Brian
I presume this is probably firmware specific. Have you tested with various firmwares to confirm the problem?
I suspect not. This problem would explain some very bizarre DNS problems I've experienced at home when using IPv6, with another DSL box from the same vendor, not used with Xtra.
I never diagnosed it, but I bypassed it by disabling use of the resolver in the CPE and going straight to the ISP's resolver.
I believe they are all using dnsmasq as the resolver, and old 2.4 linux kernels for network stack. It would not surprise me if the root lies in one or the other.
In either case I am fairly certain a customised firmware would solve the problem. Alternatively, just disable dns relay in dnsmasq on the router and hardcore an upstream one as you suggested. Kind regards -JoelW
On 2010-04-15 14:08, Joel Wiramu Pauling wrote:
I presume this is probably firmware specific. Have you tested with various firmwares to confirm the problem? I suspect not. This problem would explain some very bizarre DNS problems I've experienced at home when using IPv6, with another DSL box from the same vendor, not used with Xtra.
I never diagnosed it, but I bypassed it by disabling use of the resolver in the CPE and going straight to the ISP's resolver.
I believe they are all using dnsmasq as the resolver, and old 2.4 linux kernels for network stack. It would not surprise me if the root lies in one or the other.
In either case I am fairly certain a customised firmware would solve the problem. Alternatively, just disable dns relay in dnsmasq on the router and hardcore an upstream one as you suggested.
Or for geeks, install dnsmasq on the host: https://bugs.launchpad.net/ubuntu/+bug/81057/comments/18 Brian
Joel Wiramu Pauling wrote:
I presume this is probably firmware specific. Have you tested with
various
firmwares to confirm the problem?
I suspect not. This problem would explain some very bizarre DNS problems I've experienced at home when using IPv6, with another DSL box from the same vendor, not used with Xtra.
I never diagnosed it, but I bypassed it by disabling use of the resolver in the CPE and going straight to the ISP's resolver.
I believe they are all using dnsmasq as the resolver, and old 2.4 linux
kernels for network stack. It would not surprise me if the root lies in one or the other.
In either case I am fairly certain a customised firmware would solve the problem. Alternatively, just disable dns relay in dnsmasq on the router and hardcore an upstream one as you suggested.
It's a well known bug in dproxy-nexgen. It doesn't understand AAAA replies and corrupts them.[1] So since things do a AAAA query first, they get a response, which dproxy corrupts, and then caches. Then the follow up A query gets served out of the cache as 1.0.0.0 (or depending on what the reply was, potentially some other address). dproxy appears to be unmaintained since about 2004, but appears that it was added to the firmware of many (slightly older) embedded devices. There are many many reports around the Internet of people failing to resolve things (and then getting confused when "ping" works -- because ping is v4 only, it doesn't do the v6 query first) and many people hitting on the solution of "disabling IPv6", and reporting it upstream as a v6 bug in which ever piece of software they were using at the time they noticed the problem, few people seem to realise it's their ADSL modem, and only a couple have tracked it back to the particular software on the modem itself. There are also many people suggesting you hard code DNS servers (usually OpenDNS servers) to bypass the broken devices resolver. I had assumed that most of these devices had managed to reach their end of life one way or another, but it's quite possible that there are still a very large number of these devices around. [1]: http://sourceforge.net/tracker/index.php?func=detail&aid=1925234&group_id=2283&atid=102283
participants (6)
-
Brian E Carpenter -
David Taylor -
Joel Wiramu Pauling -
Perry Lorier -
Timothy Goddard -
Will Hargrave