Internet DRAFT - draft-fujiwara-dnsop-resolver-update
draft-fujiwara-dnsop-resolver-update
Network Working Group K. Fujiwara
Internet-Draft JPRS
Updates: 1034, 2181 (if approved) November 01, 2016
Intended status: Standards Track
Expires: May 5, 2017
Updating Resolver Algorithm
draft-fujiwara-dnsop-resolver-update-00
Abstract
Parent side NS RRSet and glue records are all information to access
servers for child zone. However, they may be overwritten by child
zone data (zone apex NS RRSet and other A/AAAA RRSets). The
overwrite makes name resolution unstable and induces vulnerabilities.
RFC 2181 section 5.4.1 specifies trustworthiness of DNS data. And it
is deemed that that all cached data (authoritative data, non-
authoritative data, referrals and glue records) are merged into one.
Resolvers may answer non-authoritative data, referrals and glue
records that should not be returned. This document proposes updating
resolver algorithm that separates the cache to "authoritative data
cache" and "delegation cache". The former is used to answer stub
resolvers, and the latter is used to iterate zones.
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 May 5, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Fujiwara Expires May 5, 2017 [Page 1]
Internet-Draft resolver-clarification November 2016
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Traditional resolver algorithm . . . . . . . . . . . . . . . 3
3.1. Importance of parent side NS RRSet . . . . . . . . . . . 3
3.2. Recommendation of resolver's answer . . . . . . . . . . . 4
3.3. Traditional resolver algorithm . . . . . . . . . . . . . 5
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. Updating of Resolver Algorithm . . . . . . . . . . . . . . . 6
5.1. Recommendations to resolvers . . . . . . . . . . . . . . 6
5.2. Update to resolver algorithm . . . . . . . . . . . . . . 6
5.3. Characteristics of the update . . . . . . . . . . . . . . 7
5.4. Issues of the update . . . . . . . . . . . . . . . . . . 8
6. Implementation Ideas . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
10. Change History . . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Resolver algorithm is defined in [RFC1034] and updated by [RFC2181].
The resolver algorithm seems to assume single cache that holds all
RRSets from received responses. [RFC2181] Section 5.4.1 Ranking data
specifies the trustworthiness order of RRSets. When a resolver
receives higher trustworthy data, the cached data is replaced by the
received data.
Parent side NS RRSet is very important because it creates new zone
and specifies how to access name servers for the created zone
described in Section 3.1. However, parent side NS RRSets and glue
records have least trustworthiness. The parent side NS RRSets and
Fujiwara Expires May 5, 2017 [Page 2]
Internet-Draft resolver-clarification November 2016
glue records are replaced by authoritative data if resolvers receive
authoritative data described in Section 3.3.
The overwrite makes name resolution unstable and some vulnerabilities
described in Section 4. And it may break requirements of resolvers'
answers described in Section 3.2.
This document proposes updated resolver algorithm that separate
authoritative data cache that is answered to stub resolvers and
delegation cache that is used to iterate zones. Details are
described in Section 5
2. Terminology
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 RFC 2119 [RFC2119].
Many of the specialized terms used in this specification are defined
in DNS Terminology [RFC7719].
3. Traditional resolver algorithm
[RFC1034] defines "zone cut", "delegation", "referral", "glue
records", "authoritative", and "resolver algorithm".
[RFC2181] clarified the resolver algorithm defined in [RFC1034].
3.1. Importance of parent side NS RRSet
[RFC1034], [RFC2181] and [RFC7719] defines zone "cut", "delegation",
"referral", and parent side NS RRSet functions as follows.
"'cuts' in the name space can be made between any two adjacent nodes.
After all cuts are made, each group of connected name space is a
separate zone. The zone is said to be authoritative for all names in
the connected region." (Quoted from RFC 1034, Section 4.2)
"The RRs that describe cuts around the bottom of the zone are NS RRs
that name the servers for the subzones. Since the cuts are between
nodes, these RRs are NOT part of the authoritative data of the zone,
and should be exactly the same as the corresponding RRs in the top
node of the subzone." (Quoted from RFC 1034, section 4.2.1)
"That is, parent zones have all the information needed to access
servers for their children zones." (Quoted from RFC 1034, section
4.2.1)
Fujiwara Expires May 5, 2017 [Page 3]
Internet-Draft resolver-clarification November 2016
"Resolvers must be able to access at least one name server and use
that name server's information to answer a query directly, or pursue
the query using referrals to other name servers." (Quoted from RFC
1034, Section 2.4)
"Delegation is the process by which a separate zone is created in the
name space beneath the apex of a given domain. Delegation happens
when an NS RRset is added in the parent zone for the child origin."
(Quoted from RFC 7719)
"This situation typically occurs when the glue address RRs have a
smaller TTL than the NS RRs marking delegation," (Quoted from RFC
1035, Section 7.2)
"The existence of a zone cut is indicated in the parent zone by the
existence of NS records specifying the origin of the child zone."
(Quoted from RFC 2181, Section 6)
As described above, parent side NS RRSet makes a new zone. Parent
side NS RRSet (referral) and glue records are all the information to
access servers for the child zone.
That is, resolvers SHOULD NOT use child side NS RRSet to iterate
zones.
3.2. Recommendation of resolver's answer
RFC 1034 describes resolver's answer as follows.
"The ideal answer is one from a server authoritative for the query
which either gives the required data or a name error. The data is
passed back to the user and entered in the cache for future use if
its TTL is greater than zero." (Quoted from RFC 1034, Section 5.3.3)
"The simplest mode for the client is recursive, since in this mode
the name server acts in the role of a resolver and returns either an
error or the answer, but never referrals." (Quoted from RFC 1034,
Section 4.3.1)
Recently, most of full-service resolver implementations answer only
authoritative data to stub resolvers.
As described above, recommendation of resolver's answer is "answer
only authoritative data." It does not break existing standards.
Fujiwara Expires May 5, 2017 [Page 4]
Internet-Draft resolver-clarification November 2016
3.3. Traditional resolver algorithm
Resolver algorithm is defined in [RFC1034] Section 5.3.3. Resolvers
cache all RRSets during the iterations in their cache. When
resolvers receive new data, they will update their cache. The update
is explained using an example resolution of "www.example.com/A" in
"example.com" zone as follows.
When a resolver iterates "www.example.com/A" query, then one of root
servers responds "com" NS RRSet (referral) with glue records, one of
"com" servers responds "example.com" NS RRSet with glue records, and
one of "example.com" servers responds "www.example.com" A RRSet.
As a result, the resolver caches all RRSets during the iterations in
its cache.
After then, a resolver receives "example.com/NS" query, it retrieves
"example.com" NS authoritative data defined in zone apex of
"example.com" and it overwrites "example.com/NS" in the resolver's
cache as "trustworthiness" rule of [RFC2181].
If the parent side "example.com" NS RRSet and the child side
"example.com" NS RRSet are different, next resolution result will be
changed because the resolver will send "www.example.com/A" query to
name servers that are specified by "example.com" NS RRSet defined in
zone apex. Glue records in the cache are also overwritten by
authoritative data, and then, IP addresses of name servers that the
resolver send to will be changed.
The other case, if one of "example.com" name servers responds
"www.example.com" A RRSet with "example.com" NS RRSet in authority
section (several existing authoritative server implementations
perform this) , "example.com" NS RRSet from "com" TLD servers
(referral) is overwritten by "example.com" NS data attached in the
authoritative answer from child zone.
The overwrite is specified by [RFC2181] Section 5.4.1 Ranking data.
"Referrals" is the ranking 7: "Data from the authority section of a
non-authoritative answer". And "example.com" NS RRSet attached in
the authoritative answer is the ranking 4: "Data from the authority
section of an authoritative answer".
4. Problem Statement
[RFC1034] section 4.2.1 states that "the parent side NS RRSet should
be exactly the same as the corresponding RRs in the top node of the
subzone".
Fujiwara Expires May 5, 2017 [Page 5]
Internet-Draft resolver-clarification November 2016
However, people sets different NS RRSets with mistakes, or
intentionally. Name server configuration changes will make the
differences because the changes take time.
If the zone data of name server(s) specified by referrals and
specified by zone apex NS RRSet are different, name resolution
becomes unstable. The cache overwrite of NS RRSet may break
"Referrals and glue records are information to access servers for
child zones" specified by [RFC1034] section 4.2.1.
The overwrite by zone apex NS RRSet induced security vulnerabilities.
In 2012, "Ghost Domain Names: Revoked Yet Still Resolvable"
[DUAN2012GHOST] was reported. The attack uses updates of NS RRSet
attached in authoritative answer. Assume a resolver caches and uses
zone apex NS RRSet, and the parent side NS RRSet is updated or
removed. The resolver send queries to name servers specified by zone
apex NS RRSet and update NS RRSet by the NS RRSet attached in the
authority section of the answer. Parent side NS RRSet specifies the
existence of delegation, however, resolvers may not check the
existence of the parent side NS RRSet and the domain name will remain
in the resolvers.
DNS software vendors fixed the problem to restrict the TTL of NS
RRSet not to exceed the cached TTL value of old NS RRSet when
replacing it.
5. Updating of Resolver Algorithm
5.1. Recommendations to resolvers
Resolvers MUST answer one of the following results: required data,
name error, or empty (NODATA) from a server that is authoritative for
the query, other name resolution errors (SERVFAIL, REFUSED), or no
answer.
Resolvers iterate queries using referrals with corresponding glue
records to other name servers. If referrals contain out-of-bailiwick
name server names, resolvers need to resolve address records of out-
of-bailiwick name servers.
Resolvers MUST NOT use glue records and referrals except iterating
delegations. Resolvers MUST NOT use zone apex NS RRSets to iterate.
5.2. Update to resolver algorithm
This document update RFC 1034 Section 5.3.3. Algorithm as follows.
Fujiwara Expires May 5, 2017 [Page 6]
Internet-Draft resolver-clarification November 2016
Separate the cache into "authoritative data cache" and "delegation
cache". Pre-load root hint information (root NS RRSet and root
server addresses) into the delegation cache.
"Step 4.a." is changed as "if the response answers the question or
contains a name error, cache the data into authoritative cache as
well as returning it back to the client".
"Step 4.b." is changed as if the response contains a better
delegation to other servers, cache the delegation information into
delegation cache, and go to step 2".
The cache in "Step 1" is the authoritative data cache.
The cache used in "step 2" is the delegation cache. "Set up their
addresses using local data" is replaced as "Set up their addresses
using the delegation cache".
As a result, RFC 2181 Section 5.4.1 Ranking data becomes useless
because the overwrite will not happen. Pre-loaded zone files (or
zones retrieved from zone transfer) are treated as answers from
authoritative servers. They are treated as static authoritative
data, referrals, and glue records. Referrals and glue records in
pre-loaded zone files MUST NOT be answered to stub resolvers. They
MUST be used to iterate name servers only.
Root zone is special because it is not delegated. Root hint and
priming are exceptions because priming replaces pre-configured root
hint by root zone apex NS RRSet (authoritative data).
5.3. Characteristics of the update
This update does not change resolver algorithm described in RFC 1034
section 5.3.3, except updates of referrals. It separates
authoritative data (possible to answer) and referrals (used to
iterate DNS tree). It does not require no special ordering (e.g.
trustworthiness and ranking data). It offers more stability of name
resolution because the results of traditional name resolution will
flap if NS RRSets between the parent and the child are different.
This algorithm is similar to traditional algorithm when the cache is
empty.
The update does not effect to DNSSEC [RFC4033] [RFC4034] [RFC4035]
because DNSSEC validates authoritative data and does not validate
referrals.
Fujiwara Expires May 5, 2017 [Page 7]
Internet-Draft resolver-clarification November 2016
The update does not effect to DNS Query Name Minimisation [RFC7816]
because answers from authoritative servers don't change. Delegation
cache and authoritative data cache separation will need small
implementation changes.
5.4. Issues of the update
This update makes impossible to control of TTL value of NS RRSet by
the child zone owner. However, overwrite of the referral does not
occur always and TTL control may increase queries to authoritative
servers.
6. Implementation Ideas
Some implementers already implemented similar algorithm to their
products.
7. IANA Considerations
{#:ianacons}
This document has no IANA actions.
8. Security Considerations
9. Acknowledgments
10. Change History
11. References
11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<http://www.rfc-editor.org/info/rfc2181>.
Fujiwara Expires May 5, 2017 [Page 8]
Internet-Draft resolver-clarification November 2016
[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,
<http://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,
<http://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,
<http://www.rfc-editor.org/info/rfc4035>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>.
11.2. Informative References
[DUAN2012GHOST]
D, H., Jiang, J., Liang, J., Li, K., Li, J., and J. Wu,
"Ghost domain names:Revoked yet still resolvable", 2012,
<The 19th Annual Network & Distributed System Security
Symposium (NDSS 2012)>.
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
<http://www.rfc-editor.org/info/rfc7816>.
Author's Address
Kazunori Fujiwara
Japan Registry Services Co., Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065
Japan
Phone: +81 3 5215 8451
Email: fujiwara@jprs.co.jp
Fujiwara Expires May 5, 2017 [Page 9]