On 5/22/2004 6:37 PM, Greg Connor wrote:
Interesting example but there is an assumption hidden here. Are you
aware of many applications that are designed to do a certain job that
use query type "ANY"?
I don't know of "many" but there are a few, including not-too-old versions
of sendmail which are still fielded in large numbers.
BTW, that was just the MX/NS and glue data. The full set including SOA/A
rolls in at 629 bytes.
If I'm correct, that means that the example of using "ANY" is kind of
spurious to this discussion.
DNS is prickly enough (and there are enough weird apps) that delicate
architecture is necessary if you want things to work smoothly. In
hotmail's case, for example, things eventually work sure, but the weird
systems have to fail out at least once. Should the infrastructure be
designed around reality?
Please, use an RR that holds a URL pointing to an XML document
instead.
I think we are in the MARID working group (Mail Authorization Records
_In_DNS_). Are you in the right place? :) Seriously, the efforts of
the work so far have focused on "lightweight" solutions and I don't
think we would win friends and influence people by requiring an HTTP
session to be opened for each lookup (or requiring clients to maintain
an HTTP cache to get down to almost the latency and bandwidth of DNS
queries.) I think a redirection to HTTP would be out of scope.
So stick the XML documents into an ESMTP verb instead. Really. We're
talking about SMTP here and if the SMTP client knows that it needs these
policy documents, well golly, let him go fetch and cache somewhere that's
useful for him. Why are we jamming SMTP policy into DNS anyway when the
SMTP client is what's going to be making the policy decisions?
MARID: mx://mydomain.com/policy
smtp-c: connects MX
smtp-s: 220-POLICY
smtp-c: POLICY
smtp-s: <xml...>
done.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/