15 reasons for using URLs/HTTP

Hi,

I received several comments to my proposal 
to move from DNS to HTTP for fetching the authorization 
records. Some comment were interesting, some were not.

However, I'd like to give a more explicit list of reasons for my
proposal. I'll split the proposal in two parts.  First part is
using HTTP, second part is supporting dynamic authorization
(separate posting).


The proposal is to use DNS only to localize the webserver(s)
through A or SRV records. Optionally a TXT record can contain a
pattern for the URL, which is to be macro-expanded with
e.g. sender-address, receiver-address, message-ID, IP-Address,
time, receiver's country,...  to form the URL. The resulting URL
could be a static one (without CGI parameters) or a CGI call.

The reply might either be an authorization record like described
in RMX, LMAP, CallerID,... for interpretation at the receiving
MTA, or the request might be interpreted at the HTTP-Server
replying basically with "yes" or "no".

The request can be sent through a regular web proxy. Caching
and expiry are controlled throught the common HTTP reply headers.

Reasons for doing so:

* An authorization record is a kind of resource. An URL
  is a resource locator. These things fit together quite
  well, where DNS is good for localizing a server, but not
  to transport arbitrary (and possibly large) resources.


* Putting a resource in one piece on a web server is much, 
  much easier to do, less error prone, and much easier to 
  debug.

  Virtually anyone is able to put a file on a web server. 
  In contrast, most sysadmins I've seen are not really
  experienced with DNS and unable to setup a zone file
  properly on their own.


* Many domain owners do not have direct access to their 
  zone files. Very often the DNS stuff is done by the ISP, 
  any every change in the zone table requires an explicit
  request at business hours, and maybe will cost money.

  Putting just the pointer in the zone table once allows
  the domain owner to easily replace and update the record
  or dynamic script immediately.

  When deploying this in a world wide scale, people will
  need to update their records often in the beginning. 
  With DNS, this is difficult, since many secondary DNS
  servers do not allow to be updated in short intervals.

  Even for those who are unable to write the authorization
  record, cgi scripts could provide very easy user
  interfaces. It's obvious that it is much easier to write a cgi
  user interface which just puts the resulting file on a web
  server, than modifying zone table files which are held and
  maintained differently everywhere.




* I often found the DNS secondaries for a domain to be everything
  but synchronous and to provide different versions of the zone 
  table. Newer versions of bind have a update notification mechanism,  
  but many ISPs don't accept this notification mechanism. So 
  very often there is no way of pushing new zone files. You'll 
  need to wait for the next SOA query, which can take hours or days.

  It could have severe impact on mail traffic if servers provide
  different replies.


* HTTP delivers the record in one piece. No need to stitch any
  TXT records together.

  What do you do if your DNS cache does not have all TXT records
  for some reason? Of TXT records of a different zone file version?
  You can't trigger refetching the records before expiry. If the
  DNS cache ever goes into such a state, it will have unusable records
  until expiry (maybe several days).


* DNS entries have a size limit of 512 Byte. They can grow bigger, 
  but need to transmitted over TCP then. Many DNS servers are not 
  open to TCP queries. At least one of the drafts proposed to 
  split the records into smaller parts, attach them to pseudo 
  subdomains and reference them from a master domain.
  
  That's more the error prone and circuitous, you'll need to 
  collect information from several domains and hope their
  consistent.

  In contrast, HTTP is a single fetch, and that's it.


* HTTP supports HTTPS. 

* Since HTTP can transport any object and additionally informs
  about the object type, the authorization record can be
  cryptographically signed. Would be much more difficult with DNS 
  and make the DNS reply bigger.

* Supports dynamically generated authorization records. 
  DNS can't.

* Can completely hide the domain's relay structure and internal
  authorization procedures: Instead of interpreting an authorization 
  record at the MTA, the MTA could send a query 
  (URL with CGI parameters) to the server and the server simply
  replies "allowed" or "not allowed".

* It's not more expensive or complex than the current DNS based
  proposals:

  With DNS you need to send a UDP query to your DNS server, which
  itself sends a UDP query to the domain's authoritative server.
  Reply is too large, so a second request over TCP is needed.
  For the same reason, you have to send a second TCP request to your
  DNS server. If the authorization record is split into several 
  subdomains, you'll need more traffic.

  Makes about 2 UDP and 2 TCP queries. 

  The HTTP approach requires to localize the Web server:
  1 UDP query to your DNS server, and another one from it to the
  authoritative Server. Then you'll have to ask your web proxy,
  and it will ask the domain's web server for the record. 

  Again, 2 UDP and 2 TCP queries. But: No stitching, no 
  inconsistencies, no missing records.


* No need to use abreviations and compressed format in the
  authorization record. Can easily support different record 
  types through the mime type mechanism and allows to 
  easily use formats like XML.

* Easily allows to pass further information as part of 
  the authorization record (e.g. in XML), like
  
  - contact address for abuse
  - legislation the sender resides in
  - is the IP address an dial-up address


* With a file put on a HTTP server and a file format like XML  
  it is much easier to extend the record in future and to 
  add new record types while keeping backward compatibility.

  With DNS, you need to update the method to encode the record
  into DNS records every time.


* A plaintext record such as XML in a file is much easier to 
  read. No dirty tricks like including line numbers in TXT entries
  or encoding integer numbers as the lower part of an A record,
  which are not human readable without detailed knowledge.


Makes 15 good reasons.


Hadmut