Re: DNS pollution
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DNS pollution



dust off the IAB wildcard statement, and say "it's not any better when YOU do it"?

http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html

While we're at it, let's say "blocking SRV records in your DNS proxy is harmful too".

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'm willing to write a draft explaining in detail why this is harmful, but somehow I think it will take more than just an RFC to get this practice stopped.

Keith


_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf





_____________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.