DNS Interception

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]