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

From: wayne <[email-masked]>
Date: Wed, 08 Jun 2005 21:40:07 -0500

In <[email-masked]> John Levine <[email-masked]> writes:

> The first 2/3 is basically fine, the discussions about all of the ways
> that one might add new data to the DNS and why most of them are bad
> are fine.  But then section 5 waves its hands, and makes lame
> arguments against the difficulty of adding new RR types.  The reality
> is that adding new RR types is hard, and the honest thing to say is
> yes, it's hard, there are barriers to doing so, but they're worth the
> pain.  

Agreed.

> The claim that most DNS servers and clients handle unknown RR types
> is, unfortunately, just false.  One of the things we learned during
> the MARID fiasco is that for some reason our pals in Redmond defined a
> DNS API with a separate call for each RR type, and no escape for RR
> types not in the API.  They then have built this API into a whole lot
> of computers in use all over the world, and none of those computers
> can handle new RR types at all, neither serve them nor look them up.
> Yes, they should fix it, but getting them to do so and to get it
> shipped to all the customers won't happen overnight.

Oh, but it is worse!

They have a firewall product that apparently many people use that
blocks all port 53 queries, so that you are *locked* into using this
braindead API and can't escape even if you roll your own resolver
code.

Mind you, the folks at the MARID interim meeting were not defending
these choices in any way, and the looked more than a little
embarrassed about the situation.  However, they weren't in any
position to change things, and it didn't sound like there were any
plans to change things.

> It also understates the difficulty in assigning type numbers to RRs.
> I am surely not the first person to note that the number of RR types
> is the same as the number of TCP ports, and to wonder why assigning RR
> numbers has been so much more of a problem than assigning TCP ports.

Well, there are certainly similar problems with collisions in usage,
but DNS has the extra problem that name servers and resolvers have
done special process on certain records and have to know how to deal
with new record types.  There isn't an equivalent problem with TCP
ports. 

> A more honest assessment of the current problems of new RR types and
> some direction about solving those problems would make this document
> a whole lot more persuasive.

Yep.

-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: wayne <[email-masked]>
Date: Wed, 08 Jun 2005 22:27:57 -0500

>> yes, it's hard, there are barriers to doing so, but they're worth the

Oops.  I misread the last sentence.

I agree with everything that John said, except that I *don't* think it
is worth the pain.  At least not in a many cases and a very large
percentage of the cases that this dns-choices document tries to
address.

-wayne

---

From: Dean Anderson <[email-masked]>
Date: Wed, 8 Jun 2005 23:38:26 -0400 (EDT)

> yes, it's hard, there are barriers to doing so, but they're worth the

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.

> the MARID fiasco is that for some reason our pals in Redmond defined a

I don't recall this being a problem with MARID, nor have I found anything
to date that this was ever raised as a MARID problem.  I'm presently
writing a paper on MARID problems, so if you have more specifics on this
problem WRT MARID, I would greatly appreciate it if you would forward that 
to me.

Thanks,

		--Dean

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

---

From: Florian Weimer <[email-masked]>
Date: Thu, 09 Jun 2005 13:38:53 +0200

> shipped to all the customers won't happen overnight.

But you can't be considerate eternally and halt all protocol
improvements because you think that a single vendor won't feel any
market pressure.

Section 3.5 in the draft misses the registration problem.  IANA is
probably unwilling to assign RR types to experimental protocols (in
the general sense of the word, not the IETF sense).  This is the main
reason why approaches solely based on RR types aren't generic enough
as an extension mechanism.

I see two solutions to the mess: Either fix wildcards to handle
prefixes gracefully, or dynamically assign RR types on a per-domain
basis (reserve a range of RR types, and use a two-stage query scheme,
to obtain the RR number first and the actual data in a second query).

---

From: Alex Bligh <[email-masked]>
Date: Thu, 09 Jun 2005 13:53:24 +0100

> to obtain the RR number first and the actual data in a second query).

Dumb question time, based on two questionable assumptions.

IF   one is the opinion TXT records should not be used for this
AND  one is of the opinion "fixing" (breaking? :-) ) wildcards to do this
     is not desirable
THEN you are left with a new RR type as the only solution anyway.

So, if those assumptions hold true, why would you want to invent two-stage
queries, when you can just do

$ORIGIN example.com
foo	IN	TXT2	"SPFv71"	"Here's my SPF String"
foo	IN	TXT2	"killspam3"	"Here's my other string"

IE encapsulate the type in the record itself, but not as part of
the freeform text field.

Sure you can't query by it (today) by type, but you can get all the
information back anyway, and if we wanted at some stage to query
by 4-tuple rather than 3-tuple, it would be obvious how to do it.

Alex

---

From: Florian Weimer <[email-masked]>
Date: Thu, 09 Jun 2005 15:05:56 +0200

> THEN you are left with a new RR type as the only solution anyway.

Seems reasonable, but as I wrote, I don't think the new RR type route
is a real solution, unless assignment is handled more liberally (which
is difficult because there are just 2**16 types).

> by 4-tuple rather than 3-tuple, it would be obvious how to do it.

I'm not sure how such a transition would interact with DNSSEC.

Just for clarity, I would propose something like this:

foo	IN	RTYPE		("SPFv71", 1025) ("killspam3", 1026)
foo     IN      TYPE1025	"Here's my SPF String"
foo     IN      TYPE1026	"Here's my other string"

(Everything is crammed into one RTYPE to cut down the protocol
overhead.  Another level of indirection (ahem) could be used to
increase caching.)

A client would request the RTYPE record, search for the corresponding
RR type, and request that RR type.  As a result, it wouldn't be bogged
down by large RRsets of a kind it's not interested in.  There's a
slight synchronization problem (you've to be careful when reusing
dynamic type numbers), but it doesn't look too bad.

IANA could liberally assign the indification strings because they
aren't a scarce resource.

---

From: wayne <[email-masked]>
Date: Thu, 09 Jun 2005 08:26:48 -0500

> I'm not sure how such a transition would interact with DNSSEC.

Yeah, I'm not sure how this would work either and I'm interested in
learning the answer.  At one time, I pondered the idea of using an
EDNS0-type extension system to allow for a *small* magic number
selector to be sent with the query in order to limit the number of TXT
records that are returned.  I think this would also cause problems
with conflicting TTLs.

> overhead.  Another level of indirection (ahem) could be used to

What happens if the list of mapped dynamic RR types exceeds the size
of a 512 byte UDP packet?

-wayne

---

From: Florian Weimer <[email-masked]>
Date: Thu, 09 Jun 2005 15:42:31 +0200

> of a 512 byte UDP packet?

Fallback to TCP, as usual.  This doesn't seem to be too likely in
practice.  You can include more than ten identifiers before it
happens.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 09 Jun 2005 13:55:12 +0000

> foo     IN      TYPE1026	"Here's my other string"

yow!  lack of subclassing bites us again.  we need a new kind of
wildcard, for nonterminal matching.  but the above is a reasonable
pave-over for this pothole, until the protocol catches up someday.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 09 Jun 2005 14:59:25 +0100

Florian,

> is difficult because there are just 2**16 types).

Indeed. So for clarification, my straw man proposal is, rather than to
invent 2 stage queries, or assign lots of new RR-Types, to assign a single
new RR-Type, the first field of which is (if you like) a sub-type.

>> So, if those assumptions hold true, why would you want to invent
>> two-stage queries, when you can just do
>>
>> $ORIGIN example.com

The 4-tuple query? Oh neither am I. No idea how it would interact
with anything. But it works on a 3-tuple query model too, which has
no adverse interactions.

> aren't a scarce resource.

Understand. Why (other than minimizing size of responses where
multiple things are present) do you need to have different RRTYPEs
for "SPF" and "other string" if this wasn't necessary with a
TXT-type solution (i.e. have 2 records of the same RRTYPE instead).

Again, possibly a dumb question.

> of a 512 byte UDP packet?

Wasn't this thrashed out in the more general case in EDNSO et al?
If you are saying "what about broken resolvers, broken firewalls,
broken servers etc. that don't support larger responses
(e.g. by falling back to TCP" then that type of broken stuff is
equally likely to be broken for any new RR type anyway, and encoding
in TXT records (all of which will be returned for one 3-tuple query)
is not going to be any more compact. IE it's no more broken either
in Florian's proposal or my straw man than any other way around it.

Alex

---

From: Florian Weimer <[email-masked]>
Date: Thu, 09 Jun 2005 16:08:13 +0200

> TXT-type solution (i.e. have 2 records of the same RRTYPE instead).

My two-stage proposal is entirely driven by a desire to minimize
response size.  In particular, it's possible to treat each record type
separately if your goal is the 512 byte packet size limit.

If TCP fallback isn't a practical problem, the simplicity of your
proposal clearly wins.  Unfortunately, I lack the kind of operational
experience necessary to make an informed judgment on the TCP fallback
question.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 09 Jun 2005 15:15:30 +0100

> experience necessary to make an informed judgment on the TCP fallback

So we would some real world data to tell us whether the set of resolvers
and middleboxen that break large answers is largely a subset of the
set of resolvers and middleboxen that choke on new RR-Types (because
if they choke on new RR-Types such as either yours or mine then whether
they choke on large queries is irrelevant).

My guess (uninformed by any actual data) is that the latter set (don't
support new RR-Types) is much larger, especially given the "helpful"
nature of many firewalls.

Research opportunity for someone.

Alex

---

From: "John L" <[email-masked]>
Date: 9 Jun 2005 10:47:38 -0400

> nature of many firewalls.

My understanding is that most Microsoft DNS software handles EDNS0, so big 
responses are less of a problem than new RR types.  The question about 
firewalls is a good one, both industrial sized ones and the little ones 
that every DSL customer has in their $30 router.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "John R Levine" <[email-masked]>
Date: 9 Jun 2005 10:53:46 -0400

>> is, unfortunately, just false. ...
> 

Quite true, but on the other hand, if you build software that half your 
users can't use, you're not going to get much traction.

> to obtain the RR number first and the actual data in a second query).

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.

Well, except for the problem of getting DNS software to support new types. 
To date, there's been an unspoken assumption that new RR's will be rare 
enough that DNS software developers can just hand-code support for new 
types and ship updates, leading to another unfortunate circle of no new 
types. Something like my XML proposal to make new types a table update 
rather than a software upgrade oughta help there.

I also agree with Vix that embedded wildcards would be a way out of this 
mess, but I perceive a strong sentiment in the DNS community that the 
current wildcards are just fine and the only problem is that people don't 
understand them, so I'm not holding my breath.

Regards,

---

From: Dean Anderson <[email-masked]>
Date: Fri, 10 Jun 2005 17:25:35 -0400 (EDT)

Umm. This seems like a lot of work for no good reason.  MARID failed for 
15 reasons, none of which was the problem with adding a new RR type.

SPF doesn't acheive its goals of stopping spam and creates more problems 
and more opportunities for abuse. I count so far 15 significant problems 
raised for SPF:

1.Abuser can still forge addresses at domain
2.Abuser can use stolen credential
3.DNS cache problems (more records per domain, same cache size)
4.DNS load (more records per domain)
5.Ongoing Maintenance issues
6.Migration issues
7.IP Renumbering issues
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

I think if we have genuine need for a new RRtype, it can be accomodated.  
However, MARID wasn't a genuine need.

		--Dean