Network Working Group P. Koch
Internet-Draft DENIC eG
Intended status: Informational February 20, 2007
Expires: August 24, 2007
Identifying and Reacting to Unsolicited DNS Queries
draft-koch-dns-unsolicited-queries-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 24, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document deals with unsolicited Domain Name System (DNS) queries
directed towards authoritative name servers. It identifies reasons
for the existence of these queries and lists some observed or
proposed reactions.
Koch Expires August 24, 2007 [Page 1]
Internet-Draft Unsolicited DNS Queries February 2007
1. Introduction
Authoritative name servers should see Domain Name System (DNS)
queries only for domain names within or below zones they are
authoritative for. Responses are either positive responses
(consisting of RRSets), negative responses (either NXDOMAIN
[I-D.ietf-dnsext-2929bis] or NOERROR/NODATA) or referrals. The
latter point the querying entity towards another set of name servers
for names in delegated zones, i.e., for names "below" those zones
served authoritatively.
Operational experience shows that many larger authoritative name
servers receive a non-negligible amount of DNS queries that do not
match the above description and will be called "unsolicited DNS
queries" below. This term is not intended to have any legal meaning
or implication. Instead it should express that the usual DNS
delegation and resolution process either does not lead to those
queries or the references are unknown to and unintended by the server
operator.
This document explores different causes and properties of unsolicited
DNS queries and provides a list of reactions to those queries as seen
on the Internet. {Discussion of trade-offs needs to be intensified.}
This document primarily deals with unsolicited queries directed
towards authoritative name servers. Abusive DNS queries for
amplification or reflection attacks are described in
[I-D.ietf-dnsop-reflectors-are-evil]. Where the term "authoritative
server" is not useful per se without stating which zone(s) it refers
to, it is meant to express that the server does not offer DNS
recursion to any client. Terminology may improve in future versions
of this draft.
Comments should be directed at the author.
2. Types of Unsolicited Queries
A DNS query is identified by the trinity of QNAME, QTYPE and QCLASS.
Either of these or any combination might or might not be expected at
an authoritative name server.
QTYPE might be unexpected, but if a server is authoritative for a
certain zone in a particular class, a query for any QTYPE (except
DS [RFC4034]) is rightfully directed towards this server.
Sometimes QTYPEs do not match well known types, but a name server
must still be able to authoritatively respond for zones it serves,
as per [RFC3597].
Koch Expires August 24, 2007 [Page 2]
Internet-Draft Unsolicited DNS Queries February 2007
QCLASS is expected to be IN, the only class widely used on the
Internet. Although [RFC1123], section 6.1.2.2, restricts the use
of QCLASS=*, queries with this parameter are sometimes seen. They
can usually be answered, since "*" (or ANY) matches IN, but the AA
bit can never be set as per section 3.7.1 of [RFC1034].
QCLASS=CHAOS is also used in identification queries
[I-D.ietf-dnsop-serverid].
QNAME should fall into or below any of the zones served
authoritatively. If the QNAME is not matched by any of the zones,
it may be for an ancestor of a served zone (e.g. a query for "ORG"
to a name server serving "example.ORG"), in which case QNAME is at
least known to exist, or it may be completely unrelated to any of
the zones present.
Message types other than QUERY (Opcode 0) may also appear but are
only discussed in Appendix A.
3. Causes of Unsolicited Queries
There are various causes for unsolicited DNS queries and it might be
impossible to find and list all of them. Therefore the following
list is most likely incomplete.
3.1. Lame Delegations
Lame delegations [RFC1912] are a common operational problem. They
direct DNS queries to name servers that are meant to be authoritative
for a zone, but cannot serve it authoritatively for a variety of
reasons beyond the scope of this discussion. A lame delegation might
be due to an NS RR in the delegating zone as well as an NS RR in the
delegated zone itself.
3.2. Taking a Server for a Resolver
Enterprises and ISPs with end customers usually provide for DNS
configuration information during session initiation, by DHCP or other
protocols. Amongst those parameters are "name servers" to use by the
users' or customers' end systems. The term "name servers" is kind of
an unfortunate choice since what is really offered is the address (or
are the addresses) of full (recursive) resolvers that are able and
willing to accept and act upon the end systems' DNS queries.
Sometimes end users feel the need to circumvent the default
configuration provided as explained above and manually configure the
resolver addresses into their stub resolvers. Popular candidates are
the "name servers responsible for the Example ISP", i.e., Example's
authoritative name servers. In similar scenarios, random ISPs' or
Koch Expires August 24, 2007 [Page 3]
Internet-Draft Unsolicited DNS Queries February 2007
enterprises' authoritative name servers are selected just for being
well known or traded as being "good name servers". Following best
practice, these authoritative name servers do not offer recursion,
but will still see many unsolicited queries [RFC4697].
These queries usually have the RD bit set.
3.3. Probing
Some load balancing systems or content delivery networks try to
dynamically respond to DNS queries with A RRSets preferring the
address(es) "closest" to the requestor. Proximity tests sometimes
involve DNS queries destined either to the requesting recursive name
server or to one of the authoritative servers for the requestor's
zone (determined by reverse mapping). QNAMEs in these queries vary
between random strings and the root (".").
3.4. Configuration or Implementation Problems
Sometimes it is as simple as that: mistyped addresses in resolver
configurations or zone files misdirect traffic.
Missing checksums may let corrupt DNS queries pass undetected, which
may lead to unexpected QCLASS, QTYPE or QNAME values, amongst others.
Implementation faults or configuration errors may lead to a QCLASS of
ANY.
3.5. Debugging
Some queries will be due to debugging or research, i.e., they are
either manually initiated or generated by a debugging or surveying
script. This includes queries that are meant to check the
availability of a certain zone as well as host identification queries
[I-D.ietf-dnsop-serverid] and those used for DNS fingerprinting
[FPDNS].
3.6. Attack Traffic
DNS traffic aimed at authoritative or recursive servers or anywhere
else for the sole purpose of resource exhaustion or Denial of Service
(DoS) is out of the scope of this document.
4. Response Variants
When constructing a response to an unsolicited query, care must be
taken not to disturb the correct use of the responding server.
Koch Expires August 24, 2007 [Page 4]
Internet-Draft Unsolicited DNS Queries February 2007
Especially any kind of response should not degrade the service for
those zones the server is actively able and willing to serve. This
includes having the server marked as non-responsive or 'down'. On
the other hand it is not useful to invest too much effort into these
responses, e.g. by trying to satisfy requests for recursion or by
automatically making the server authoritative for zones that are
delegated lame.
No Response might be sent at all. This will lead to a timeout at
the resolver and may make the responsible administrator aware of
the configuration issue. Silence is also used to throttle high
volume query streams. However, this reaction may indicate to the
querying entity that the server is not available at all and thus
may degrade service for the zones served authoritatively.
DNS Error Responses often carry a DNS RCODE for "Server Failure" (2)
or "Refused" (5). In the case of QLASS other than IN, sometimes
"Not Implemented" (4) is seen as well. These responses are short
since they do not carry any RRSets [RFC2181] and may be rate
limited. However, only a stateful resolver will be able to skip
the server based on this information and some resolvers even
repeat the DNS query instantaneously.
Best Effort Responses may include "upward referrals", often
referrals for the root domain. These referrals serve no practical
purpose in that they do not constitute progress in the resolution
process. "Upward referrals" point at a higher level in the DNS
tree and can be rather huge.
Defensive Negative Responses authoritatively indicate either a name
error (RCODE 3) for QNAME or the absence of any RRSet matching
QTYPE to the querier. The SOA RR in the response usually signals
a short negative TTL [RFC2308]. The intent of these responses is
to induce errors on the side of the requestors to make them aware
of a configuration problem. This may or may not work, since a
query may be part of a chain of queries along a DNS search path,
where negative responses will just be ignored. Negative responses
might be able to throttle high volume query streams better than
other DNS error responses.
Defensive Positive Responses send back an A RR at least for QTYPE=A.
They are meant to throttle high volume query streams and usually
either point to a website that notifies of a configuration error
or to the loopback address. These responses are intrusive to a
certain extent (as are the queries triggering them) and might have
operational and legal implications. The AA bit may or may not be
set. In an attempt to override an NS RRSet in a resolver's cache,
these responses may have NS RRSets in their authority section
Koch Expires August 24, 2007 [Page 5]
Internet-Draft Unsolicited DNS Queries February 2007
pointing to unreachable name servers (to increase resolution time)
or the loopback interface (to keep traffic local to the
requestor).
All of the responses above may be sent with a delay to discourage the
further use of the server, assuming the server selection follows
section 7.2 of [RFC1034]. This may again have a negative side effect
on the service to the remaining zones on the same server.
A server might send different responses depending on whether or not
the RD bit was set in the query. However, even at an authoritative
server not all queries with RD=1 will be unsolicited. Most full
(iterative) resolvers will clear the RD bit when sending queries, but
today's DNS traffic shows that some don't.
5. Security Considerations
This document deals with unsolicited DNS queries that may lead to
resource consumption on the server side. Using wrong, unwilling or
untrusted resolvers for DNS name resolution exposes the user to the
risk of DNS spoofing. Defensive responses as described above may
lead to technical problems at the resolver side and may also have
legal implications. Defensive responses cannot be secured by Secure
DNS [RFC4033] and will lead to validation failures.
{This section needs more work.}
6. IANA Considerations
This document does not propose any new IANA registry nor does it ask
for any allocation from an existing IANA registry.
7. Acknowledgements
The author would like to thank Jaap Akkerhuis and Danny Thomas for
their review and helpful input.
8. References
8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
Koch Expires August 24, 2007 [Page 6]
Internet-Draft Unsolicited DNS Queries February 2007
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
8.2. Informative References
[FPDNS] Schlyter, J. and R. Arends, "fpdns - Fingerprinting DNS
Servers", <http://www.rfc.se/fpdns/>.
[I-D.arends-dnsext-qr-clarification]
Arends, R., "DNS Response clarification.",
draft-arends-dnsext-qr-clarification-00 (work in
progress), October 2004.
[I-D.ietf-dnsext-2929bis]
3rd, D., "Domain Name System (DNS) IANA Considerations",
draft-ietf-dnsext-2929bis-04 (work in progress),
December 2006.
[I-D.ietf-dnsop-reflectors-are-evil]
Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks",
draft-ietf-dnsop-reflectors-are-evil-03 (work in
progress), February 2007.
[I-D.ietf-dnsop-serverid]
Conrad, D. and S. Woolf, "Requirements for a Mechanism
Identifying a Name Server Instance",
draft-ietf-dnsop-serverid-08 (work in progress),
Koch Expires August 24, 2007 [Page 7]
Internet-Draft Unsolicited DNS Queries February 2007
February 2007.
[RFC0862] Postel, J., "Echo Protocol", STD 20, RFC 862, May 1983.
[RFC0864] Postel, J., "Character Generator Protocol", STD 22,
RFC 864, May 1983.
[RFC0867] Postel, J., "Daytime Protocol", STD 25, RFC 867, May 1983.
[RFC1912] Barr, D., "Common DNS Operational and Configuration
Errors", RFC 1912, February 1996.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,
November 2002.
[RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution
Misbehavior", BCP 123, RFC 4697, October 2006.
Appendix A. Non-Query DNS Messages
DNS messages are distinguished by Opcode and QR bit. DNS queries
have an Opcode of 0 and the QR bit cleared.
Responses should not be sent for messages with the QR bit set
[I-D.arends-dnsext-qr-clarification].
FORMERR or NOTIMP responses should be sent for unknown or obsoleted
Opcodes [RFC3425].
Certain UDP based services can be exploited to provide a steady back
and forth of unrecognized message and error response. If the advise
given above is followed, only services keeping the "QR bit" (MSB in
the third octet of the payload [RFC1035]) unset can be abused. This
includes, e.g., daytime [RFC0867] and chargen [RFC0864], but not the
echo protocol [RFC0862]. Some implementations rate limit error
responses to mitigate this attack.
Messages types NOTIFY and UPDATE are in wider use and will be
addressed separately:
Koch Expires August 24, 2007 [Page 8]
Internet-Draft Unsolicited DNS Queries February 2007
A.1. NOTIFY
[RFC1996] only deals with the case of NOTIFY messages received from
unknown masters. Sometimes, a receiving name server might not be
authoritative for the zone. That means the NS RR (or an explicit
configuration directive) that led to the NOTIFY message is misplaced.
In these cases sending a REFUSED response may help identifying the
problem at the source.
A.2. Dynamic Updates
Root and Toplevel Domain (TLD) name servers as well as those
authoritative for zones high in the IN-ADDR.ARPA tree see a lot of
UPDATE requests. [RFC4697].
Sections 4.5 and 4.6 of [RFC2136] describe how a conforming client is
supposed to react to the DNS response codes. SERVFAIL, NOTIMP,
silence or ICMP error messages are interpreted as a per server
failure, where REFUSED should prevent further UPDATE attempts.
Appendix B. Document Revision History
This section is to be removed should the draft be published.
B.1. Changes from -00 to -01
Expanded on Defensive Responses.
Added Probing and Attack Traffic.
Appendix A (non-query messages) added.
B.2. Initial Document
First draft
Koch Expires August 24, 2007 [Page 9]
Internet-Draft Unsolicited DNS Queries February 2007
Author's Address
Peter Koch
DENIC eG
Wiesenhuettenplatz 26
Frankfurt 60329
DE
Phone: +49 69 27235 0
Email: pk@DENIC.DE
Koch Expires August 24, 2007 [Page 10]
Internet-Draft Unsolicited DNS Queries February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Koch Expires August 24, 2007 [Page 11]