Hello,
There will be a panel discussion at IETF 75 about Securing the "DNS:
Leading the next step towards a more secure Internet" [1]. There is
also a proposal on the agenda of the DNS Operations Working Group [2]
about using DNS to protect users. The ongoing discussions about that
proposal reminded me of "Offentlighetsprincipen" (a Swedish
word). It is viewed in some circles that whoever controls DNS
controls the Internet. In 2003, there was a controversy about some
changes made in DNS. The IAB posted a commentary [3] about it. I'll
quote an excerpt:
"There are many architectural assumptions regarding DNS behavior
that are not
specified in the IETF standards documents describing DNS, but
which are deeply
embedded in the behavior of Internet protocols and applications. These
assumptions are inherent parts of the network architecture of
which the DNS is
one component."
Some of the design goals of DNS (RFC 1034) are:
"The primary goal is a consistent name space which will be used
for referring to resources. In order to avoid the problems
caused by ad hoc encodings, names should not be required to
contain network identifiers, addresses, routes, or similar
information as part of the name.
Because we want the name space to be useful in dissimilar
networks and applications, we provide the ability to use the
same name space with different protocol families or
management.
We want name server transactions to be independent of the
communications system that carries them."
Although communication systems refer to the circuit, there has been
some unstated assumptions that we have taken for granted over the
years. RFC 2826 discusses about a globally unique public name
space. RFC 4084 provides some terminology describing
"Internet connectivity". Most end-users are not aware that there are
different types of Internet access. Some of them confuse a "Web
address" with a domain name. The Web is the Internet to them.
Governments have sought to protect their citizens from the ills of
the Internet by re-purposing some of the technologies developed
within the IETF to block access to content. The IETF has a policy on
wiretapping (RFC 2804) which might provide some clues about the matter:
"The IETF, an international standards body, believes itself to be
the wrong forum for designing protocol or equipment features that
address needs arising from the laws of individual countries,
because these laws vary widely across the areas that IETF standards
are deployed in.
The IETF sets standards for communications that pass across
networks that may be owned, operated and maintained by people from
numerous jurisdictions with numerous requirements for privacy. In
light of these potentially divergent requirements, the IETF
believes that the operation of the Internet and the needs of its
users are best served by making sure the security properties of
connections across the Internet are as well known as possible. At
the present stage of our ignorance this means making them as free
from security loopholes as possible.
The IETF believes that mechanisms designed to
facilitate or enable wiretapping, or methods of using other
facilities for such purposes, should be openly described, so as to
ensure the maximum review of the mechanisms and ensure that they
adhere as closely as possible to their design constraints. The IETF
believes that the publication of such mechanisms, and the
publication of known weaknesses in such mechanisms, is a Good
Thing."
RFC 3924 specifies an architecture for lawful intercept in IP
Networks. RFC 3040 has some information about HTTP
interception. Some technologies operate at the DNS level for HTTP
interception. Although they are referred to as "DNS redirects", a
better name would be "DNS interception".
According to RFC 2181, the accuracy of (DNS) data available is
assumed from its source. Trustworthiness shall be, in order from
most to least:
Data from a primary zone file, other than glue data,
Data from a zone transfer, other than glue,
The authoritative data included in the answer section of an
authoritative reply.
Data from the authority section of an authoritative answer,
Glue from a primary zone, or glue from a zone transfer,
Data from the answer section of a non-authoritative answer, and
non-authoritative data from the answer section of authoritative
answers,
Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers.
There is an assumption that DNS resolver will not purposefully be
changing the data for non-technical reasons. Some people have said
that DNS resolvers are lying if they do such changes. If we use the
word "lie" to qualify it, we polarizes the discussion. It is
understandable that domain registrants and those near the top of the
DNS hierarchy are not so happy about such changes.
There is a security flag in the IPv4 header, known as the Evil bit
(RFC 3514), which can be used for distinguishing between packets that
have malicious intent. I personally don't think that there should be
a similar flag in DNS to signal intent.
End-users have an expectation that there should have safe
browsing. They don't bother about whether the magic is done through
DNS interception or any other means. On the other hand, the
technical measures are of interest to developers as there are some
applications that rely on the DNS NXDOMAIN code.
At the end of the day, whether we like it or not, there will be DNS
interception. The IETF can provide input for decision makers, be it
ISPs or regulatory bodies, by documenting the technique and/or
practice. The question is whether to do that through the proposal
that has been posted or some other Internet-Draft. Note that the
question is different from that of having a unique public name
space. I welcome your feedback.
Regards,
-sm
1. http://www.isoc.org/isoc/conferences/dnspanel/
2. http://tools.ietf.org/wg/dnsop/agenda
3. http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf