Re: Devilish: Forget about DNS

I see several issues here:

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

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.

> , "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
> that.

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)".

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

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.

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

We don't want to use TCP.

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

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

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

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