Network Working Group R. Austein INTERNET-DRAFT Epilogue Technology Corporation September 1993 DNS Support for IDPR [draft-ietf-dns-idpr-01.txt] Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. This is a working document only, it should neither be cited nor quoted in any formal document. This document will expire before 25 March 1994. Distribution of this document is unlimited. Please send comments to the author. 1. Introduction This note documents the support needed from the Domain Name System (DNS) by Inter-Domain Policy Routing (IDPR). The DNS changes are minor and can be deployed with minimal impact on the installed DNS community. When an IDPR Policy Gateway receives an IP packet, it needs to map the packet's IP address to an IDPR Administrative Domain (AD) in order to deliver the packet. The initial prototype implementation of IDPR used a configuration file to provide this mapping, but this is clearly unacceptable for a full-scale deployment of IDPR. As an existing, well understood, (relatively) low-overhead distributed database, the DNS is the obvious mechanism by which to distribute Austein Expires 25 March 1994 [Page 1] INTERNET-DRAFT DNS Support for IDPR September 1993 these mappings. Due to an unfortunate collision in use of the term "domain" by both IDPR and the DNS, this note avoids unqualified use of the term "domain." 2. The AD RR type. We define one new DNS RR type, with symbolic name "AD" and numeric value xxx. This RR type is class-independent; the rest of this note discusses IN class AD RRs, with the understanding that the mechanism described here is not tied to IP addresses. The RDATA portion of an AD RR consists of two 32-bit integers, each representing an IDPR AD. The two fields are the "home" AD associated with the address, and the proxy AD associated with the address. An AD which is acting as its own proxy (the normal case) has the same value for these two fields. Class IN AD RRs appear in the IN-ADDR.ARPA portion of the DNS name space. These RRs are used to map from an IP address to an IDPR AD. We expect that it will be possible to make heavy use of "wildcard" DNS names here, since we expect that all the hosts on a given IP network (or subnetwork) are likely to belong to a single IDPR AD. For purposes of discussion, assume that Miskatonic University is in Administrative Domain 42, while Engulf & Devour, Inc., is in Administrative Domains 666 and 17; Engulf & Devour recently purchased Liver Donors Ltd., in order to use their Policy Gateway as a proxy for Engulf & Devour's corporate network. The following RRs might appear in the DNS: Loki.Miskatonic.EDU. IN A 1.1.1.5 Thor.Miskatonic.EDU. IN A 1.1.1.6 Liver-Donors.EaD.COM. IN A 2.2.2.7 HQ.EaD.COM. IN A 3.3.3.8 5.1.1.1.IN-ADDR.ARPA. IN PTR Loki.Miskatonic.EDU. 5.1.1.1.IN-ADDR.ARPA. IN AD 42 42 6.1.1.1.IN-ADDR.ARPA. IN PTR Thor.Miskatonic.EDU. 6.1.1.1.IN-ADDR.ARPA. IN AD 42 42 7.2.2.2.IN-ADDR.ARPA. IN PTR Liver-Donors.EaD.COM. 7.2.2.2.IN-ADDR.ARPA. IN AD 666 666 8.3.3.3.IN-ADDR.ARPA. IN PTR HQ.EaD.COM. 8.3.3.3.IN-ADDR.ARPA. IN AD 17 666 In this case the AD RRs for Miskatonic University could usefully be collapsed into a wildcard RR: *.1.1.1.IN-ADDR.ARPA. IN AD 42 42 Austein Expires 25 March 1994 [Page 2] INTERNET-DRAFT DNS Support for IDPR September 1993 3. Use of the AD RR type. In the initial deployment of of IDPR, we believe that only IDPR Policy Gateways will need to know about IDPR ADs. Thus, only Policy Gateways will need to obtain and use AD RRs. In the long run it may be beneficial for hosts to obtain this data as well, but it is not necessary that they do so in order for IDPR to work correctly. 4. Bootstrapping the Policy Gateways Since a Policy Gateway needs an AD before it can forward a packet, the AD associated with the IP addresses of each of the Policy Gateway's default DNS name servers needs to be part of the Policy Gateway's configuration. Ie, there is a bootstrapping problem here, because we can't use the DNS to obtain the ADs we need in order to talk to the DNS. Note that the Policy Gateway's default DNS name servers are not necessarily the root DNS name servers; indeed, clever use of centralized DNS caches by a community of Policy Gateways will help decrease the load IDPR will add to the existing DNS system. Ultimately, however, this question reduces to the question of how the Policy Gateways reach the DNS root servers. 5. Glue RRs Since in some cases the authoritative nameservers for a particular AD RR may be within the AD itself, it may be necessary to insert "glue" AD RRs into some zones in the IN-ADDR.ARPA tree. These fill the same role as the glue A RRs already in use to solve the analogous problem with finding the IP address of a name server. 6. Security Considerations Security considerations ane not discussed in this memo. 7. Acknowledgments Most of the ideas in this document were derived from email conversations with Martha Steenstrup and Robert Woodburn, without whose help the author would still be completely clueless about IDPR and its requirements. 8. References [1] Steenstrup, M., "An Architecture for Inter-Domain Policy Routing", RFC 1478, June 1993. [2] Mockapetris, P., "Domain names - concepts and facilities", RFC 1034, November 1987. Austein Expires 25 March 1994 [Page 3] INTERNET-DRAFT DNS Support for IDPR September 1993 [3] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987. [4] Lottor, M., "Domain administrators operations guide", RFC 1033, November 1987. 9. Author's address: Rob Austein Epilogue Technology Corporation 268 Main Street, Suite 283 North Reading, MA 01864 USA Phone: +1-617-942-0915 EMail: sra@epilogue.com Austein Expires 25 March 1994 [Page 4]