Subject: draft-iab-dns-choices-02.txt comments

From: wayne <[email-masked]>
Date: Wed, 08 Jun 2005 19:58:44 -0500

I believe that dns-choices is fundamentally flawed, it will be ignored
by developers that decide to use TXT and does not provide an useful
way forward.

I believe that that dns-choices flies in the face of decades of
successful Unix semantics about data storage in files.

I believe what needs to be done is to allocate say, 100 new DNS RRs as
clones of TXT records (say, TXT0-TXT99).  There are tens of thousands
of RR numbers sitting totally unused.

What the Unix philosophy about files is that there shouldn't be a
"file type" (RR number), most things should be put into flat text
files.  Files should be distinguished by "magic numbers", located
within the file.  These "magic numbers" do not need a central
authority to allocate them.

While text is often not as compact as binary formats and require
conversions/parsers, the advantages of being able to use standard
tools to edit and debug the files is huge.  Binary files are often not
significantly smaller, nor are the overhead of parsing is often
irrelevant.

Of course, the Unix philosophy of flat text files was developed back
in the 1970s when storage space and CPU cycles were far more expensive
than they are today, so these considerations are even less relevant 30
years later.

Reasonably long magic numbers are unlikely to collide, even globally.
When localized to particular application area, they are even less
likely to collide.  If one magic number is in widespread use, and
someone comes along and tries to re-use it, they will quickly discover
the collision and they, being the newer and less popular use, will
almost certainly back down.  Intelligent designers will do a survey of
the application area first to make sure there isn't a problem with
collisions.  Two unpopular systems that use the same magic number are
unlikely to collide because they are unpopular.

History has shown that collisions with Unix magic numbers is rare.  An
unofficial, first-come first-served registry of (TXTxx, magic number,
application area) tuples could make it even more rare.

By having, say, 100 TXT record clones to choose from, applications can
choose one that keeps the RR set small.  If there ever comes a day
when it looks like those 100 TXT RR clones are filling up, we can
allocate another 100, or even 1000 or 10,000 TXT RR clones.

The whole dns-choices I-D makes the assumption that TXT space is
limited, and instead of changing that assumption, it goes off claiming
that new, special purpose RRs should be used.

There are two conflicting problems with allocating new RRs.  First
off, the vast majority of ideas never take off, and if you allocate a
new RR type for every harebrained idea, we would run out of RR numbers
quickly and we would have a very long list of RRs that aren't used.
Secondly, if you try to do some sort of gate-keeping to make sure only 
"popular"/"useful" RRs get allocated, then that will be too much work
for people who want to just test an idea and they will go off and use
TXT RRs.  Of course, if that test proves successful, it will be too
late to change from a TXT.

Of course, right now we have a long list of RR numbers that have been
allocated, but hardly ever used, and the process of getting a new RR
number allocated is far too burdensome.

Let's take an example of Cisco's IIM email anti-forgery system.
Instead of using TXT, it is using a binary format called KR.  That's
what dns-choices says to do, right?  So this is good, right?  Well,
they have used used RR type number 1010 (decimal), which isn't in the
range that RFC2929 says to use.  Ooops.  So now there are people out
there deploying 1010 RR numbers and if IIM dies, that RR number will
be polluted for many years to come.  

And how am I supposed to look to see if these KR records exists with
dig?  Maybe there is a way, but I couldn't find it.  And how is this
stuff entered or displayed?  If you think that hex is as easy to read
as text, well, why aren't you reading this as hex now?  And since the
goal of IIM is to be used everywhere that email is used, every MTA,
every box that a mail admin uses, every DNS hosting service that lets
people create RRs will need to be updated with special code to deal
with KR records in a nice way.

Of course,Cisco's IIM system is defined by an I-D published on the
IETF website so it is easy to find.  How many other systems are there
that have gone and defined some other "easily typed" RR number that we
don't know about?

Dns-choices is doing nothing but tilting at windmills.  People will
continue to use TXT RRs because they are the best solution.  The only
problem with TXT is that their space is limited, but that can be fixed
as easily as it would take to create one single other new RR type.

-wayne

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 8 Jun 2005 21:11:26 -0700 (PDT)

On Wed, 8 Jun 2005, Dean Anderson wrote:

> I don't think adding new RR types is too hard.  Most implementations can
> handle unknown RR types properly.  I think at this point, the ones that
> don't are in the realm of "implementation problems" that aren't of concern
> to a standards group.  But, I would agree that adding new RRs is not a
> completely trivial exercise, and should not be undertaken frivolously.
> Frivolous RR types waste limited RR type space.

Tell me what percentage of RR type space is currently in use?
Would it be 1%? Perhaps less?

We have plenty of arguably "frivolous" tcp port assignments, yet we are
nowhere close to exhausting the number of available tcp ports. DNS people 
on this list really do guard assignments of new RR types too closely.

What should be done instead is separate registration into standard and 
provisional and allow easy registration of provisional RR type (with id 
assignment just for them, listing in IANA, etc) when just the internet 
draft is present.

Then DNS group would then watch their progress and if in say 2 years
they are able to get to standard level, provisional becomes standard
(keeping number) but if they fail, the provisional registration is
removed and in another 2 years the id is available for reuse by
somebody else. Obviously after 2 years pass/fail is not the only option 
they could apply for continuance of the provisional registration for
another 2 years, etc.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Thu, 9 Jun 2005 01:22:39 -0400 (EDT)

> Would it be 1%? Perhaps less?

Less at present.  But if we created new RR's for every anti-spam email
authentication proposal I've seen, we would quickly run out of 16 bits of
space.  And we expect that space to last for a long, long time.

> on this list really do guard assignments of new RR types too closely.

Getting harder to have rational allocaton of anonymous TCP ports. Can't 
just assume all services are less than 1024, now can you. 

> assignment just for them, listing in IANA, etc) when just the internet 

Reusing RR types is a bit harder than reusing IP address space.

> they could apply for continuance of the provisional registration for

Only problem is that this creates chaos for implementations to follow.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Fri, 10 Jun 2005 15:29:41 -0400

Am I missing something?

RFC 2929, as well as allocating RR Type numbers from 65280 - 65534 (0xFF00 - 0xFFFE) for private use also allocates almost half of all RR Type numbers, those from 32768 - 65280 (0x8000 - 0xFEFF), for use based on "Specification Required". That is, as defined in RFC 2434:

      Specification Required - Values and their meaning must be
           documented in an RFC or other permanent and readily available
           reference, in sufficient detail so that interoperability
           between independent implementations is possible.

Isn't getting an RR Type based on just publicly documneting its use liberal enough?

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John R Levine
Sent: Thursday, June 09, 2005 10:54 AM
To: [email-masked]
Subject: Re: draft-iab-dns-choices-02.txt comments

...

We don't need dynamic RR types, there's plenty of them.  We need to 
drastically lower the bar to assigning RR types.  It's a 16 bit field, if 
they handed out a thousand numbers of which only two turned out to be 
useful, it wouldn't be a big deal, it's less than 2% of the address space. 
It might also be good to designate some chunk of the RR space as the 
experimental range where numbers will never be assigned so people can 
safely fool around with private types there.

...

---

From: John Levine <[email-masked]>
Date: 11 Jun 2005 21:49:03 -0000

>Indeed.  And it isn't just NAPTR that is being overloaded.  Anti-spam
>DNSBLs have long overload A records in order to get a bit (or
>sometimes a few bits) for flags.  The SPF system codifies this
>practice with the exists: mechanism, but I haven't heard any
>complaints about this overloading the meaning of A records by SPF.
>The CSV system overloads SRV records.

I would say that DNSBLs and CSV reuse other record types, rather than
overloading them.  The important difference is that they have their
own namespaces.  Any A record returned from 1.2.3.4.somednsbl.org
means the same thing, this IP is in this DNSBL.  Wildcards work the
way you'd want, and you can list a /24 witn *.2.3.4.somednsbl.org.
Similarly, the SRV record you get back from _client.smtp.example.org
is always a CSV record.  Wildcards don't work, but that's a problem
with all SRV records.

A simple way to look at it is to say that the combination of the domain
name and the record type identifies the data you want.  If you do a lookup
and you get something back, that's definitely the data you want.

With TXT or TXT99 or whatever, you have to look inside the record to
see what kind it is, and that's the problem.  The data you get back
might be what you want, and might be something completely irrelevant.

R's,
John

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 13 Jun 2005 16:21:25 +0200

Dear Colleagues.

One of the arguments that is currently being used against trying to "design" 
a new RR for use with ones application, is that it is apparently difficult to get
one's specification reviewed, processed and the typecode assigned.

This should not be an argument.

The DNSEXT working group has the following statement in its charter:

     The lifetime of the group is set by the work items above but while
     these are ongoing the working group has additional tasks:

         o Reviewing and providing recommendations about the
           specification, by other working groups, of RR types that do not
           require any special processing and that do not require any
           special naming conventions.

It is the intentention that the DNSEXT WG will review that:

         o The proposed RR does _not_ need special processing by DNS
           servers or clients.

         o Your RR does not use name compression for the domain names
           in the RDATA section.

         o Your RDATA specification is correct and unambiguous.

         o Your specification does not make unreasonable assumptions
           about the working of the DNS

The group may give recommendations about the use of the DNS for the
protocol of application. The DNSEXT WG is not supposed to review the protocol that
uses the RR (but may sometimes be tempted).

For a well written specification this review should not take more than
a couple of weeks to a few months.

The specification then follows normal IETF process and hits IETF last
call.

We, chairs, can, in cooperation with the document editors the shepherd
the the process to speed up the review in the group and immediately
after IETF last call get an IANA type code assignment.

We hope to facilitate that the "two years get a type code" argument
will be irrelevant.

It is probably a good idea to document the process for this "fast
track" above a bit more thorough then the above 4 bullet points. The
rusulting document could update the assignment rules.

I should mention that we are already trying to practice in this
mode. Some RR specifications have passed the group and received some
recommendations and review. Examples are SSHFP, IPSECKEY. I am not
sure if the authors of these specifications are happy with the speed
and quality of the feedback they received but I do not think the
DNSEXT group was the bottle neck in getting an RR type
assigned. Currently the NFS4ID RR proposal is following this route and
deserves your review.

-- Olaf Kolkman, Olafur Gudmundsson.

---

From: Dean Anderson <[email-masked]>
Date: Mon, 13 Jun 2005 15:40:33 -0400 (EDT)

On Fri, 10 Jun 2005, wayne wrote:

> In <[email-masked]> Dean Anderson <[email-masked]> writes:
> 
> > 1.Abuser can still forge addresses at domain
> > 2.Abuser can use stolen credential
> 
> These are out of scope for this list.

No, actually, they aren't. A protocol that doesn't work isn't suitable for 
standardization.

But there is little point to arguing the details of why SPF doesn't work, 
now.

		--Dean

> 
> > 3.DNS cache problems (more records per domain, same cache size)
> 
> This is a choice that receivers can decide on.  If they don't think
> the additional DNS cache is worth it, then don't use SPF checks.
> 
> > 4.DNS load (more records per domain)
> 
> This, indeed, is a problem that I wish didn't exist.  Domain owners
> that don't want to deal with SPF will still receive DNS queries.  The
> only thing I can suggest is to publish an SPF record that has a very
> long TTL which says "v=spf1 ?all".
> 
> For domain owners that do want to publish SPF records, then that is
> their choice to have more records.
> 
> > 5.Ongoing Maintenance issues
> > 6.Migration issues
> > 7.IP Renumbering issues
> 
> Again, this is up to the domain owners who choose to publish SPF
> records.  SPF does have quite a few features that make these less of
> an issue, at the expense of increased DNS loads.  The choice is up
> tothe domain owner.
> 
> > 8.Lost non-spam emails
> > 9.Lack of universal compliance.*
> > 10.Not a basis for trust/reduced filtering
> > 11.Makes forgery blowback problem much worse
> > 12.Patent issues
> > 13.spam-profiteering / charges for SPF services
> > 14.Email Source Routing 
> > 15.Outbound SMTP Relay Identification
> 
> These are out of scope for this list.
> 
> 
> 
> The things that are in scope for this list are reasons why I have
> twice, without being asked, asked for reviews of the SPF I-D here.  If
> it was up to the IESG, no review would have been done here.
> 
> 
> -wayne
> 
> 
> --

---

From: Dean Anderson <[email-masked]>
Date: Mon, 13 Jun 2005 15:38:58 -0400 (EDT)

On Fri, 10 Jun 2005, william(at)elan.net wrote:

> 
> On Fri, 10 Jun 2005, Dean Anderson wrote:
> 
> > I think if we have genuine need for a new RRtype, it can be accomodated.
> > However, MARID wasn't a genuine need.
 
> but from what I see the issue is that DNSEXT is not assigning new RR
> types in without very very substantial review and that creates other
> problems like that that proposals like SPF begin to use TXT as basis and
> then this may become widely used on the net.

It is supposed to be IETF policy not to standardize hypothetical
protocols. That is, there should be working code. It should be tested and
proven to work as documented.

I think the problem here is methodology. The SPF folks came in and said,
essentially, "standardize and deploy this new protocol without any proof
that it works. Its too urgent to actually test before deployment."  But,
it didn't work, and they didn't get their standards, and they've been mad
ever since, claiming the IETF is irrelevant.

I don't see any problem with developing new RRtypes, showing that the
protocols work and perform some useful service, and then getting standard
RRtype codes. 

> It should not be for DNSEXT people to decide if concept itself is bad or 
> good and argue about it here, you should focus on providing stability for 
> dns system and let others run experiments that use dns for specific
> applications and if experiment turns out to be usefull the requested RR 
> assignment becomes permanent.

Experiments don't require standard codes.  The SPF folks didn't do any
real experiments. SPF was "too urgent" for such "nonsense".

> But trying to shut down (or not letting it start) the experiment by not 
> getting it RR is just wrong and exactly why proposals like SPF or DK 
> which attempt to use TXT RR instead of getting new one from the start.

No experiments were shutdown. Only production deployment was affected. 
Those are different matters, entirely.

Indeed, SPF supporters are currently asking sites to enter production SPF
TXT records, without telling those sites that they are participating in an
experiment. I've already suggested that this is misleading. The SPF
promoters are unconcerned and unfettered by ethical standards for
experimentation.