Re: 15-15 good reasons for using URLs/HTTP

On 2/12/2004 11:36 AM, George Schlossnagle sent forth electrons to convey
why most of the 15 reasons are weak or aren't valid, several of which 
I'd already explained to Hadmut privately, but it seems fell on deaf ears.

>
> On Feb 12, 2004, at 2:15 PM, Hadmut Danisch wrote:
>
>> 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.
>>
>
>> 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.
>
>
> You can represent dns queries as URLs.  See 
> http://josefsson.org/draft-josefsson-dns-url.txt for details.  URL != 
> HTTP.
>
>> * 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.
>
>
> I don't see this as being an asset.  If you don't have the technical 
> acumen to setup DNS records properly, you should not be running a 
> mail-server.  Many ISPs have voiced this same opinion by refusing mail 
> from servers without valid rDNS lookups.

Indeed, it's not inherently easier, just something more people have 
experience doing, so it seems easier.  E.g. walking seems easy but try 
teaching a biped robot to walk.

>
>> * 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.
>
>
>
> See above.
>
>> * 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.
>
>
>
> You have the same problem with HTTP proxys disobeying caching headers.
>
>> * HTTP delivers the record in one piece. No need to stitch any
>>   TXT records together.
>
Ditto, e.g a likely complete record for hotmail.com would be

         hotmail.com  IN TXT  "v=spf1  ptr  -all"

That's a helluva lot smaller than 512 bytes.


>>
>>   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).
>
>
> Why would you go into such a state?
>
>> * 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.
>
>
> You're right of course that this is a hack, but I haven't seen many 
> SPF records that would require this sort of cludgery.
>
>> * HTTP supports HTTPS.
>
>
> I don't see the benefit of this.  It's a public record that you are 
> requesting.

It would address the deficiencies acknowledged in the LMAP discussion 
document that DNSSEC would resolve. 
Broad DNSSEC deployment is probably being held back by weaker forces 
than HTTP support in MTAs, but that's just IMHO.

>
>> * 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.
>
>
> http://www.dnssec.net/drafts.php
>
>> * Supports dynamically generated authorization records.
>>   DNS can't.
>
>
> Sure it can.  Your server might not be able to, but it's not a 
> deficiency in the protocol.  Plenty of servers are equiped to return 
> dynamic answers.
>
>> * 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".
>
>
> I don't understand what you are saying.

DNS based LMAP could direct to a server doing this too, as I've said 
before.  Eg. a "lookup" modifier could specify a DNSRBL or DNSRWL to be 
queried.

>
>> * 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.
>
>
> Some major differences are:
>
> 1) All mail servers now integrate resolution services.  None integrate 
> HTTP services.
> 2) Because of 1, a DNS based system does not require security policy 
> changes to make querying systems work whereas in your proposal 
> requires letting mail servers make HTTP requests.
> 3) Now we have two components for sending mail, a DNS server and an 
> MTA.  Under yours 3 components are required (4+ if you integrate 
> caching of query results, which is a critcal feature of DNS).  More 
> parts is not a good thing.
>
>> * 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.
>
>
> XML != good.  If I'm making millions of DNS queries per day, I don't 
> want long records.  I want them abbreviated and compressed.

DNS would be an order of magnitude or two more efficient.

>
>>
>> * 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
>
>
> See above.
>
>> * 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.
>
>
> See above.
>
> George
>