On 11Oct 2006, at 7:03 PM, 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.
Dear colleagues,
The IAB is working on a draft on transparency issues. It will appear
shortly in the I-D repository. That document contains a paragraph
about this issue:
2.5. DNS Namespace Mangling
In [RFC2826] the technical arguments for a unique root were
presented.
One of the premises in [RFC2826] is that a common symbol set, and
common semantics applied to these symbols, is needed for effective
communication between two parties. The document argues that this
principle can only be met when one unique root is being used and
when
the domains are maintained by single owners or maintainers.
Because [RFC4084] targets only on IP service terms and does not talk
about namespace issues, it does not refer to [RFC2826]. We stress
that for proper IP service the use of a unique root for the DNS
namespace is essential.
Since the publication of [RFC2826] there have been reports that
Internet service providers implement recursive nameservers and/or
DNS
forwarders that replace answers that indicate that a name does not
exist in the DNS hierarchy by a name and an address record that
hosts
a webservice that is supposed to be useful for end-users.
In a way the effect of these modifications are similar to placement
of a wildcard in top-level domains. Although wildcard labels in
top-
level domains lead to problems that are described elsewhere [Advs]
they do not strictly violate the DNS protocol. This is not the case
for the above example where the modification of answers takes place
in the middle of the path between authoritative servers and the stub
resolvers that provide the answers to applications.
[RFC2826] section 1.3 states:
Both the design and implementations of the DNS protocol are
heavily based on the assumption that there is a single owner or
maintainer for every domain, and that any set of resources
records
associated with a domain is modified in a single-copy
serializable
fashion.
In particular the DNSSEC protocol [RFC4035] has been designed to
verify that DNS information has not been modified between the moment
they have been published on an authoritative server and the moment
the validation takes place. Since that verification can take
place at
the application level, any modification by a recursive forwarder
will
cause validation failures.
On a similar but slightly different topic: We also send out a comment
to the relevant ICANN committee about the proposal to ad a wildcard
to the travel TLD. (Should appear on the correspondence area of the
IAB site shortly).
I think it may be a good idea to also create an IAB document that
documents all these DNS issues that have to do with namespace tricks.
The IAB comment on Sitefinder [1] could act as the core of that
document. I'd be happy to work with a few volunteers to make that fly.
--Olaf Kolkman
[1] http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html
-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/
PGP.sig
Description: This is a digitally signed message part
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf