| Internet-Draft | DNS in Isolated Networks | November 2024 |
| Blanchet | Expires 7 May 2025 | [Page] |
This document lists operational methods to enable local DNS name resolving on an isolated network, where that network have intermittent reachability to Internet and/or have very long delays, such as deep space networks, disabling the real-time query and response flow to the authoritative name servers on Internet.¶
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 7 May 2025.¶
Copyright (c) 2024 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Deep space communications involve long delays (e.g. Earth to Mars is 4-20 minutes) and intermittent communications, because of orbital dynamics. [I-D.many-deepspace-ip-assessment] discusses the use of the whole IP stack in this context. Domain name requests and response over long delays generate timeouts and when there is no reachability to the DNS server, requests will not be answered. Therefore, on celestial bodies IP networks, a local DNS infrastructure with all the needed names and values stored locally is needed. Moreover, to keep the same DNS root and the current DNSSEC trust chain, all keys necessary for validation should also be stored locally. This document describes the different ways to accomplish this.¶
While this document uses deep space as the base use case, it applies to other "mostly" isolated networks. Mostly isolated means that most of the time the network is isolated, but there are times where it is not isolated and then may receive zone transfers or other means to populate or update its name caches. In case of deep space, the delays for those transfers is significant and the transport mechanisms are more limited, as discussed in [I-D.many-deepspace-ip-assessment].¶
The requirements and characteristics for this document use case are:¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This section presents various approaches that should meet the requirements set in the previous section. These approaches use the [RFC8806] approach for root zones, but augment it for the whole needed name hierarchy.¶
All approaches share similar naming infrastructure on the target isolated network:¶
If one assumes that all names that will be used on the isolated network are known in advance, then queries walking the tree from the root down to the final name of all needed names can be done on Internet and the responses saved in a file, together with the appropriate DNSSEC records (TBD: should we list those: aka RRSIG, DS, DNSKEY). The records should contain values that are relevant to the isolated network. For example, an IP address record such as an A or AAAA record should resolve to an IP address relevant and reachable on the target isolated network.¶
The resulting file containing all the records is uploaded to the authoritative name servers on the isolated network.¶
This method somewhat mimics the hosts.txt file used before the DNS was created.¶
The authoritative name servers should serve the root zone and all required domain tree records underneath as found above.¶
If a name used on the isolated network by the hosts or applications is not in the uploaded file served by the local name servers, then the request will leak and will timeout since the request will not reach the Internet DNS infrastructure.¶
If all needed DNSSEC material is not fully uploaded, then DNSSEC validation will fail.¶
A method for syncing and updating all the updated records to the isolated network should be put in place, at the appropriate frequency. It could be done using zone tranfer mechanism if TCP/IP reachability is possible but other file transfer mechanisms may also be used.¶
Some DNS records have values containing other names, such as the SRV and CNAME records. The referenced names should also be "walked".¶
This setup somewhat assumes that there is a single operator for the DNS authoritative infrastructure on the target isolated network.¶
If one assumes that the name hierarchy is known for all needed names used on the isolated network and if the operator of the DNS infrastructure on the isolated network has access to all the zones of the hierarchy, then these zones are saved. They may need to be modified so that the NS glue records point to the appropriate local authoritative name servers. These zones are then uploaded to the authoritative name servers on the isolated network.¶
The authoritative name servers should serve the root zone and all zones as discussed above.¶
This approach have less risk of missing a name since all names under the hierarchy are uploaded. However, if the zones are too big compared to the transfer capacity to the isolated network, then this solution is not appropriate. Moreover, it may be possible that most of the names in the uploaded zones will not be used, therefore it is a possible waste of resources (bandwidth, memory/cpu on server, ...). Therefore, careful consideration on the chosen hierarchy, specially the top-level domain, is relevant. Given deep space relative limited use networks, it would make sense to dedicate some top-level domain or subdomain for its needs. However, it is possible to remove all the non-needed recoard from the zones before uploading them to the isolated network DNS infrastructure, but then if some names are missing in this removal, the same issues from the previous approach appear.¶
If all needed DNSSEC material is not fully uploaded, then DNSSEC validation will fail.¶
A method for syncing and updating all the updated records to the isolated network should be put in place, at the appropriate frequency. It could be done using zone tranfer mechanism if TCP/IP reachability is possible but other file transfer mechanisms may also be used.¶
In the context of multiple operators on the target network, each one may do this process independently for its own zones, without having to rely on another party.¶
Instead of fetching a whole zone containing a lot of non useful records, the manager of that zone creates a special version of the zone containing only the useful records and sign it. It is then sent to the isolated network DNS infrastructure. This approach is a combination of the previous approaches, but require careful management of the two versions of the zone. In terms of deployment and operations, it has the same properties as the zone pre-fetch approach.¶
If DNS zone transfer is possible over the link between the Internet and the isolated network, then incremental zone transfer (aka IXFR) might be advised to minimize the use of the bandwidth and also minimize the data merge on the target DNS server.¶
If DNS zone transfer is not possible or not optimal, than various file transfer mechanisms such as FTP, ssh, git, rsync may be used.¶
Zones are signed at various frequencies based on the operator policies. If a signature on a record has expired, then DNSSEC validation will fail. Therefore, the frequency of uploading updated records should be higher than the frequency of the signing of the uploaded zones.¶
Similarly, the key lifetimes, including the root zone anchor, should be monitored to make sure that new keys are uploaded before the old ones expire.¶
Finally, the DNSSEC RR TTL values need to be longer than the update times.¶
Even with careful management, there is some probability that some applications or host on the isolated network will query names that were uploaded to the local DNS infrastructure, but refer to services or IP addresses that are not reachable from the isolated network. If the isolated network do have intermittent IP connectivity to Internet but the link is not appropriate for live queries, such as long delays in deep space, costly bandwidth or very small time window of reachability, then the network may try to route the packets to the Internet. Therefore, a default route pointing to null or other mechanisms to signal unreachability may be appropriate to be setup at the edge of the isolated network.¶
This memo includes no request to IANA.¶
By expanding the use of the same Internet DNS root to space, the space IP network naming infrastructure is then secured at the same level as on Internet.¶
The idea of the pre-walk was suggested by Warren Kumari. The idea of a special zone was suggested by Mark Andrews. All errors are authors'.¶