almquist@JESSICA.STANFORD.EDU ("Philip Almquist") (11/29/90)
The DNS Working Group meeting at the IETF will be a single two-hour session on Monday afternoon. The major purpose of the session will be (re)organizational, deciding on and planning projects for the coming months. Also, the X.400 Working Group will be discussing use of the domain name system for mapping between domain names and X.400 names. I don't plan to discuss their proposal in our meeting, but I hope that some of you DNS wizards will take the time to read their draft and give them thoughtful comments. From their agenda: > > [Wednesday] Morning Session: > > Discussion & Markup of the paper: > > "Draft Proposal for the use of the Internet DNS to maintain > RFC 987/RFC 1148 Address Mapping Tables" > > The goal of this session is to review this draft and modify as > necessary in preparation of its submission as an internet draft. > This will be the last chance for the working group to review the document > before it is submitted as an internet draft. Once submitted as an I-D, > I expect sites begin to implement, so it is important that we reach > consensus on issues raised in the document. > > This paper may be retrieved by anonymous ftp from janeb.cs.wisc.edu > (128.105.2.151) in the pub directory: > > -r--r--r-- 1 ftp 29553 Nov 26 17:03 dns987.out > -r--r--r-- 1 ftp 66845 Nov 26 17:03 dns987.ps > > Please do not come to this session unless you have read the document > and have comments. > For further information on the X.400 group meeting, contact Rob Hagens (hagens@cs.wisc.edu). Now, back to the subject of the Domain Working Group meeting. In order to get you thinking about what the group ought to be doing, here are a number of ideas from various sources, including the survey I sent to the namedroppers and bind mailing lists several weeks ago: 1. Consider and perhaps pass judgement on the resource record types proposed in RFC-1183 (AFS Data Base Location, Responsible Person, X25, ISDN, and Route Through). 2. Figure out if the MB and MG resource record types really work. If so attempt to get them widely deployed. If not, design replacements for them. 3. Define and standardize an Autonomous System Number resource record. 4. Add QCLASSes for non-IP protocols, such as DECNet. 5. Attempt to get the HS QCLASS more widely deployed. 6. Attempt to understand and document the issues involved in the use of multiple QCLASSes (for example, the semantics of queries for QCLASS=*). 7. Add load balancing to the DNS. {I think this has been done, but perhaps we need to get it written up and/or get the software more widely distributed}. 8. Create a DNS MIB. 9. Figure out if and how the domain name system can be made to give different answers to the same question depending on the identity of the asker. In particular, is there any good way to make parts of the name space private? 10. Figure out and document the safest way to set up fake root name servers. 11. Document better the ways in which a resolver or recursive server can detect and recover from being referred to a dead or sick server. 12. Figure out if it's possible and desirable to restrict a domain server to talking to "nearby" root servers. 13. Consider what steps the Internet ought to take to protect itself against the periodic problems it has with bogus servers claiming to be authoritative for "." or "*". 14. Evaluate short-term measures to improve, or at least describe, the security of the domain name system. Can we, for example, describe how a server or resolver might decide that a given piece of information should not be believed? 15. Consider whether it is possible and desirable for domain servers to perform RoboDoc-like sanity checks on their own configurations. 16. Figure out whether compression (DNS-style compression of names in resource records) can or should be used in zone transfers. 17. Figure out a policy for deciding that a new resource record type has become sufficiently "well-known" that compression may be used. 18. Consider whether there are procedural changes we might suggest to the NIC which would help to ensure that network administrators are aware of the need to register the servers for their IN-ADDR.ARPA domains. 19. Consider (and perhaps document our recommendations about) when it is appropriate to have resource records (other than SOA and NS) at non-leaf nodes of the domain tree. 20. Create a catalog of DNS software. {I believe that Paul Mockapetris has been working on this}. Philip