Internet DRAFT - draft-ogud-dnsop-acl-metaqueries
draft-ogud-dnsop-acl-metaqueries
DNSOP O. Gudmundsson
Internet-Draft M. Majkowski
Updates: 1035 (if approved) CloudFlare Inc.
Intended status: Standards Track J. Abley
Expires: September 10, 2015 Dyn, Inc.
March 9, 2015
DNS Meta-Queries resticted.
draft-ogud-dnsop-acl-metaqueries-00
Abstract
Some DNS types have special meaning and are classified as meta
queries, this includes ANY, AXFR, IXFR. These queries frequently
return larger answers than queries for other types.
This document defines a standard way for Authoritative-Only servers
how to refuse to serve these and other similar queries, with the
expectation that resolvers honor that, by not asking followup
queries.
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."
This Internet-Draft will expire on September 10, 2015.
Copyright Notice
Copyright (c) 2015 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
Gudmundsson, et al. Expires September 10, 2015 [Page 1]
Internet-Draft Resticting DNS Meta-Queries March 2015
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Changes . . . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Implementation Experience . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Document history . . . . . . . . . . . . . . . . . . 5
A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 5
A.2. Abridged Revision History . . . . . . . . . . . . . . . . 5
A.2.1. draft-ogud-dnsop-any-notimp-00 . . . . . . . . . . . 5
A.2.2. draft-ogud-dnsop-acl-metaqueries-00 . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The DNS Specification [RFC1035] meta queries where defined for use
either zone maintainance AXFR, full zone transfer, IXFR [RFC1995],
incremental zone transfer. For security reasons Authoritative name
servers frequently only respond to these queries if a TSIG [RFC2845]
key is presented or the query comes from an approved address.
The ANY meta query was defined for debugging purposes mainly against
resolvers. There have been widespread misunderstanding as to what
the query is supposed to do and when it is approriate. The query is
intented for testing what records for a particular name a resolver
has in its cache. There are security implications related to
information leaks and use in DoS attacks that strongly argue for
restricting its use like the other Meta Queries.
RRSIG [RFC4034] type used in a query can also return large answers as
the server attempts to put all RRSIG records at that one name into
one answer. This type was envisioned as deployment tool for
validators to overcome DNSSEC ignorant resolvers and/or servers. For
all practical purposes this is never needed.
Gudmundsson, et al. Expires September 10, 2015 [Page 2]
Internet-Draft Resticting DNS Meta-Queries March 2015
Queries yielding large answers are known to be widely abused by
attackers carrying out reflection attacks, since they provide a
convenient way to elicit large responses from small queries, and
hence exhibit significant amplification potential. A similar
reaction to an operational security problem can be observed in the
advice contained within [RFC5358].
The data model used by some authoritative-only DNS server
implementations does not align easily with the zone structure
described in [RFC1035], and responding accurately to meta queries
involves significant processing overhead. The ability to refuse meta
queries can simplify the implementation with corresponding benefits
to performance and code correctness.
Recursive Resovlers frequently treat REFUSED as a temporary denial.
In the case of policy statement that certain queries will not
answered, having a more explicit statment is beneficial. There are
two chocies as how more permanent semantics can be expressed, reusing
an exisiting RCODE or define a new one. This docuemnt proposes
reusing the NOTIMP rcode. This feels like the right choice as as far
as the querier is concerned it makes no difference if the meta type
is implemented or the authoritative server has no interest in
providing that service to the client. There are other options like
defining new RCODE or place stronger semantics on REFUSED.
Various DNS operators have chosen to refuse various meta queries
including QTYPE=ANY in the past, using a variety of approaches,
including rate-limiting of queries and responses, returning TC=1 on
qeries received via UDP transport and silently dropping queries
before they reach the DNS server. Consistency in approach would
provide a more predictable outcome for DNS resolvers and clients.
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Protocol Changes
DNS processing entities SHOULD support authenticated meta queries,
and process them when appropriate as defined by policy. By default
the implemenations SHOULD be restrict it to localhost via ACL. For
all rejected meta-queries the behavior specified below SHOULD be
used. The types where this behavior is appropriate includes ANY,
AXFR, IXFR, RRSIG.
Gudmundsson, et al. Expires September 10, 2015 [Page 3]
Internet-Draft Resticting DNS Meta-Queries March 2015
An authoritative-only DNS server MAY reject meta queries received by
returning RCODE=4 (NOTIMP).
An iterative resolver MUST NOT forward a meta-query when the query
arrives with RD=0, even when it has no types for that name. An
iterative resolver SHOULD ignore RD=1 on a meta query, i.e. it SHOULD
NOT forward them upstream.
An iterative resolver that sends a query to an authoritative DNS
server and receives a response with RCODE=4 SHOULD remember that
upstream server's behaviour, for that qclass, qname, qtype
combination. It SHOULD suppress any subsequent qeries for that
qclass, qname, qtype to that server for at least one day (??? better
value needed).
4. IANA Considerations
No actions are requested of the IANA.
5. Security Considerations
In the original Internet where everyone behaved nicely had different
secrity and operating model than todays Internet. This document is
defining how DNS servers can express that they will never answer a
particular query from a given address.
RCODE=REFUSED is frequently treated as temporary thus resolver may
repeat queries in the hope of getting an answer.
An on-path attacker[RFC3833] can forge these answers easily, but as
that document explains the attacker can anyway inject any lies it
wants to.
6. Implementation Experience
TBD
7. Acknowledgements
Editors want to thank following people, in random order, for useful
feedback: Paul Vixie, Tony Finch, Ralph Weber, Mark Andrews, Stephane
ortzmeyre, Filippo Valsodra, Edward Lewis, and we forgot someone.
8. References
Gudmundsson, et al. Expires September 10, 2015 [Page 4]
Internet-Draft Resticting DNS Meta-Queries March 2015
8.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", BCP 140, RFC 5358,
October 2008.
Appendix A. Document history
This section (and sub-sections) should be removed before publication.
A.1. Venue
An appropriate venue to discuss this draft is the dnsop working group
mailing list.
A.2. Abridged Revision History
A.2.1. draft-ogud-dnsop-any-notimp-00
Initial draft.
A.2.2. draft-ogud-dnsop-acl-metaqueries-00
Wordsmithing; add jabley as co-author; normalise normative language
in protocol changes section.
Gudmundsson, et al. Expires September 10, 2015 [Page 5]
Internet-Draft Resticting DNS Meta-Queries March 2015
Based on feeback from dnsop mailing list, we Expaned the scope of the
document to cover "META" types in general, and express that
RCODE=NOTIMP should be cached by resolvers. Changed language so it
is more neutral to as what path this work takes.
Authors' Addresses
Olafur Gudmundsson
CloudFlare Inc.
San Francisco, CA 94107
USA
Email: olafur@cloudflare.com
Marek Majkowski
CloudFlare Inc.
London
UK
Email: marek@cloudflare.com
Joe Abley
Dyn, Inc.
103-186 Albert Street
London, ON N6A 1M1
Canada
Email: jabley@dyn.com
Gudmundsson, et al. Expires September 10, 2015 [Page 6]
