Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!cs.mu.OZ.AU!kre From: kre@cs.mu.OZ.AU (Robert Elz) Newsgroups: comp.protocols.tcp-ip.domains Subject: Re: Proposed extensions to MX records. Message-ID: Date: 2 Apr 91 22:57:47 GMT References: <1991Mar28.170144.8370@mp.cs.niu.edu> <1991Mar28.182232.13467@agate.berkeley.edu> <91Mar28.233847est.6186@neat.cs.toronto.edu> <8341@crash.cts.com> Sender: news@cs.mu.oz.au Lines: 57 jeff@crash.cts.com (Jeff Makey) writes: >We now need some >sort of access controls to provide different answers to DNS queries >depending upon who is asking the question. No we don't - telling lies is the very last thing that we want to do - we've already seen (many times) how a little bit of bad information can easily polute the namespace, and be difficult to get rid of - institutionalising this by deliberately providing wrong answers cannot possibly help. Quite apart from that - you can't possibly tell reliably who is asking the question, queries are often sent through forwarding nameservers, the server that handles the query has no idea at all where it originated. Some have suggested that the domain name of the requestor be used to decide on the answer to give - even assuming that you could find who the requestor is, this would mean the server doing an in-addr.arpa lookup before answering any query - kind of a heavy workload for a busy server there - but even then would be basing the decision on the wrong criteria - domain names should not be used for this purpose. Note that Neil's suggestion does not in any way attempt to hide information - he makes it all available, its then up to the recipient to decide how to interpret the information. That is, his suggestion is simply to provide some guidance. I could imagine that doing something similar for NS records may be an advantage - to suggest (somehow) which NS would be the preferable one to use. This is less important though, as its possible to determine that dynamically by watching the responsiveness of the various servers as queries are made - something that is much harder for a mailer to do (as "responsibveness" is not a measure of which MX is the best to use). Note again - Neil's suggestion does not restrict whoch MX destination a host can use, or which it should try first (beyond the standard restriction if the host involved is itself one of the MX hosts). All of the MX's are equally plausible hosts to use - the suggestion simply provides hosts with a method to determine which is likely to actually be an effective host to try (eg: host X is the best MX, but its useless trying that if you're not in the Z domain, as you won't be able to reach it, you can try if you like, just wasting a bit of time, so try using host Y instead.) Its problem is that that decision is based on domain names - a choice made only because without changing the DNS there is no other available information to use. But here its based on known, well defined, names, the domain of the host asking the query (one assumes it knows its own name - and for this purpose any extra domains it may be considering itself to be a member of) and the domains that actually appear in the DNS answer packet. kre