draft-ietf-dnsop-7706bis-11.txt   draft-ietf-dnsop-7706bis-12.txt 
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Obsoletes: 7706 (if approved) P. Hoffman Obsoletes: 7706 (if approved) P. Hoffman
Intended status: Informational ICANN Intended status: Informational ICANN
Expires: September 13, 2020 March 12, 2020 Expires: September 14, 2020 March 13, 2020
Running a Root Server Local to a Resolver Running a Root Server Local to a Resolver
draft-ietf-dnsop-7706bis-11 draft-ietf-dnsop-7706bis-12
Abstract Abstract
Some DNS recursive resolvers have longer-than-desired round-trip Some DNS recursive resolvers have longer-than-desired round-trip
times to the closest DNS root server; those resolvers may have times to the closest DNS root server; those resolvers may have
difficulty getting responses from the root servers, such as during a difficulty getting responses from the root servers, such as during a
network attack. Some DNS recursive resolver operators want to network attack. Some DNS recursive resolver operators want to
prevent snooping by third parties of requests sent to DNS root prevent snooping by third parties of requests sent to DNS root
servers. Such resolvers can greatly decrease the round-trip time and servers. In both cases, resolvers can greatly decrease the round-
prevent observation of requests by serving a copy of the full root trip time and prevent observation of requests by serving a copy of
zone on the same server, such as on a loopback address or in the the full root zone on the same server, such as on a loopback address
resolver software. This document shows how to start and maintain or in the resolver software. This document shows how to start and
such a copy of the root zone that does not cause problems for other maintain such a copy of the root zone that does not cause problems
users of the DNS, at the cost of adding some operational fragility for other users of the DNS, at the cost of adding some operational
for the operator. fragility for the operator.
This document obsoletes RFC 7706. This document obsoletes RFC 7706.
[ This document is being collaborated on in Github at: [ This document is being collaborated on in Github at:
https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent
version of the document, open issues, and so on should all be version of the document, open issues, and so on should all be
available there. The authors gratefully accept pull requests. ] available there. The authors gratefully accept pull requests. ]
Status of This Memo Status of This Memo
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 13, 2020. This Internet-Draft will expire on September 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 20 skipping to change at page 6, line 20
the SOA record in the root zone, as described in [RFC1035]. This the SOA record in the root zone, as described in [RFC1035]. This
inherently means that the contents of the local root zone will likely inherently means that the contents of the local root zone will likely
be a little behind those of the global root servers because those be a little behind those of the global root servers because those
servers are updated when triggered by NOTIFY messages. servers are updated when triggered by NOTIFY messages.
There is a risk that a system using a local authoritative server for There is a risk that a system using a local authoritative server for
the root zone cannot refresh the contents of the root zone before the the root zone cannot refresh the contents of the root zone before the
expire time in the SOA. A system using a local authoritative server expire time in the SOA. A system using a local authoritative server
for the root zone MUST NOT serve stale data for the root zone. To for the root zone MUST NOT serve stale data for the root zone. To
mitigate the risk that stale data is served, the local root server mitigate the risk that stale data is served, the local root server
MUST immediately switch to using non-local root servers. MUST immediately switch to using non-local root servers when it
detects that it would be serving state data.
In a resolver that is using an internal service for the root zone, if In a resolver that is using an internal service for the root zone, if
the contents of the root zone cannot be refreshed before the expire the contents of the root zone cannot be refreshed before the expire
time in the SOA, the resolver MUST immediately switch to using non- time in the SOA, the resolver MUST immediately switch to using non-
local root servers. local root servers.
In the event that refreshing the contents of the root zone fails, the In the event that refreshing the contents of the root zone fails, the
results can be disastrous. For example, sometimes all the NS records results can be disastrous. For example, sometimes all the NS records
for a TLD are changed in a short period of time (such as 2 days); if for a TLD are changed in a short period of time (such as 2 days); if
the refreshing of the local root zone is broken during that time, the the refreshing of the local root zone is broken during that time, the
skipping to change at page 7, line 7 skipping to change at page 7, line 7
4. Security Considerations 4. Security Considerations
A system that does not follow the DNSSEC-related requirements given A system that does not follow the DNSSEC-related requirements given
in Section 2 can be fooled into giving bad responses in the same way in Section 2 can be fooled into giving bad responses in the same way
as any recursive resolver that does not do DNSSEC validation on as any recursive resolver that does not do DNSSEC validation on
responses from a remote root server. Anyone deploying the method responses from a remote root server. Anyone deploying the method
described in this document should be familiar with the operational described in this document should be familiar with the operational
benefits and costs of deploying DNSSEC [RFC4033]. benefits and costs of deploying DNSSEC [RFC4033].
As stated in Section 1, this design explicitly allows the local copy As stated in Section 1, this design explicitly requires the local
of the root zone information to be available only from resolvers on copy of the root zone information to be available only from resolvers
that host. This has the security property of limiting damage to on that host. This has the security property of limiting damage to
clients of any local resolver that might try to rely on an altered clients of any local resolver that might try to rely on an altered
copy of the root. copy of the root.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. References 6. References
6.1. Normative References 6.1. Normative References
 End of changes. 6 change blocks. 
14 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/