Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!bionet!ucselx!crash!jeff From: jeff@crash.cts.com (Jeff Makey) Newsgroups: comp.protocols.tcp-ip.domains Subject: Re: Proposed extensions to MX records. Message-ID: <8461@crash.cts.com> Date: 8 Apr 91 07:56:35 GMT References: <91Mar28.233847est.6186@neat.cs.toronto.edu> <8341@crash.cts.com> Organization: Future Procrastinators of America Lines: 27 Access controls are the correct paradigm for the proposed extensions, for the simple reason that we wish to restrict (attempted) access to certain MX hosts. (A similar concern is restricting attempted access to nameservers.) The problem with bogus RRs is a good reason for enforcing the access controls in DNS clients, but this doesn't mean enforcement shouldn't also be done at the server. Doing it both places would ease the transition period where a large number of DNS implementations don't do access controls. The only workable basis for allowing or denying access to particular RRs is the domain name of the requestor, and this could be either the regular domain name or the .IN-ADDR.ARPA name, whichever is more appropriate. Servers should err on the side of releasing RRs when the identity of the requestor is in question. Once again, I think enforcement should be done by *both* server and client, and that the mechanism should be applied to *all* RR types to allow maximum flexibility. Of course, the momentum of the DNS protocol and existing implementations may be such that the most we can hope for is a new RR type (which would still take a painfully long time to be widely understood). :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Posting from my temporary home at ... Domain: jeff@crash.cts.com UUCP: nosc!crash!jeff