Network Working Group R. Austein INTERNET-DRAFT Epilogue Technology Corporation October 1993 DNS Support for IDPR [draft-ietf-dns-idpr-02.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 27 April 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 27 April 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. When written in a master zone file, these fields are written as unsigned decimal integers; no characters other than the digits zero through nine may appear in these fields. The "proxy" field may be omitted, in which case its value is the same as the "home" field. 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. Since the IN-ADDR.ARPA portion of the DNS name space is (or should be) already populated with PTR RRs mapping IP addresses to DNS names, the DNS wildcard name mechanism will not generate AD RRs for IP that have associated PTR RRs. However, since not all IP addresses have associated DNS names, it will probably be useful to add wildcard AD RRs to master files where appropriate to insure that there is a "default" AD associated with every IP address on a given IP network or subnetwork. 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. All IP addresses within Miskatonic University are advertised as being Miskatonic's Administrative Domain, while Engulf & Devour choses to publish Administrative Domain information only for specific hosts. 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 Austein Expires 27 April 1994 [Page 2] INTERNET-DRAFT DNS Support for IDPR September 1993 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 *.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 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 Austein Expires 27 April 1994 [Page 3] INTERNET-DRAFT DNS Support for IDPR September 1993 whose help the author would still be completely clueless about IDPR and its requirements. Thanks also to Mike Patton for catching a serious error in the way that an earlier draft of this document proposed to use DNS wildcard names. 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. [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 27 April 1994 [Page 4]