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

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

> On one of Christian's other points ...
> 
>   | The main argument against the name prefix solution is its
>   | incompatibility with wild cards.
> 
> The main argument against it should be that domain names don't belong
> to the IETF, they belong to whoever registered the domain, 
> and the IETF
> has no business whatever stealing names from organisations' domains.

Names such as _MARID.example.com are unusable for DNS as machine 
names. It is already agreed that names of some form --xxx will be assigned
for internationalization use. So whats this with calling it
'stealling'?

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.

Sure they have asked for a RR, but they have absolutely no intention 
of ever using it or participating in a migration to it. We are
back with the X-Header problem of RFC 822, only worse because 
the unprefixed TXT record is going to become useless for other
purposes.

As Alex points out most applications do not require wildcards 
at all, merely server side macros that expand to the appropriate
entries.

The wildcard issue is thus irrelevant wrt prefixes, it can be
solved by a single site deployment that has no impact on the
rest of the infrastructure.

--
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: Ted Hardie <[email-masked]>
Date: Mon, 18 Oct 2004 10:59:26 -0700

>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

---

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: Paul Vixie <[email-masked]>
Date: Mon, 18 Oct 2004 22:31:55 +0000

> interface (which typically will not provide any way to create unknown

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.  only microsoft could have forced a mind-change
or format-change, and they (microsoft) blew their chance due to IPR policies.

plz don't make this sound more complicated, or more considered, than it was.

---

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: Edward Lewis <[email-masked]>
Date: Wed, 20 Oct 2004 09:32:37 -0400

>EXCEPT in the case of non-existent records, which I would suggest are

Speaking from the experience of talking with the MARID group and also 
from observing the behavior of one popular DNS implementation, 
relying on a strategy of "try one, if it fails, try the other" is not 
going to be well received.

The problem is that this causes a latency hit for the application. 
Packets and bandwidth are cheap, a user's time isn't.  Application 
designers want to avoid long activity-dependency chains.

When searching for glue records, one DNS implementation asks for AAAA 
and asks for A simultaneously at all steps.  There's no real 
alternative - it's not like you can ask for just the A and then get 
the AAAA when you get an authoritative answer (positive or negative) 
- or vice versa.  That's because it's a waste of sending the last 
query, especially when the domain name sought has just one or the 
other address type.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Oct 2004 13:29:56 +0000

if new rr's take too long on deployment to be useful for new globally deployed
services and service models to be practical, somebody had better tell microsoft
that using SRV was a mistake.

(and, note: we've cut the time down by a lot since then.)

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Oct 2004 13:51:01 +0000

> When searching for glue records, one DNS implementation asks for AAAA and
> asks for A simultaneously at all steps.  There's no real alternative - it's
> not like you can ask for just the A and then get the AAAA when you get an
> authoritative answer (positive or negative) - or vice versa.  That's
> because it's a waste of sending the last query, especially when the domain
> name sought has just one or the other address type.

this is why, back in the days of rfc1886, i argued that the additional-data
processing for AAAA should be to "add any A RRs matching the same qname".

this is also why, back in the days of rfc2672, i argued that qdcount>1 should
be made meaningful, so as to allow several qtypes to be looked up for the
given qname/qclass.

in both cases the WG said "that's more complicated than the payback is worth."

what do you all think NOW?

---

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Oct 2004 11:17:59 -0400

>what do you all think NOW?

Since you've asked. ;)

I think that it's not all bad.  The current practice does achieve the 
goals of minimizing latency, allowing the migration from v4 to v6 
(and vice versa) to occur at the edges, is backward compatible with 
older software, and is resilient.  That's a lot of good.  There is 
that nasty cost of double the traffic though, that's a waste.

Hindsight isn't always 20-20.

Had we pursued multiple queries in a message, we'd have had to deal 
with the issue of partial results - like, if one query was for 
(foo.example. IN A) and the other was for (bar.example. IN A) and 
foo.example. existed and bar.example. did not, how is a half name 
error returned?  Who knows - had we travelled down that road would 
the WG be wrapped around the axle over AAAAbis by now?

Had we thrown the AAAA in the additional section, we may have had 
problems with the older pass-through servers that might not have 
known to add the AAAA's when it was needed (answering from a 
non-authoritative source).  We'd have been creating a new type with 
"special considerations."

Summarizing the above - we now have empirical evidence of a pitfall 
of the option chosen (which I prefer over anticipated concerns) and 
we have two other options that haven't faced a test.

One untried option is a new RR type (e.g., NSADDR) which may have all 
the glue in one RDATA (one large RDATA section).  EDNS0 solves size 
problems and we could do this as a "try this one, then fallback" for 
backwards compat.  Oops - there's that phrase "then fallback".  Maybe 
not wise course either.

I'd say that I'm happy with the bird in hand, even if it leaves me 
with guano, than the two birds in the tree.  I would be happier with 
the two birds in the tree, but I have to keep asking if the effort to 
obtain them is worth it considering what I already have.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Oct 2004 15:38:06 +0000

> goals of minimizing latency, allowing the migration from v4 to v6 (and
> vice versa) to occur at the edges, is backward compatible with older
> software, and is resilient.

if a AAAA response comes in without A RRs in the additional data section
and you happen to need them then (and only then) do you have to do another
query (for the A RRset).

if the servers you're talking to don't support qdcount>1 then you'll have
to do multiple queries.

both proposals were opportunistic and ended in good balance other than the
leftover complexity of having to support qdcount>1 even after IPv4's dead;
however, other possibilities exist, like querying for both MX+AAAA, or
SRV+AAAA, in various applications like mail transports.  so the complexity
would not have been truly wasted even after IPv4's dead.

> Had we pursued multiple queries in a message, we'd have had to deal with
> the issue of partial results - like, if one query was for (foo.example. IN
> A) and the other was for (bar.example. IN A) and foo.example. existed and
> bar.example. did not, how is a half name error returned?  Who knows - had
> we travelled down that road would the WG be wrapped around the axle over
> AAAAbis by now?

the proposal was for qdcount>1, all qname's the same, all qclass's the same,
and variant qtype.  so your multiple-qname scenario was under prior restraint.

> Had we thrown the AAAA in the additional section, we may have had problems
> with the older pass-through servers that might not have known to add the
> AAAA's when it was needed (answering from a non-authoritative source).
> We'd have been creating a new type with "special considerations."

the proposal didn't put the AAAA into the additional section, it put A RR's
there on qtype=AAAA.  just like A RR's go into the additional section on
qtype=MX (though there it's the target rather than the owner name).  are
you reading what i'm writing, ed?

> Summarizing the above - we now have empirical evidence of a pitfall of the
> option chosen (which I prefer over anticipated concerns) and we have two
> other options that haven't faced a test.

i don't like your summary.  "fear was mongered, several good solutions were
quashed, and we got our comeuppance" is a much better summary.  but it's just
possible that i'm bitter about this, or twisted, or perhaps both.

> I'd say that I'm happy with the bird in hand, even if it leaves me with
> guano, than the two birds in the tree.  I would be happier with the two
> birds in the tree, but I have to keep asking if the effort to obtain them
> is worth it considering what I already have.

there are really two questions here.  one is just out of bitterness and it
goes something "did we do the right thing?" and we all agree it's irrelevant.
the other question, though, is relevant: "should we do something different?"
with that in mind, here's the current EDNS1 draft, last revised two years
ago, containing the qdcount>1 proposal.  the historians among y'all know
that this text was excised from EDNS0 in order to trim down EDNS0 into
something the world could understand and agree on.  i apologize for the
length -- it's three pages.  but the third page is just the references.
note that ISC's name has changed since this was last troff'd.

---

   DNSIND Working Group                                         Paul Vixie
   INTERNET-DRAFT                                                      ISC
   <draft-ietf-dnsext-edns1-03.txt>                           August, 2002

                          Extensions to DNS (EDNS1)

   Status of this Memo

      This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

      Internet-Drafts are working documents of the Internet Engineering
      Task Force (IETF), its areas, and its working groups.  Note that
      other groups may also distribute working documents as Internet-
      Drafts.

      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as "work in progress."

      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

   Abstract

      This document specifies a number of extensions within the Extended
      DNS framework defined by [EDNS0], including several new extended
      label types and the ability to ask multiple questions in a single
      request.

   1 - Rationale and Scope

   1.1. EDNS (see [RFC2671]) specifies an extension mechanism to DNS (see
   [RFC1035]) which provides for larger message sizes, additional label
   types, and new message flags.

   1.2. This document makes use of the EDNS extension mechanisms to add the
   ability to ask multiple questions in a single request.

   Expires March 2003                                              [Page 1]

   INTERNET-DRAFT                    EDNS1                     August, 2002

   2 - Affected Protocol Elements

   2.1. Multiple queries in a question section have not been supported in
   DNS due the applicability of some DNS Message Header flags (such as AA)
   and of the RCODE field only to a single QNAME, QTYPE, and QCLASS.
   Multiple questions per request are desirable, and some way of asking
   them must be made available.

   3 - OPT pseudo-RR Flags and Options

   3.1. The extended RCODE and flags are structured as follows:

                    +0 (MSB)                            +1 (LSB)
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      0: |         extended-rcode        |            VERSION            |
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      2: |md |FM |RRD|lm |                       z                       |
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   VERSION  Indicates the implementation level of whoever sets it.  Full
            conformance with the draft standard version of this
            specification is version ``1.''  Note that both requestors and
            responders should set this to the highest level they implement,
            that responders should send back RCODE=BADVERS and that
            requestors should be prepared to probe using lower version
            numbers if they receive an RCODE=BADVERS.

   FM       ``First match'' flag.  Notable only when multiple questions are
            present.  If set in a request, questions will be processed in
            wire order and the first question whose answer would have
            NOERROR AND ANCOUNT>0 is treated as if it were the only
            question in the query message.  Otherwise, questions can be
            processed in any order and all possible answer records will be
            included in the response.  Response FM should be ignored by
            requestors.

   RRD      ``Recursion really desired'' flag.  Notable only when a request
            is processed by an intermediate name server (``forwarder'') who
            is not authoritative for the zone containing QNAME, and where
            QTYPE=ANY or QDCOUNT>1.  If set in a request, the intermediate
            name server can only answer using unexpired cached answers
            (either positive or negative) which were atomically acquired
            using (a) the same QTYPE or set of QTYPEs present in the
            current question and whose TTLs were each minimized to the

   Expires March 2003                                              [Page 2]

   INTERNET-DRAFT                    EDNS1                     August, 2002

            smallest among them when first cached, and (b) the same FM and
            LM settings present in the current question.

   Z        Set to zero by senders and ignored by receivers, unless
            modified in a subsequent specification.

   4 - Multiple Questions for QUERY

   4.1. If QDCOUNT>1, multiple questions are present.  All questions must
   be for the same QNAME and QCLASS; only the QTYPE is allowed to vary.  It
   is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY.

   4.2. RCODE and AA apply to all RRs in the answer section having the
   QNAME that is shared by all questions in the question section.  AA
   applies to all matching answers, and will not be set unless the exact
   original request was processed by an authoritative server and the
   response forwarded in its entirety.

   4.3. If a multiple question request is processed by an intermediate
   server and the authority server does not support multiple questions, the
   intermediate server must generate an answer iteratively by making
   multiple requests of the authority server.  In this case, AA must never
   be set in the final answer due to lack of atomicity of the contributing
   authoritative responses.

   4.4. If iteratively processing a multiple question request using an
   authority server which can only process single question requests, if any
   contributing request generates a SERVFAIL response, then the final
   response's RCODE should be SERVFAIL.

   4.5. An authority server processing a query for which QDCOUNT>1 will
   respond with a delegation or referral if any of the multiple QTYPEs
   present would yield such a response when QDCOUNT==1.

   4.6. An initiator can infer the absence of any RRs for one of the QTYPEs
   where QDCOUNT>1 if the response contains no RRs of that type but some
   RRs for one of the other QTYPEs present.

   Expires March 2003                                              [Page 3]

   INTERNET-DRAFT                    EDNS1                     August, 2002

   5 - References

   [RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
              Specification,'' RFC 1035, USC/Information Sciences
              Institute, November 1987.

   [RFC2671]  P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671,
              IETF DNSIND, September 1998

   6 - Author's Address

                 Paul Vixie
                    Internet Software Consortium
                    950 Charter Street
                    Redwood City, CA 94063
                    +1.650.779.7001
                    <[email-masked]>

   Expires March 2003                                              [Page 4]

---

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Oct 2004 11:43:14 -0400

>	can be done in the TXT RR.  right?

Peace folks.

The argument here is not head to head.  One set of words reflects the 
way it is now.  The other set of words is motivated by what may lie 
ahead.

I really want to encourage the continual movement towards an 
architectural correct DNS.  Without that, the system will become 
unmanageable and will be forced into stagnation from an engineering 
viewpoint.

But reformation comes at a cost - we can't shutdown the DNS for a 
week, have a flag day, instructing all uses of DNS software upgrade 
on a dime.  For this, we have to give a nod to doing some undesirable 
things, undesirable from the point of view of an architectural purist.

What's missing from the discussion is how the DNS engineering 
community helps lead the communities using DNS to reform their ways 
when it comes to using DNS. (E.g., what can be done to get 
application developers to not hold DNS data beyond the TTL 
recommendation?)  This is the answer to the "we gotta use TXT cause 
it works today," not retorting with "relying on the TXT means we can 
remove all other types."

I can't imagine any engineer worth their salt would want a system to 
stagnate.  I can imagine an engineer doing everything possible to 
continue to offer support to users, even if this means stagnation 
might look like the best approach.

That is why I think the draft ought to recognize that it is 
preferable to extend via new types and ought to acknowledge that 
reusing TXT, although discouraged, has a legitimate role in DNS work.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Oct 2004 12:00:45 -0400

>you reading what i'm writing, ed?

Yes.  Although I was around during the discussions then, I didn't get 
all that into the topic.  After starting in on DNSSEC in 1996 (and 
having a history in other lookup systems), I can now say that I 
didn't really come to understand the DNS protocol until about 2002 or 
2003.  I'm still not sure I really understand all of it now.

I mention this to say that I don't bear scars of those discussions. 
I may have caused some.

>quashed, and we got our comeuppance" is a much better summary.  but it's
>just possible that i'm bitter about this, or twisted, or perhaps both.

And that may well be - and for justifiable reasons.  What I've 
learned is to have a short memory when it comes to the debate over 
arriving at a solution.

A decision was made a while back.  It's water under the bridge.  The 
question that we need to focus on is, as always in engineering "where 
do we go from here?"

Do we want to revive the effort to "fix" the situation?

Do we want to revive the effort to "fix" the situation *now*?

Personally - I think the answer to the last question is no - not 
*now* - as we try to determine if DNSSECbis is a success.  I think we 
can live with the hit we see now.

(But that is not what tipped off the thread.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-571-434-5468
NeuStar