Re: 15 reasons for using URLs/HTTP

hello,
   I frankly don't get the point of this DNS vs. HTTP proposal, and I'll 
explain my confusion below.

At 11:15 AM 2/12/2004, Hadmut Danisch wrote:

>Hi,
>
>I received several comments to my proposal
>to move from DNS to HTTP for fetching the authorization
>records.

This is where I am lost.  Authorization is based on some kind of trust, 
i.e. "trust to do what?"  For example, with DNS, we trust the binding of a 
name to an address is correct, and with reverse DNS we trust the binding of 
an address to a name.  What do you propose to replace this with when you 
move from DNS, which is a global database system based on IANA assignments, 
to http, which is a client/server protocol?

Mark

>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
>
>
>
>
>
>
>
>
>
>
>