< draft-ietf-dnsop-7706bis-08.txt   draft-ietf-dnsop-7706bis-09.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 2, 2020 March 1, 2020 Expires: September 3, 2020 March 2, 2020
Running a Root Server Local to a Resolver Running a Root Server Local to a Resolver
draft-ietf-dnsop-7706bis-08 draft-ietf-dnsop-7706bis-09
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 such as during a network attack. times to the closest DNS root server; those resolvers may have
Some DNS recursive resolver operators want to prevent snooping by difficulty getting responses from the root servers, such as during a
third parties of requests sent to DNS root servers. Such resolvers network attack. Some DNS recursive resolver operators want to
can greatly decrease the round-trip time and prevent observation of prevent snooping by third parties of requests sent to DNS root
requests by serving a copy of the full root zone on the same server, servers. Such resolvers can greatly decrease the round-trip time and
such as on a loopback address or in the resolver software. This prevent observation of requests by serving a copy of the full root
document shows how to start and maintain such a copy of the root zone zone on the same server, such as on a loopback address or in the
that does not cause problems for other users of the DNS, at the cost resolver software. This document shows how to start and maintain
of adding some operational fragility for the operator. such a copy of the root zone that does not cause problems for other
users of the DNS, at the cost of adding some operational 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 47 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 2, 2020. This Internet-Draft will expire on September 3, 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 3, line 29 skipping to change at page 3, line 29
the TTL for negative answers from the root servers. (Although the the TTL for negative answers from the root servers. (Although the
primary goal of the design is for serving the root zone, the method primary goal of the design is for serving the root zone, the method
can be used for any zone.) can be used for any zone.)
This document describes a method for the operator of a recursive This document describes a method for the operator of a recursive
resolver to have a complete root zone locally, and to hide queries resolver to have a complete root zone locally, and to hide queries
for the root zone from outsiders. The basic idea is to create an up- for the root zone from outsiders. The basic idea is to create an up-
to-date root zone service on the same host as the recursive server, to-date root zone service on the same host as the recursive server,
and use that service when the recursive resolver looks up root and use that service when the recursive resolver looks up root
information. The recursive resolver validates all responses from the information. The recursive resolver validates all responses from the
root service on the same host, just as it would all validate root service on the same host, just as it would validate all
responses from a remote root server. responses from a remote root server.
This design explicitly only allows the new root zone service to be This design explicitly only allows the new root zone service to be
run on the same server as the recursive resolver, in order to prevent run on the same server as the recursive resolver, in order to prevent
the server from serving authoritative answers to any other system. the server from serving authoritative answers to any other system.
Specifically, the root service on the local system MUST be configured Specifically, the root service on the local system MUST be configured
to only answer queries from resolvers on the same host, and MUST NOT to only answer queries from resolvers on the same host, and MUST NOT
answer queries from any other resolver. answer queries from any other resolver.
At the time that RFC 7706 [RFC7706] was published, it was considered At the time that RFC 7706 [RFC7706] was published, it was considered
skipping to change at page 5, line 14 skipping to change at page 5, line 14
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Requirements 2. Requirements
In order to implement the mechanism described in this document: In order to implement the mechanism described in this document:
o The system MUST be able to validate every signed record in a zone o The system MUST be able to validate every signed record in a zone
with DNSSEC [RFC4033]. with DNSSEC [RFC4033].
o The system MUST have an up-to-date copy of the Key Signing Key o The system MUST have an up-to-date copy of the public part of the
(KSK) [RFC4033] used to sign the DNS root. Key Signing Key (KSK) [RFC4033] used to sign the DNS root.
o The system MUST be able to retrieve a copy of the entire root zone o The system MUST be able to retrieve a copy of the entire root zone
(including all DNSSEC-related records). (including all DNSSEC-related records).
o The system MUST be able to run an authoritative service for the o The system MUST be able to run an authoritative service for the
root zone on the same host. The authoritative root service MUST root zone on the same host. The authoritative root service MUST
only respond to queries from the same host. One way to assure not only respond to queries from the same host. One way to assure not
responding to queries from other hosts is to run an authoritative responding to queries from other hosts is to run an authoritative
server for the root that responds only on one of the loopback server for the root that responds only on one of the loopback
addresses (that is, an address in the range 127/8 for IPv4 or ::1 addresses (that is, an address in the range 127/8 for IPv4 or ::1
 End of changes. 6 change blocks. 
15 lines changed or deleted 17 lines changed or added

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