| Internet-Draft | DNS in Deep Space | July 2025 |
| Blanchet | Expires 2 January 2026 | [Page] |
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. This document lists operational methods to enable local DNS name resolving on celestial body networks such that there are no real-time query and response flow to the authoritative name servers on (Earth) 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 2 January 2026.¶
Copyright (c) 2025 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 has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. To illustrate a simple example of intermittence, communications may be between a ground station on Earth to an asset on a planet through the use of an orbiter around that planet. That orbiter may have an overpass of 20 minutes every 2 hours. Therefore, continuous connectivity between the two endpoints cannot be assumed. However, as discussed in [I-D.many-tiptop-ip-architecture], orbiters may temporarily store IP packets until the next communication window with the next hop appears. From the standpoint of the transport or upper application protocols, the one-way delay and the RTT will be stable while direct connectivity happens, and then jump to a large value while the orbiter is not reachable anymore, until it becomes reachable again. In some cases, where the asset is on a shadow side of a planet or Moon and while there is no full constellation of orbiters providing connectivity all around, the asset and Earth ground may never or rarely have a uninterrupted end2end path. [I-D.many-tiptop-usecase] provides more details about key characteristics of deep space communications and the use case of networking.¶
[I-D.many-tiptop-ip-architecture] 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.¶
While this document uses deep space as the base use case, it may apply to other "mostly" isolated networks, such as IoT 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.¶
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.¶
Given all the investment in technology, protocol, services, infrastructure, scrutiny and governance in place, the ability to use the current Internet DNS Root with DNSSEC even in deep space has a lot of merit compared to starting another root with another trust chain. In order to achive that goal, which is to keep the same DNS root and the current DNSSEC trust chain in deep space, domain data and all related keys necessary for local validation should also be stored locally.¶
The requirements and characteristics for this document use case are:¶
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 celestial body network:¶
"Target network" used in this document means the celestial body network.¶
If one assumes that all names that will be used on the target 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 celestial body 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 network.¶
The resulting file containing all the records is uploaded to the authoritative name servers on the target network.¶
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 celestial body network by the hosts or applications is not in the uploaded file served by the local name servers, then the request will timeout.¶
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. Typical DNS zone tranfer mechanism may not be suitable because TCP transport is likely not possible in deep space. In this case, other file transfer mechanisms may 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 network.¶
If one assumes that the name hierarchy is known for all needed names used on the target network and if the operator of the DNS infrastructure on the target 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 target network.¶
The authoritative name servers should serve the root zone and all zones 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 target 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 record from the zones before uploading them to the target network DNS infrastructure, but then if some names are missing in this removal, the same issues from the previous approach appear. Moreover, DNSSEC validation will fail if records are removed from a signed zone.¶
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 target network should be put in place, at the appropriate frequency. Typical DNS zone tranfer mechanism may not be suitable because TCP transport is likely not possible in deep space. In this case, other file transfer mechanisms may 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 target 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 target 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 another file transfer mechanism should 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.¶
This document assumes a minimal infrastructure on a celestial body surface and vicinty network. As discussed in [I-D.many-tiptop-usecase], there are other instances of IP networks in deep space. One of them is a cruising spacecraft which has non-continuous connectivity to Earth using a direct point-to-point link to Earth ground stations. A cruising spacecraft typically have a local IP network to connect the various payloads and computers together. Names may be used on the onboard network, either by a simple infrastructure as described in this document, or by other simpler means such as a static file distributed on all on-board computers. When the spacecraft lands or connects to an infrastructure network such as a celestial body surface network, some names may need to be updated to use the local DNS infrastructure. The transition is not discussed in this document.¶
Even with careful management, there is some probability that some applications or host on the target 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 target network. If the target 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 mechanisms to signal unreachability may be appropriate to be setup at the edge of the target 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'.¶