Internet DRAFT - draft-ohta-practically-secure-dns
draft-ohta-practically-secure-dns
INTERNET DRAFT M. Ohta
draft-ohta-practically-secure-dns-00.txt Tokyo Institute of Technology
Intended status: Standard Track October 24, 2011
Expires: April 23, 2012
Practically Secure DNS
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
Plain DNS without PKI is secure, if a chain of query/response
communications between a client and an authoritative server relayed
by zero or more intermediate resolvers and the authoritative server
and all the resolvers are secure.
However, because of short (16bit) message ID, the communications
composing the chain are not very secure without, or even with (port
exhaustion attack is possible), source port randomization.
M. Ohta Expires on April 20, 2012 [Page 1]
INTERNET DRAFT Practically Secure DNS October 2011
Still, plain DNS can be made practically secure, if the client makes
two queries with independent message IDs to an address of a server (a
resolver or a name server) and confirm that two replies are
identical.
1. Security Considerations
This memo proposes rather an implementation guideline than protocol
modifications to DNS [DNS] to make DNS without PKI practically secure
by letting a DNS client make two (or more, if necessary) queries,
which are identical save cryptographically randomized message IDs, to
a server (a resolver or a name server) over UDP and let the client
check whether the replies are identical or not, ignoring inessential
differences of RR ordering, character cases of labels and compression
of labels.
Queries should have identical source and destination addresses and
randomized source port numbers. The second query may immediately
follow the first one without a randomized interval.
While multiple queries increases the number of packets exchanged a
little more than twice, the number of packets and associated
computation load are expected to be considerably less than
queries/replies over TCP (according to [TTCP], 10 packets are
exchanged) and much less than those with [SDNS].
If there is no reply after reasonable time out, it is a temporal
failure.
If there is only one reply after the reasonable time out, another
query should be sent, failure to get the second reply after the
reasonable time out is a temporal failure.
If two replies are received but not identical, it should be because:
1) versions of some zones related to the queries changes between
the queries; or
2) replies are constructed from different cache content; or
3) the server is actively randomizing answers for load balancing
and other purposes; or
4) the client is under a message ID guessing attack.
Even though two queries are made with a short interval, 1) and 2) can
still occur, because zone version and cache content may change during
the interval.
M. Ohta Expires on April 20, 2012 [Page 2]
INTERNET DRAFT Practically Secure DNS October 2011
In any case, additional one or two queries, with different message
IDs, should be generated.
For cases 1), 2), 3) (only if randomization is based on client
address) and 4), one or two more queries should be enough to have two
identical replies, which should be practically secure. If no
identical replies are available, it should be case 3) with truly
random replies.
During waiting replies, case 4) can be identified by replies with
unmatched message IDs, which should initiate serious security alerts.
Otherwise, it should be case 3) and, unless case 4) is identified to
be simultaneously occurring, one of the replies should be practically
secure, though it is less secure. As DNS assumes "the system should
be able to deal with subsets that change more rapidly (on the order
of seconds or minutes)" [DNS], it is a natural consequence of
randomizing servers to break the fundamental principle of DNS. If
case 3) and 4) is simultaneously occurring, it's a temporal failure.
A resolver used by a practically secure DNS client should also behave
as a client of practically secure DNS to make DNS practically secure
end to end. However, then, the resolver must merge identical queries
from its clients to prevent exponential growth of DNS traffic. If the
resolver consists of internal multiple servers, identical queries
should be forwarded to a single internal server based on source
addresses of the queries, to prevent the exponential growth.
A resolver unaware of practically secure DNS may generate multiple
queries as a client, if corresponding multiple queries come from its
clients.
2. IANA Considerations
This document has no actions for IANA.
Normative References
[DNS] STD0013.
Informative References
[TTCP] R. Braden, "Extending TCP for Transactions -- Concepts", .
RFC1379, November 1992.
[SDNS] R. Arends, R. Austein, M. Larson, D. Massey and S. Rose, "DNS
Security Introduction and Requirements". RFC4033 , March 2005.
M. Ohta Expires on April 20, 2012 [Page 3]
INTERNET DRAFT Practically Secure DNS October 2011
Author's Address
Masataka Ohta
Graduate School of Information Science and Engineering
Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku
Tokyo 152-8552, JAPAN
Phone: +81-3-5734-3299
Fax: +81-3-5734-3299
EMail: mohta@necom830.hpcl.titech.ac.jp
M. Ohta Expires on April 20, 2012 [Page 4]
