Folks,
there has been a lot of discussion about how to cope with the
limitations of stone age service DNS.
DNS is difficult to extend for new record types, which makes
it expensive to introduce a new record type like RMX RR.
The currently existing record types make it difficult to
store the relevant information, as has been seen by many
of the proposals so far, e.g. when people need to store
boolen values or integer numbers in A records.
When you need to store more information, you need to
perform special tricks to store them, like Microsoft's
CallerID proposal, which assembles the information from several
TXT entries.
And - last not least - we are struggling with the packet size
limitations and the dualism of UDP and TCP.
I'd like to initiate a new discussion thread with this
proposal: Forget about DNS (except to use it for what it was
built for).
We could use a much more modern and robust protocol, the
famous and ubiquous HTTP.
When we do receive a message from a domain somedomain.com
sent from IP address a.b.c.d
then we could simple contact the host
_lmap.somedomain.com port 80
or - even better - get the SRV entry for
_tcp._lmap.somedomain.com
which would allow multiple servers, fallback servers, and
arbitrary ports.
At this port we could fetch from URL /_lmap/somedomain.com
(to allow the same server to serve several domains, and
receive whatever record format we're going to define,
like simple entry lines, XML, ASN.1 or whatever.
Need Caching? Just use any HTTP Cache. HTTP pretty well
supports transmission of expiry information.
Even better:
The record could contain a directive to do dynamic queries.
In this case we could query
/_lmap/somedomain.com.query?ipv4=a.b.c.d
or
/_lmap/query?domain=somedomain.com&ipv4=a.b.c.d
Where the query could be virtually anything if describing it with
SPF's macro expansion (maybe include the receiving MTA's country, the
MessageID, the size,...). This would allow to easily offer dynamic
services as described in
http://www.ietf.org/internet-drafts/draft-danisch-scaf-00.txt
Additionally, could optionally provide some kind of security with HTTPS.
This is robust, easy to maintain, no need for large scale software
replacement, in simple cases it's just a file to be put on a
webserver, or people can write CGI scripts for any special case.
And today, virtually every domain owner should be able to have a
file placed somewere on any web server.
And updating the file is easier than with DNS's expiry mechanisms.
So all we need bloody DNS for is the A and maybe the SRV record to
find the server. No tricks, no record type abuse, no hunting for
lost TXT records. Just normal use of existing protocols exactly for
what they have been designed for. :-)
Hadmut
(I was too busy to follow all mailing lists within the last months.
Would anyone gimme a hint if this has been proposed already?)