Arnt Gulbrandsen wrote:
(FWIW, I tried to compute the traffic load of DNS vs. RMX++ vs. the
RPC mechanism I've been muttering about. Assuming that spammers adapt
and some other minor assumptions, I see no significant difference for
participating sites.)
Thanks a lot. I didn't compute it, but I roughly estimated this.
I do not expect a big difference in traffic. But I do expect Web
servers and HTTP proxies to
cope much better with this kind of traffic and stored data than DNS
servers can. And
Web servers do not need any update or new protocol. They are there.
Plenty of them.
And, as a main advantage, you could choose whether to
- put a static MARID record on the server as a file
- generate the record dynamically through a simple CGI script
- passing the parameters up to the server and do the check
in any way you want without change of protocols or MTA
software.
DNS servers can't do it.
I do not see this as the only possible solution. But I'd currently see
two technical
ways to do it as I mentioned before:
- Either the "small" solution:
Have a compact binary record in DNS. I'd prefer ASN.1. Write a coder and
decoder for the dns library, which converts the binary from and into a
readable
representation of your choice. If you like it, have nslookup and dig
print it
in SPF syntax for readability. Or in XML for postprocessing. Give it a
command
line flag to choose what you want. It is like with those x.509
certificates:
They are binary, but you use openssl to convert them into a readable
representation.
- Or the "big" solution (like RMX++):
Have a Pointer in DNS giving a resource locator where to get or
where and how to ask for the MARID record.
And there a two hybrid solutions:
- Ask the DNS for an any record in _marid.domain...
If you receive a MARID record, use the small version.
If you receive SRV records, use the big one.
- Or you receive a MARID record with either regular
entries or a special locator entry mimicing the former
SRV model.
In this way, XML and SPF colaborate very well, because they both are
just the external representation and you can arbitrarily choose which you
want for any purpose. You have one record and can convert it to
both (or other) representations. Best of both worlds.
The SPF people get, what they want: They can simply type in SPF
statements into their zone files, except that the are of type
MAR instead of TXT. And if the dig or nslookup, they see SPF as well.
Be happy.
The XML people can do it the same way. Be happy as well.
The DNS folks get compact binary records, and, btw, the introduction
of ASN.1 into DNS. I guess these are two reasons to be happy.
And the implementors can - of course after understanding ASN.1 and DER -
implement easily, because DER allows decoding with very small, compact,
and simple routines in any language, just with a one-byte lookahead.
I believe this to be more efficient and faster than parsing SPF records
(which might require regular expressions).
And you can extend it at any time because ASN.1 is extensible.
Unknown record? Just have a critical flag like in x.509 extensions.
If you don't understand it and it doesn't have the critical flag,
just skip it. It has a length field.
Did anyone complain that XML is extensible in syntax, but the
semantics is not extensible because requiring new programs?
This problem also occured with x.509 certificate extensions.
They solved it with a single bit, the critical bit. Unknown extensions
where this bit is not set can be silently ignored.
And this way you have a very clean separation between
internal encoding and external representation. DER is
unambigous. Want to embed x.509 certificates, e.g. for
SMTP over SSL? They are already ASN.1 encoded.
And it is not a big deal to provide a reference implementation of a
MARID interpreter which does not require any external library
functions (except for fetching other DNS records and such standard
stuff).
Give MARID records a new OID, as usual in ASN.1, and you can be
sure to be able to plug it in into other protocols without major problems.
regards
Hadmut