Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt

From: Ted Hardie <[email-masked]>
Date: Mon, 18 Oct 2004 10:59:26 -0700

At 10:35 AM -0700 10/18/04, Hallam-Baker, Phillip wrote:
>Christian is making an important point. The reason SPF is written
>to the bare TXT record without a prefix is that the people behind
>it had no way to get themselves a RR without waiting for two years
>before they could start deployment.

While Christian's point is important, I note that BCP 42 actually
distinguishes among various ranges:

      1 - 127
    0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
           TYPEs by IETF Consensus.

      128 - 255
    0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
           Meta TYPEs by IETF Consensus.

      256 - 32767
    0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
           Consensus.

      32768 - 65279
    0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].

      65280 - 65535
    0xFF00 - 0xFFFF - Private Use.

Using a code from the "private use" range for SPF might have been
a bit of stretch, but "specification required" would have been possible
with far less of a barrier than a two-year consensus process.

I believe the fundamental reason these folks chose TXT was that
existing libraries understood TXT records well enough.  The
ease of parsing these records was the second factor, again,
in my opinion.

If folks thing BCP 42 needs an update, or that IANA needs new
processes to handle requests in the various ranges, I think
now might be a good time to send text.  Since RFC 3597 is now a proposed
standard, we can hope for more complete libraries, and I suspect we will see
more requests for new RRs.

Just my opinion,
			regards,
				Ted

--
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: Roy Badami <[email-masked]>
Date: Mon, 18 Oct 2004 19:38:14 +0100

>>>>> "Ted" == Ted Hardie <[email-masked]> writes:

    Ted> I believe the fundamental reason these folks chose TXT was
    Ted> that existing libraries understood TXT records well enough.
    Ted> The ease of parsing these records was the second factor,
    Ted> again, in my opinion.

My understanding is that the SPF folks chose TXT because of problems
with some widely-deployed DNS servers and proxy firewalls that don't
support unknown record types, and also to allow records to be
published by people using ISP-hosted DNS with a web-based management
interface (which typically will not provide any way to create unknown
record types).

       -roy

---

From: James Snell <[email-masked]>
Date: Mon, 18 Oct 2004 11:45:06 -0700

> ease of parsing these records was the second factor, again,

I can collaborate this thought.  In a couple of days a new I-D should
be published that describes a couple of new resource record types
we've been working on.  In our initial passes at these records we had
intended to use TXT records precisely for the reasons given above.  We
ultimately decided against their use because of the problems inherent
in their ambiguity.  It simply made more sense to create specific
record types to handle the data we needed, despite the process
required to get those types officially allocated.  For our private
work-in-progress prototype implementations of the I-D, we have chosen
two numbers from the private range.

--
- James Snell
  IBM, Emerging Technologies
  [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Tue, 19 Oct 2004 02:44:01 +0700

Date:        Mon, 18 Oct 2004 10:35:09 -0700
    From:        "Hallam-Baker, Phillip" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Names such as _MARID.example.com are unusable for DNS as machine 
  | names.

That's simply wrong to start with, there are a few protocols that
forbid such names, but for most just about anything goes.   And quite
apart from that, who says what I am putting in my domain is machine
names - it is mine, I'll put there whatever I want to put there.

  | Christian is making an important point. The reason SPF is written
  | to the bare TXT record without a prefix is that the people behind
  | it had no way to get themselves a RR without waiting for two years
  | before they could start deployment.

Yes, that point of his I agree with, it is hard to get a new RR currently.
Part of that problem, of course, is that no-one has really been willing
to really trust that unknown RR types are really handled correctly by
all the existing servers out there.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 18 Oct 2004 20:53:34 -0000

Roy Badami writes:
> support unknown record types

Yes. A huge fraction of the DNS deployments on the Internet are BIND
versions that can't handle unknown record types. Every new record type
immediately encounters massive interoperability failures. Removing those
failures means updating BIND and waiting _years_ for BIND redeployment.

(BIND 9.1.0 finally fixed this bug---but a May 2004 survey of *.com,
*.net, *.org, *.info, and *.biz found 11 million second-level names
published by servers running BIND 8. Redeployment takes a long time.)

In contrast, TXT works. Yes, it requires coordination to avoid name
clashes; yes, it has space limits; but at least it succeeds in
distributing data to every interested client.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 Oct 2004 14:21:30 +0200

On Mon, Oct 18, 2004 at 10:31:55PM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 18 lines which said:

> nothing so grand.  he originally chose TXT because he didn't know
> any better, and by the time he got any help, there was already both
> code and data deployed that made TXT hard to change.

Not really true, I think. Roy Badami gave a better description
(http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01912.html).

Some elements:

* Every MS-Windows computer has a problem with unknown record types,
according to Microsoft itself. See
http://www.imc.org/ietf-mxcomp/mail-archive/msg01517.html and
http://www.imc.org/ietf-mxcomp/mail-archive/msg01511.html.

* Many "firewall appliances" have a problem when relaying DNS with
unknown record types.

* Many "registrars" or other DNS providers give you access to the zone
contents only through an "user-friendly" interface. Not everyone edits
the zone file with vi or emacs. The problem is so common that there is
a list of DNS providers that *do* allow you to create TXT records
(http://archives.listbox.com/[email-masked]/200407/0933.html),
not to mention unknown record types.

I do not ask you to adopt TXT records (you could say that Microsoft OS
is hopelessly broken and I would agree) but do not think the choice of
the SPF people was careless.

[Reminder: the issue of the new RR type for SPF -
draft-lentczner-spf-00.txt - will be discussed in Washington.]

---

From: Alex Bligh <[email-masked]>
Date: Tue, 19 Oct 2004 14:14:53 +0100

> the SPF people was careless.

Seems to me there is a bit of a chicken & egg argument going on here.
If you don't make it clear that the preferred way to incorporate new
DNS features is new RR Types, then people will continue to ship broken
operating systems / UIs etc. on the basis that new DNS features will
use TXT.

That does *not* mean (IMHO) that the early decision to use TXT for
SPF etc. was careless / dumb (whatever), it merely means it was taken
(a) in the absence of guidance as being proposed by draft-iab-dns-choices,
and (b) in the absence of the effect of guidance such as in
draft-iab-dns-choices on the various DNS-speaking servers/appliances/UIs.

IE if everyone (SPF folks included) were already following
draft-iab-dns-choices, there would be no need for it. So the fact that
people aren't following draft-iab-dns-choices (or producing compatible
OS's and appliances etc.) is a justification FOR having it, not against
having it; not should it serve to criticize people who've made other
decisions in the past (which is not I think what Paul meant, but...)

Alex

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Oct 2004 17:32:46 -0000

I fully agree that DNS implementations should support all record types.
As RFC 1034 says: ``Researchers are continuously proposing, implementing
and experimenting with new data types ... experimental behavior should
always be expected in extensions beyond the official protocol.'' As RFC
1123 says: ``DNS software ... SHOULD be written to minimize the trauma
associated with the introduction of new well-known types and local
experimentation with non-standard types.'' My DNS software has always
handled the complete 16-bit range of possible record types.

The reality, however, is that certain implementors have screwed this up
horribly. A large part of the Domain Name System, as it actually exists
on the Internet today, fails to deliver records whose types aren't on a
very short list. Fixing this will take years. We have to be honest about
this when we're talking to people writing software that uses DNS.

Alex Bligh writes:
> DNS features is new RR Types

For anyone who cares about interoperability, new RR types are _not_ the
preferred way to incorporate new DNS features. The preferred way is TXT
records. TXT records, unlike new RR types, succeed in delivering the
data to every interested client.

The problem here is not a failure to communicate the advice. The problem
is that the advice is wrong. Anyone who is suckered into following the
advice in draft-iab-dns-choices will suffer massive real-world
interoperability problems---and will then switch to TXT records,
throwing draft-iab-dns-choices away.

> the effect of guidance such as in draft-iab-dns-choices on the various
> DNS-speaking servers/appliances/UIs.

This draft isn't talking to the DNS implementors. It's talking to the
DNS users. It's giving amazingly bad advice to the DNS users.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 19 Oct 2004 14:16:43 -0400

>data to every interested client.

On the one hand I agree with Dan.  On the other hand I disagree with 
Dan.  (I am glad I do not have three hands.)

"In the moment" there are realities that cripple efforts to roll out 
new RR types, resulting in the use of the TXT RR as a crutch.  Dan is 
right about that.

One could react to this with a resigned countenance and go along with 
the crowd.  One could also decide to take an activist posture and try 
to fix the world, one application at a time.

I am making this suggestion (for the document) - which I have heard 
from someone else.  Encourage the use of new RR types as an extension 
mechanism for the DNS while noting a (potential) need to develop a 
transition mechanism that makes use of types that are in current 
widespread use - e.g., TXT.

My motivation is not to do this for the sake of academic 
protocol/architectural purity.  My motivation is to move the DNS into 
position for future efforts (via having a pure protocol/architecture).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-571-434-5468
NeuStar

"Now under neu management"

---

From: Alex Bligh <[email-masked]>
Date: Tue, 19 Oct 2004 19:22:09 +0100

> throwing draft-iab-dns-choices away.

Last time I looked there was no defined format for TXT records either, also
leading to real world interoperability problems the first time two
implementations collide, or versioning problems.

It may be (de-facto) true that most DNS speaking devices do not support the
extensibility required by the protocol definitions. The answer to this (at
a protocol definition level) would not appear to be "throw away the
extensible protocol and go to freeform text records".

Clearly, at an implementation design level, it's going to be pragmatically
necessary to work around widescale deployment bugs. It's not the first time
that has happened. I don't really see why implementations should not for
instance try their new RR type and if it's absent (or they get an error)
fall back to TXT. But unless you are proposing defining (at a protocol
level) what goes into a TXT record, that would seem to be an implementation
issue, not a protocol issue.

Putting it right in the protocol means there will be encouragement to fix
all these buggy implementations.

Alex

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Oct 2004 12:44:16 +1000

> this when we're talking to people writing software that uses DNS.

	FUD.

	You have to be able to publish the record.  You have to be
	able retrieve the record.  Depending upon which end(s) you
	are on you have control to upgrade any servers which don't
	support the new type, either directly or via finacial mean.
	The same goes for any middleware interfering with the DNS
	traffic.  If you choose not to exercise that control don't
	complain.

	It's not like there isn't a existing solution space to the
	problem.  The solution space exists and is well populated
	by mutiple vendors whether the problem is the nameserver,
	middleware or ISP.  In most cases your existing vendor
	already has a fix or can implement a fix and if they don't
	change vendor.

	The main reason nameservers are not upgraded is because
	they perform adequately enough for their users.  All you
	are seeing is sites that haven't yet seen the need to
	upgrade.

	A nameserver doesn't have to be able to publish a MX record
	if it will never be asked to publish one.  Lots of load
	balancers arn't capable of publishing a MX record and no one
	cares about that.  A nameserver has to be able to return
	a valid negative answer when asked about a MX record.  Some
	load balancers fail to do this correctly and people do care
	about that.

	The real litmus test is how many nameservers return a invalid
	negative answer when asked about a new RR type not how many
	are capable of serving the new RR type or even fetching the
	new RR type.  The later two will be addressed by direct
	consumer presure.  Only in the first case has a real negative
	impact on deploying new RR types and in my experience there are
	only handfuls of servers that fail to return valid negative
	answers.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Oct 2004 04:59:37 -0000

Alex Bligh writes:
> Last time I looked there was no defined format for TXT records either,
> also leading to real world interoperability problems the first time
> two implementations collide, or versioning problems.

Seems to me that we're doing just fine defining TXT-record formats and
avoiding TXT interoperability problems. Of course, this success comes
from open, honest communication among implementors---the sort of thing
that IETF used to promote and now actively interferes with.

The bottom line is that TXT succeeds in delivering the data to every
interested client, whereas new record types are a miserable failure.

> I don't really see why implementations should not for instance try
> their new RR type and if it's absent (or they get an error) fall back
> to TXT.

That's a much worse solution than pure TXT records, for several obvious
reasons: (1) for interoperability, everyone will have to provide TXT
records anyway, so the new RR type is extra work for the administrator;
(2) the new-then-TXT approach is more work for software authors than
pure TXT; (3) when networks are overloaded, the new-then-TXT approach
fails more often than pure TXT; (4) the new-then-TXT approach is often
slower, and never faster, than pure TXT.

> all these buggy implementations.

We already have encouragement. I already quoted the relevant sections of
RFC 1034 and RFC 1123. I wouldn't object to yet another document making
crystal clear that BIND and NSD and Microsoft screwed up and that we
really want to get rid of this problem before 2010.

However, until the bug has actually been fixed on every machine we can
see, it's irresponsible to tell people to use new record types.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Oct 2004 10:33:50 +0300 (EEST)

> see, it's irresponsible to tell people to use new record types.

FWIW,

Depending on what we want to achieve, defining new RR's might make 
perfect sense.

If a lot of prominent operators started using MARID-like techniques 
using those RRs, this would actually provide a really significant 
incentives for the vendors and the operators of broken equipment to 
get their act together and fix their crap.

Unless we use it, nothing is going to change in the next 10 years.

There's a lot evidence that things just don't get fixed unless there
is some pressure (examples: firewalls breaking on ECN,
servers/balancers mistreating AAAA records, etc.).  Maybe this would
be a good apportunity to get that broken gear fixed.

By the way, as it appears a lot of people are breaking DNS
specifications pretty badly, I wonder if it would make sense to try to
come up with some kind DNS implementation requirements document,
similar to "host requirements" a long time ago, but updated with
respect to new specs.. this would be a lot of work, but it might be
worth it if we want to decrease the amount of completely broken DNS
implementations out there.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Alex Bligh <[email-masked]>
Date: Wed, 20 Oct 2004 08:59:36 +0100

--On 20 October 2004 04:59 +0000 "D. J. Bernstein" <[email-masked]> wrote:

> records anyway

I don't see lots of people providing both A records and MX records for
this purpose (now).

> so the new RR type is extra work for the administrator;

I think the point is that you only try one if the other fails. Therefore
it can only be faster and MORE resilient to network congestion (etc.),
EXCEPT in the case of non-existent records, which I would suggest are
the minority.

Alex

---

From: [email-masked]
Date: Wed, 20 Oct 2004 13:51:11 +0000

Mr D.J. Bernstein, Associate Professor, Dpt of Mathmatics,
	Statistics, and Computer Science, University of Illinois at
	Chicago,  will not receive my reply due to his local policy
	on acceptance of email.  My reply talks to local policy as
	well as pointing out a possibly defective line of reasoning
	in his assertions.  For the record.

> that IETF used to promote and now actively interferes with.

	sub-typing inside the RDATA section... cool. move the
	problem from unknown RRtypes to unknown RDATA types.. :)

	who gets to keep track of the "open honest communication"
	about the various sub-typing formats so that future
	implementors can know what do do w/ the contents of 
	RDATA?  Must be the IANA.

> interested client, whereas new record types are a miserable failure.

	this line of thinking should raise the question - why keep
	any of the other, now vestigal, RR types...  anything we want
	can be done in the TXT RR.  right?

> records anyway, so the new RR type is extra work for the administrator;

	er... no. I -dont- have to provide or support TXT records. My zone,
	my data...

> Statistics, and Computer Science, University of Illinois at Chicago

--bill