Internet DRAFT - draft-yao-dnsop-smallzone-junk-query
draft-yao-dnsop-smallzone-junk-query
dnsop J. Yao
Internet-Draft CNNIC
Intended status: Standards Track July 8, 2019
Expires: January 9, 2020
A Mechanism to Reduce the junky queries to Authoritative Name Servers
Serving Small Size Zones
draft-yao-dnsop-smallzone-junk-query-00
Abstract
Some zones are small, public and stable, but very important. They
might deal with millions of queries every day. But many of the
queries are junky. For examples, many queries DNS root servers
receive are junky. The queried junky names are not in the root, but
the root servers have to waste a lot of resources to deal with them.
It has been an obstacle to increase the performance of DNS root
query. In order to save the resource caused by the DNS junky
queries, this document proposes a new mechanism by aggressive use of
the owner name list of the DNS zone.
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 https://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 January 9, 2020.
Copyright Notice
Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Yao Expires January 9, 2020 [Page 1]
Internet-Draft root-junk-query July 2019
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 3
4. Onldigest Resource Record . . . . . . . . . . . . . . . . . . 4
5. Create the Owner Name list and Calculate the Digest . . . . . 4
6. Requirements for the resolver . . . . . . . . . . . . . . . . 5
7. Requirements for the Authoritative Name Servers . . . . . . . 5
8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . 6
11. Change History . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. draft-yao-dnsop-smallzone-junk-query: Version 00 . . . . 7
12. Normative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Some zones are small, public and stable, but very important. They
might deal with millions of queries every day. But many of the
queries are junky. For examples, many queries DNS root servers
receive are junky. The queried junky names are not in the root, but
the root servers have to waste a lot of resources to deal with them.
It has been an obstacle to increase the performance of DNS root
query.
In order to save the resource caused by the DNS junky queries, this
document proposes a new mechanism by aggressive use of the owner name
list of the DNS zone. This document proposes an owner name list of
Yao Expires January 9, 2020 [Page 2]
Internet-Draft root-junk-query July 2019
the DNS zone, and introduces a new RR type that serves as a
cryptographic message digest of the owner name list of the DNS zone.
The digest allows a receiver of the owner name list of the zone to
verify the owner name list.
2. Terminology
The basic key words such as "MUST", "MUST NOT", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "MAY", and "MAYNOT" are to be interpreted as
described in [RFC2119] [RFC8174].
The basic DNS terms used in this specification are defined in the
documents [RFC1034] and [RFC1035].
3. Design Overview
This document introduces a new mechanism which uses the owner name
list of a zone to produce the negative response. When the resolver
receives the query for the specific zone, it checks its owner name
list of that zone before doing further query. If the name queried is
in the owner name list, it will be sent to that zone for furhter
query; otherwise, the responder will generate the negative response
if it is not in the owner name list. This document introduces a new
Resource Record type designed to convey a message digest of the owner
name list of a zone. The digest is calculated at the time of zone
publication. Ideally the zone is signed with DNSSEC to guarantee
that any modifications of the digest can be detected. The procedures
for digest calculation and DNSSEC signing are similar, which require
the similar ordering of RRs. Many small zones'owner name list keeps
stable, although the DNS RR's type or RDATA may change day by day.
The mechanism is designed to be used on zones that are relatively
stable and have infrequent updates. As currently specified, the
digest is re-calculated over the entire zone when the owner names are
updated. It is expected that verification of digest of owner name
list of a zone would be implemented in name servers and the
resolvers. That is, a name server can verify the zone owner name
list it was given and refuse to serve a zone which fails
verification; a resolver can verify the zone owner name list it was
given and refuse to serve a zone owner name list which fails
verification. For signed zones, the name server needs a trust anchor
to perform DNSSEC validation. A server for a specifical zone can
publish the owner name list or the full zone. A resolver can get the
owner name list for a specifical zone or get the full zone and create
the owner name list for this zone according to the rules set by this
document.
The goal of our design is that the junk-queried names can be
recognized as soon as possible before sending to the specifized zone.
Yao Expires January 9, 2020 [Page 3]
Internet-Draft root-junk-query July 2019
The mechanism proposed by this dcoument will decrease the work load
of authoritative name servers serving the specific zone efficently.
4. Onldigest Resource Record
This record is designed for the cryptographic message digest of the
owner name list of the DNS zone. The Onldigest RDATA wire format is
encoded as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest Type | |
+-+-+-+-+-+-+-+-+ |
| Digest |
/ /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Onldigest RDATA Wire Format
o The Digest Type field is an 8-bit unsigned integer that identifies
the algorithm used to construct the digest.
o The Digest field is a variable-length sequence of octets
containing the message digest. The Digest field MUST NOT be
empty.
5. Create the Owner Name list and Calculate the Digest
The owner name list digest is calculated by concatenating the
canonical on-the- wire form (without name compression) of all RRs in
the zone, and then applying the digest algorithm. Some rules are:
o All of owner names of RRs with NS type should be prefixed with
"*." before putting into the owner name list. It means that if
example.com has NS type, the owner name will become
"*.example.com".
o For ordering of owner names in the zone, this document adopts
DNSSEC's canonical ordering for names (Section 6.1 of [RFC4034]),
o It is meaningless for an owner name list to have multiple same
owner names. In the interest of consistency and interoperability,
such duplicate owner names MUST NOT be included in the owner name
list.
Yao Expires January 9, 2020 [Page 4]
Internet-Draft root-junk-query July 2019
o All other owner names which are not descendants of the zone apex
name, including glue records, MUST not be included.
The owner name list Should have the following format:
o owner-name-list = RR(1); | RR(2);| RR(3); | ...
o digest = digest_algorithm( owner-name-list )
o where "|" denotes concatenation, and ";" is an added separator.
6. Requirements for the resolver
In order to implement the mechanism described in this document:
o The resolver should get the owner name list for a specific zone
either in band or out of band. It can also get a full zone and
create the owner name list for a specific zone.
o The resolver should verify the zone owner name list using the
Onldigest record.
o The resolver should refresh the Onldigest record befor it expires.
When the Onldigest record's Digest field is updated, it means that
the owner name list was updated and the resolve should get a new
one.
o For a non DNSSEC query, if the queried name is not on the owner
name list for the specifical zone, it means that that name is not
on that zone or its sub-zone and the resolver can create a none
existent name response to the query.
o For a DNSSEC query, if the queried name is not on the owner name
list for the specifical zone, it means that that name is not on
that zone or its sub-zone and the resolver can create a none
existent name response to the query. The resolver can verify the
Onldigest record's relative RRSIG and the owner name list with the
Onldigest record. If it is successful, it can be regarded as the
DNSSEC verification.
7. Requirements for the Authoritative Name Servers
In order to reduce the workload and get the faster response, the
Authoritative Name Servers may choose the similar strategies adopted
by the resolvers. For a non DNSSEC query, if the queried name is not
on the owner name list for the specifical zone, it means that that
name is not on that zone or its sub-zone and the servers can create a
none existent name response to the query. For a DNSSEC query, if the
Yao Expires January 9, 2020 [Page 5]
Internet-Draft root-junk-query July 2019
queried name is not on the owner name list for the specifical zone,
the servers need to find the NSEC or NSEC3 records before responding.
8. Use Cases
The mechanism proposed in this document has the following use cases
(you can help to add more):
o Root Zone: The root zone are small, public and stable where the
owner name are not likely to be changed for a long time.
o Important Companies' zone: These company's zones are small and
where the owner name are not likely to be changed for a period of
time. For examples, CNNIC's owner name list for cnnic.cn are kept
stable for a long time. But sometimes, the attacker may choose
name server serving cnnic.cn zone for random name DDOS attack.
CNNIC also runs a resolver which can be configured to use this
mechanism to help to deduce the flooding to the CNNIC's
authoritative name server.
o Public DNS Resolver: The public DNS resolver can provide the
value-added service to some specific companies' zone. Some online
company may choose to coporate with some public DNS resolvers to
reduce the possible DDOS attack to their companies' authoritative
name servers.
9. IANA Considerations
This document defines a new DNS RR type, Onldigest, whose value **
has been allocated by IANA from the "Resource Record (RR) TYPEs"
subregistry of the "Domain Name System (DNS) Parameters" registry:
Type: Onldigest
Value: **
Meaning: Owner name list digest
Reference: This document
10. Security Considerations
The mechansime designed in this document is useful for small, public
and stable zone, where owner names are likely to kept stable. It is
not useful for big, private and dynamic zone, where owner names are
too many or likely to kept dynamical.
Yao Expires January 9, 2020 [Page 6]
Internet-Draft root-junk-query July 2019
The resolver needs to know the owner name list via the public zones
or the one published by the zone owners.
11. Change History
RFC Editor: Please remove this section.
11.1. draft-yao-dnsop-smallzone-junk-query: Version 00
o Help to reduce the workload of junk-query to the authoritative
name servers.
12. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
Yao Expires January 9, 2020 [Page 7]
Internet-Draft root-junk-query July 2019
Author's Address
Jiankang Yao
CNNIC
4 South 4th Street,Zhongguancun,Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3007
Email: yaojk@cnnic.cn
Yao Expires January 9, 2020 [Page 8]
