One thought:
every time we encounter one of those problems, we should report an issue
to the ISP's helpdesk.
If the opex of the "feature" is high enough, even accountants may get
the point....
Stephen Casner wrote:
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
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf