On Wed, 11 Oct 2006, Keith Moore wrote:
> In the past month or so I've run across two separate ISPs that are
> apparently polluting the DNS by returning A records in cases where the
> authoritative server would either return NXDOMAIN or no answers. The A
> records generally point to an HTTP server that will display
> advertisements, but I've also seen more sinister things happen.
>
> Is there anything that IETF as an organization, or IETF participants,
> can do to discourage this? To me this is fraud and unfair trade
> practice in addition to being a security threat (as people give their
> passwords when trying to connect to the wrong site) and harmful to
> applications (either because they do connect to a protocol engine on the
> wrong server, or they try to connect to a nonexistent protocol engine on
> the wrong server and treat the "connection refused" or "connection timed
> out" condition as a temporary error). I've also seen this break
> applications that speak both IPv4 and IPv6 by failing to return the AAAA
> records.
I agree. For me personally, this was not hypothetical. The Pine mail
user agent that I use began to intermittently fail to connect to the
IMAP server even when there was no evidence of problems with network
connectivity. The problem turned out to be DNS fraud.
I use ssh to connect over DSL service from Earthlink, and port
forwarding to get to the IMAP server. That means Pine needs to
connect to 127.0.0.1 on the forwarded port number. I don't know why,
but Pine does a DNS lookup on 127.0.0.1. My problems arose when the
Earthink DNS servers began returning A records for a host that, if
accessed via http, provides a "helpful" message that the web site
address I had entered could not be found. The DNS exchange, as
displayed by ethereal:
DNS Standard query A 127.0.0.1
DNS Standard query response A 209.86.66.92 A 209.86.66.93 A 209.86.66.94 A 209.86.66.95 A 209.86.66.90 A 209.86.66.91
This caused Pine to attempt an IMAP connection directly to that host
rather than connecting to my intended IMAP server through the ssh port
forwarding.
Why the behavior was intermittent I have no idea, but the problem was
baffling. I was able to figure out the answer because I am able to
run tcpdump and interpret the results. Someone with less knowledge
would just have to suffer.
-- Steve
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf