Subject: [Asrg] Devilish: Forget about DNS

From: Hadmut Danisch <[email-masked]>
Date: Mon, 9 Feb 2004 17:50:04 +0100

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

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 9 Feb 2004 18:27:20 +0100

On Mon, Feb 09, 2004 at 06:11:57PM +0100, Patrik Fältström wrote:
> On 2004-02-09, at 17.50, Hadmut Danisch wrote:
> 
> I don't agree with this.
> I think we should start the discussion right here. What do you base 
> this information on?

I proposed to introduce a new RR with the first version of the 
RMX draft in December 2002. Since then I'm drowning in mails like
"How can you dare...", "We don't want...", "Too many old DNS 
servers, which can't be replaced...", "Too expensive...", "Too
much overhead...", "Will take 10-20 years...", "We don't support
this...", "Proprietary DNS server, can't be extended...", "Needs to
replace billions of DNS client softare..." and much, much more of
that. 

The other problem is that many, many people complained that they
would need to change the firewall or even network structure because
records would grow beyond 512 bytes and require TCP queries. 
As if many of today's DNS records wouldn't be longer than 512 bytes
anyway. 

But if we accept to query DNS records with TCP, why, after all, should 
we bother to fetch all entries and to stitch information together from 
differen TXT and A records or a new record type? HTTP is just perfect
for fetching a record of any data type and any length. And it exists. 
No need to replace or update HTTP servers.

All we need is to find the HTTP server which is competent to give the 
answer. Finding the HTTP server is a DNS task, that's what DNS is 
designed to do.

And a HTTP query is imho significantly better than trying to fetch 
several records throuth DNS/TCP and trying to stitch them together
(and no way to trigger the DNS server to refetch missing records).

Hadmut

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 9 Feb 2004 18:11:57 +0100

I don't agree with this.

(I had this view some 5 years ago, but was convinced I was wrong...and 
now I am on the other side ;-)

     paf

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 9 Feb 2004 18:37:45 +0100

After spending 20 more minutes to think about I'd go somewhat
more into detail:

If wanting to fetch the record for   somedomain.com

do a DNS query for  A, SRV and TXT record (or ANY) on

_lmap.somedomain.com     (violates the SRV RFC a little bit, but
			 for sake of efficiency)

If a SRV record is found then
  
   try the servers as described in the SRV records

elsif A records are found then

   try on of them or one after another, Port 80

else

   error, no record available.

end

If TXT record available then

  run it through maxcro expansion for sender name, IP address, 
  MessageID,...  and take this as the URL to query.
  (if macro after first '?' then protect special characters as
  usual in URL query parameters)

else

  use default URL  /_lmap/somedomain.com

end

-> Fetch record and evaluate

Hadmut

---

From: Dave Crocker <[email-masked]>
Date: Mon, 9 Feb 2004 10:06:21 -0800

Hadmut,

HD> We could use a much more modern and robust protocol, the
HD> famous and ubiquous HTTP. 

Let's see if I understand your proposal:

You want to stop using a distributed lookup service that has worked well
for 15 years, and you want to replace it with a point-to-point document
retrieval service?

Oh, no.  That's wrong.  You want to continue using DNS 'for what it was
built' which is mapping between names and addresses. You just don't want
to use it for this particular, new name/address mapping.

And, by the way, most of the difficulties making changes that you cite
have to do with implementation and operation, not protocol.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 9 Feb 2004 19:21:09 +0100

> for 15 years, and you want to replace it with a point-to-point document

No. You don't understand my proposal.

> to use it for this particular, new name/address mapping.

No. Again, you don't understand my proposal. 

I just don't want to use DNS to this particular, new 
name ->  lmap record mapping, where the record is some
arbitrary octet sequence of maybe several kilobytes.

DNS has never been built oder designed for that purpose.
So how could it be wrong to not use DNS for something it
has not been made for?

And, furthermore, analysis of all the comments I received for 
my RMX drafts and recent discussions showed that some domains
would need to dynamically generate the records depending on the 
query (see the hotmail example in 
http://www.ietf.org/internet-drafts/draft-danisch-scaf-00.txt

DNS is currently completely unable to provide dynamically generated
replies. HTTP servers can easily do that (CGI).

Again: I don't want to replace DNS in any way. I just don't want to 
invent a new use for DNS which DNS can't do properly. That's all.

regards
Hadmut

---

From: "denny" <[email-masked]>
Date: Mon, 9 Feb 2004 13:47:36 -0500

Just My $0.02 here....

This sounds *A LOT LIKE* a "Web Service" ... and I think I see what you mean
about DNS Vs. HTTP ....

It should be very doable to have a "Lookup Service" that replies with data
based on the query submitted. 

Just my bit on what I read....

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadmut
Danisch
Sent: Monday, February 09, 2004 1:21 PM
To: Dave Crocker
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Asrg] Devilish: Forget about DNS

 

regards
Hadmut

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 09 Feb 2004 14:27:07 -0500

> to use it for this particular, new name/address mapping.

RMX/LMAP drafts address the question of relationships between a given 
domain and a given MTA's IP address. There is nothing wrong with using 
DNS for this purpose and as a matter of fact, the XMPP draft uses a very 
  similar mechanism via DNS.

HOWEVER, if you want to store sender's identity in DNS that is a 
different question. Then, I would agree with Hadmut that DNS was not 
designed to store information about specific email accounts.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
  "Why are both drug addicts and computer aficionados both called 
users?" (Clifford Stoll)
-------

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 09 Feb 2004 15:09:12 -0500

Patrik Fältström wrote:

> I see several issues here:
> 
>> servers, which can't be replaced..."
> 
> 
> Three problems here:
> 
> (1) The zone file syntax might not be able to handle a new RR _name_ 
> because of parser issues
> (2) The zone file syntax might not be able to handle a numeric RR type
> (3) A caching resolver might not be able to cache an unknown RR
> 
> Out of these (3) is broken software. (2) is problematic and (1) is 
> something users have to manage.
> 

I would like to add to this that XMPP uses SRV records to verify the 
domain name/server IP relationship. See 
http://www.ietf.org/internet-drafts/draft-ietf-xmpp-core-22.txt, section 
14.3.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"But in this world nothing can be said to be certain, except death and 
taxes" (Benjamin Franklin)
-------

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 9 Feb 2004 20:58:00 +0100

Three problems here:

> , "Too expensive...",

Expensive?

> "Too
> much overhead...",

???

> "Will take 10-20 years...", "We don't support
> this...", "Proprietary DNS server, can't be extended...",

Well, NAPTR and SRV took not so many years, and in reality a new round 
of patches for Bind.

Remember that we talk about something which is to be visible in the 
global DNS, which normally public DNS software is in use. The 
proprietary stuff is normally hidden inside enterprises (or should be 
replaced anyway).

> "Needs to
> replace billions of DNS client softare..."

No. This I do not agree with. I have not seen any library which can not 
query for random RR types. Of course, programmers might be lazy and can 
not write their own code which parse a new RR type, but this is not an 
argument for me.

For example (good or bad example, you decide...) implementing ENUM 
using NAPTR as part of IOS in Cisco Routers was not a big deal from a 
DNS point of view.

> and much, much more of

Yes, a lot of people say these things....but I have not heard for 
example people in the DNSEXT wg say such things. They instead say 
things like "don't overload RR type values in the names (like SRV)" and 
"don't overload use in RR types (like TXT and NAPTR)".

> As if many of today's DNS records wouldn't be longer than 512 bytes

Correct. Two issues here:

(1) I see a larger risk the rr set expands above 512 bytes if we do NOT 
use a specialized RR type which minimize the size of the data, and the 
size of the RR set when sending a query.
(2) If they have a firewall which doesn't allow DNS over TCP, they have 
other problems already.

> differen TXT and A records or a new record type?

We don't want to use TCP.

> HTTP is just perfect

No, HTTP is not fun. Any implementation of HTTP is multiple degrees 
harder to implement that DNS. Have you read the spec?

> (and no way to trigger the DNS server to refetch missing records).

If you need to first use DNS, and then some other protocol, then this 
other protocol should be defined so it solves the problem which is to 
be solved. We should not get a bulldozer to try to catch flies.

See for example RFC 3205.

     paf