Internet Engineering Task Force M. Blanchet Internet-Draft Viagenie Intended status: Informational 2 November 2026 Expires: 6 May 2027 Deployment and Use of the Domain Name System(DNS) in Deep Space draft-many-tiptop-dns-03 Abstract 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 name servers on (Earth) Internet. 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 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 6 May 2027. Copyright Notice Copyright (c) 2026 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. Blanchet Expires 6 May 2027 [Page 1] Internet-Draft DNS in Deep Space November 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Use Case and Requirements . . . . . . . . . . . . . . . . . . 3 3. Possible Approaches . . . . . . . . . . . . . . . . . . . . . 4 3.1. Pre-walk of all needed names . . . . . . . . . . . . . . 4 3.2. Pre-fetch of all zones in the needed name hierarchy . . . 5 3.3. Special zone . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Local zones . . . . . . . . . . . . . . . . . . . . . . . 6 4. Zone Transfer Considerations . . . . . . . . . . . . . . . . 7 5. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 7 6. ZoneMD Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Network Operations Considerations . . . . . . . . . . . . . . 8 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 8 8.1. Crusing Spacecraft (CS) . . . . . . . . . . . . . . . . . 8 8.2. Moon Full Connectivity (LF) . . . . . . . . . . . . . . . 9 8.3. Moon Intermittent Connectivity (LI) . . . . . . . . . . . 9 9. Example Procedure . . . . . . . . . . . . . . . . . . . . . . 9 10. New TLD for Deep Space . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 13.1. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Alternative Name Resolution Approaches . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction 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.ietf-tiptop-usecase] provides more details about key characteristics of deep space Blanchet Expires 6 May 2027 [Page 2] Internet-Draft DNS in Deep Space November 2026 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. Various scenarios of deployments depending on the distance of the celestial body and the coverage of orbiters are described in [I-D.ietf-tiptop-usecase]. This document describes on the hardest case (delays too long and intermittence) and then Section 8 discusses some specific ones. 2. Use Case and Requirements 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[RFC9364] in deep space has a lot of merit compared to starting another root with another trust chain. In order to achieve 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 of this document use case are: * inability to do real-time DNS queries to the Internet DNS infrastructure from space * domains used in deep space are under the same unique DNS root[RFC2826], deployed under agreed community requirements[RFC7720] * ability to sometimes reach the celestial body network name servers from Earth Internet to update their data cache * multiple network and DNS operators may exist on the celestial body network, each managing their own namespace and/or caches Blanchet Expires 6 May 2027 [Page 3] Internet-Draft DNS in Deep Space November 2026 * management of DNS servers and zones are done from Earth, since no human is expected to do server administration on celestial body network * Celestial body network autonomous DNS infrastructure to enable local resolution and DNSSEC validation 3. Possible Approaches This section presents various approaches that may 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: * One or more authoritative name server. * One or more resolvers using the above authoritative servers (or additional servers) in their hints/cache file. * hosts using the above resolvers. * DNSSEC verifying resolvers have the root trust anchor[trust-anchor] in their configuration. "Target network" used in this document means the celestial body network. It should be noted that, with proper planning and careful consideration, the following approaches are not exclusive and may be deployed over time. 3.1. Pre-walk of all needed names 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. 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 from the target network. To achieve this, a list of all needed names is saved and used as input for the above process. Blanchet Expires 6 May 2027 [Page 4] Internet-Draft DNS in Deep Space November 2026 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. Glue records, which are not signed, should be changed to the IP addresses of the authoritative name server on the target network 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 or error. 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. 3.2. Pre-fetch of all zones in the needed name hierarchy 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 need to be modified so that the NS glue records, not signed, 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 Blanchet Expires 6 May 2027 [Page 5] Internet-Draft DNS in Deep Space November 2026 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. 3.3. Special zone 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 using the same key used for the "Earth Internet" version of the zone, so that DS records in the parent zone remain unchanged. 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. Another variation is to dedicate a subdomain to the celestial body network, under a domain controlled by the entity. For example, moon.example.net, where example.net is managed by the operator of the Moon DNS infrastructure. In this case, names useful for Moon are located in a single zone. 3.4. Local zones Local zones can be deployed on the target networks. However, they may not be secured by DNSSEC. Moreover, the danger of name collision over time with the Earth Internet DNS can create a big operational issue later. Blanchet Expires 6 May 2027 [Page 6] Internet-Draft DNS in Deep Space November 2026 4. Zone Transfer Considerations 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. Current zone transfer mechanisms, such as AXFR, IXFR, rsync or ftp, all use TCP as transport. However, TCP is not suitable for deep space. Therefore, it is recommended to use AXFR/IXFR over profiled[I-D.many-tiptop-quic-profile] QUIC[RFC9250]. If DNS zone transfer is not possible or not optimal, than another file transfer mechanism such as HTTP over profiled QUIC should be used. 5. DNSSEC Considerations Zones are signed at various frequencies based on the operator policies. If a signature on a record has expired, then DNSSEC validation will fail. The quantity that bounds how long the target network can operate while isolated is therefore the validity period of the RRSIG records covering the data it serves, that is the interval between the signature inception and expiration times, and not any TTL. The re-supply period from Earth should be shorter than the shortest signature validity period present in the hierarchy being served, with margin for missed contact opportunities. 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. The automated trust anchor update mechanism of [RFC5011] cannot be relied upon on an isolated network. It requires a resolver to query the trust point at an interval derived from the DNSKEY TTL and the signature validity period, which in current root zone practice amounts to at least one query per day, to retry on failure at a comparable cadence, and to observe add and remove hold-down times of thirty days. A network that is out of contact for days or weeks cannot satisfy those timers. Trust anchors must therefore be established on Earth and delivered to the target network as part of the managed data set. Because the trust anchor is the root of all validation on the target network, it must not be accepted solely on the basis of the transfer that carried it. The receiving side should verify each key against the DS records published out of band by IANA [trust-anchor], by recomputing the digest of the DNSKEY as described in Section 5.1.4 of Blanchet Expires 6 May 2027 [Page 7] Internet-Draft DNS in Deep Space November 2026 [RFC4034] and requiring it to match a published value before the key is installed as an anchor. This check uses only the published digests and the key material itself, and so does not depend on the DNS that is about to be trusted. Finally, the DNSSEC RR TTL values need to be longer than the update times. If the parent zones are not copied in full, then negative answers can no longer be validated. This consequence need to be assessed by the missions. 6. ZoneMD Considerations When glue records are changed in a zone, the ZoneMD [RFC8976] digest is invalidated. Therefore, target network authoritative servers importing the zone should disable the ZoneMD check or the ZONEMD record should be removed prior to import. 7. Network Operations Considerations 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. 8. Deployment Scenarios Various scenarios of deployments depending on the distance of the celestial body and the coverage of orbiters are described in [I-D.ietf-tiptop-usecase]. This document describes the hardest cases. This section describes some specific ones that are typically easier. 8.1. Crusing Spacecraft (CS) This document assumes a minimal infrastructure on a celestial body surface and vicinty network. As discussed in [I-D.ietf-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 Blanchet Expires 6 May 2027 [Page 8] Internet-Draft DNS in Deep Space November 2026 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. This transition is not discussed in this document. 8.2. Moon Full Connectivity (LF) A Moon surface network always reachable from Earth because of a sufficient number of orbiters enabling full connectivity, provides a simpler case, as DNS queries and responses could go through the deep space links with an RTT of less than 4 seconds. DNS resolvers with caches on the surface network can then be used to optimize the name resolution traffic. However, if full connectivity is lost for some temporary windows, then DNS resolution may not work depending on the cache richness and RR TTLs. A more reliable infrastructure would be the one described in this document. 8.3. Moon Intermittent Connectivity (LI) A Moon surface network is reachable from Earth only during certain periods. Given an RTT of less than 4 seconds, DNS resolvers with caches on the surface network can then be used and DNS queries goes through the deep space links to Earth and responses back. If resource records TTL are lower than the longest intermittence interval, then those RR will be timeout in the cache, disabling name resolution for those names. Therefore, while this solution looks simpler, it is fragile and not recommended. 9. Example Procedure This section gives an example procedure to build the minimal set of zones with which a resolver on the target network validates every name under a celestial zone against the Internet root trust anchor, without any query leaving the target network. It uses "moon.example.net" as the celestial zone, operated by the operator of "example.net", and M as the address of the authoritative name server on the target network. The zones to provision are the root zone, "net", "example.net" and "moon.example.net". Prerequisites: "example.net" is signed and its DS record is published in the "net" zone; the root trust anchor has been verified as described in Section 5 and is delivered to the target network. Blanchet Expires 6 May 2027 [Page 9] Internet-Draft DNS in Deep Space November 2026 1. The operator builds the zone "moon.example.net" on Earth, as a complete zone signed. It contains its SOA and NS records, the address M for its name server, and all the names used on the target network. Its signature validity period should exceed the longest expected isolation period, with margin. The operator computes its DS record. moon.example.net. SOA ns1.moon.example.net. hostmaster.example.net. (...) moon.example.net. NS ns1.moon.example.net. ns1.moon.example.net. A M rover1.moon.example.net. A
2. The operator builds the celestial edition of "example.net" on Earth and signs it with the same keys as the Earth edition, so that it validates under the DS record already published in "net". The address records of all the name servers listed at the apex are set to M. The edition contains the delegation of "moon.example.net" with its DS record and glue, and any other names of "example.net" used on the target network. The operator verifies that its key signing key still matches the DS record published in "net". example.net. SOA (...) example.net. NS ns1.example.net. ns1.example.net. A M example.net. DNSKEY moon.example.net. NS ns1.moon.example.net. moon.example.net. DS ns1.moon.example.net. A M 3. Partial copies of the parent zones "net" and the root zone are built on Earth, from responses obtained directly from their authoritative servers rather than from a resolver. Each partial copy contains: * unmodified, each with its RRSIG records: the SOA, NS and DNSKEY RRsets at the apex, and the DS RRset of the child zone on the path ("example.net" in "net", "net" in the root zone); * the delegation NS RRset of that child zone, which is unsigned; * glue address records, unsigned and set to M, for the name servers of that child zone and for the name servers listed at the apex of the zone itself, since an authoritative server will not load a zone whose in-zone name servers have no address. Blanchet Expires 6 May 2027 [Page 10] Internet-Draft DNS in Deep Space November 2026 All other records, including the other delegations, the NSEC or NSEC3 records and the ZONEMD record, are omitted. 4. All four zones are loaded on the authoritative name server on the target network, as primary zones loaded from files. The resolvers on the target network are configured with the root trust anchor and with M as the address of the root zone. 5. Before delivery, the set is verified on Earth with an isolated validating resolver pointed at a copy of the server: every provisioned name must validate, and no query may be sent to any address other than M, including after the resolver has obtained the NS RRsets of the zones. 6. The set is delivered again before the first of its signatures expires. With this set, negative answers for other names in the partial parent zones cannot be validated, and the names of the name servers of the parent zones cannot be resolved on the target network. Neither affects the names under "moon.example.net". Each partial parent zone contains a few signed RRsets, one delegation and the glue for its own and its child's name servers, which is a small fraction of the complete zone. 10. New TLD for Deep Space Given the various considerations discussed in this document, a specific TLD for deep space would simplify many issues, such as signature expiration values more aligned with the expected period of intermittence. However, this specification works with or without a new TLD, therefore do not provide any recommendation on creating a new TLD or not, as well as its tree structure. 11. IANA Considerations This memo includes no request to IANA. 12. Security Considerations 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. That equivalence depends on the trust anchor held on the target network being genuine. Since the automated update mechanism of [RFC5011] cannot operate as discussed in Section 5, the anchor is delivered as managed data, which makes the delivery path part of the Blanchet Expires 6 May 2027 [Page 11] Internet-Draft DNS in Deep Space November 2026 trust model. Verifying each key against the digests published out of band by IANA before installing it, as described in Section 5, keeps the decision to trust a key independent of the channel that carried it and of the DNS being bootstrapped. Changing glue records disable the use of ZoneMD that could be used on the celestial body DNS infrastructure to verify zones on loading. 13. References 13.1. Informative References [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 2000, . [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, . [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, . [RFC7720] Blanchet, M. and L. Liman, "DNS Root Name Service Protocol and Deployment Requirements", BCP 40, RFC 7720, DOI 10.17487/RFC7720, December 2015, . [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, . [RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. Hardaker, "Message Digest for DNS Zones", RFC 8976, DOI 10.17487/RFC8976, February 2021, . [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, . [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, . Blanchet Expires 6 May 2027 [Page 12] Internet-Draft DNS in Deep Space November 2026 [trust-anchor] IANA, "Trust Anchors and Keys", . [I-D.ietf-tiptop-usecase] Blanchet, M., Eddy, W., and M. Eubanks, "IP in Deep Space: Key Characteristics, Use Cases and Requirements", Work in Progress, Internet-Draft, draft-ietf-tiptop-usecase-04, 28 October 2026, . [I-D.many-tiptop-quic-profile] Blanchet, M. and W. Eddy, "QUIC Profile for Deep Space", Work in Progress, Internet-Draft, draft-many-tiptop-quic- profile-03, 6 July 2026, . [I-D.many-tiptop-ip-architecture] Blanchet, M., Eddy, W., and T. Li, "An Architecture for IP in Deep Space", Work in Progress, Internet-Draft, draft- many-tiptop-ip-architecture-03, 2 March 2026, . Appendix A. Alternative Name Resolution Approaches Alternatives of using DNS include static distribution of name-to- address mappings and the direct use of IP addresses without names. TIPTOP nodes may be provisioned with static host name mappings (e.g., "hosts.txt"-style files), enabling local resolution without network queries. Updates are distributed periodically through TBD out-of- band mechanisms between celestial networks and Earth-based infrastructure. In small or constrained celestial networks, applications may use IP addresses directly, avoiding any naming system. This removes resolution dependencies entirely but reduces flexibility, human usability, error prone by typing IPv6 addresses, and abstraction from addressing changes. It will also disable the use of a large variety of DNS record types. These approaches are simple and robust to disconnection, but do not scale to large or dynamic TIPTOP deployments, introduce update latency (for static mappings), and lack DNS capabilities such as delegation, hierarchical naming, record types, caching control, and DNSSEC. Blanchet Expires 6 May 2027 [Page 13] Internet-Draft DNS in Deep Space November 2026 Operators of TIPTOP deployments should consider namespace size and dynamics, update distribution frequency between celestial networks and Earth-based infrastructure, administrative boundaries, and data integrity mechanisms. Static or IP-only approaches may be sufficient for small, stable celestial networks, but DNS-based solutions provide greater flexibility for larger or evolving TIPTOP deployments. Hybrid models can combine static distribution of a small set of nodes in a static mapping file such as /etc/hosts with DNS-based mechanisms. For example, nodes may be provisioned with hosts files for critical infrastructure, while DNS data is distributed as discussed in this document, with a name resolution preference set properly. Static distribution mechanisms provide simplicity and robustness under extreme delay and intermittence, but at the cost of scalability and functionality. DNS, when adapted for deep space conditions, offers a more general and extensible solution. Acknowledgements 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'. The following people have provided valuable feedback and comments, in no specific order: Lloyd Wood, Warren Kumari. Author's Address Marc Blanchet Viagenie Canada Email: marc.blanchet@viagenie.ca Blanchet Expires 6 May 2027 [Page 14]