Subject: DNS is mandatory text

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 11 Mar 2008 23:31:54 -0400

<no-hat>

During the namedroppers meeting I made the proposal that the current
ENDS0bis draft include words that made EDNS0 mandatory.
The sense of the room was that this was reasonable, even though it will
cause some problems.
I (personally) have the feeling this is a question of short intense pain
vs long dull pain.

So I propose that the next version of EDNS0bis contain something like:
(feel free to word smith)

ENDS is required

ENDS was specified in 1999 been on the wire since then, with minimal
adverse effects.
As number of uses of DNS require larger answers than can be easily fit in
512 byte answers, it makes sense to require modern DNS software to implement
EDNS0.
Thus Authorative servers, Recursive Resolvers, Stub-resolver and middle-ware
boxes speaking DNS in any form MUST implement ENDS0 and MUST support buffer
size of at least 2K.

<now-returning-to-being-chair>
	Olafur

--
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: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2008 14:51:48 +0200 (EET)

On Tue, 11 Mar 2008, Olafur Gudmundsson wrote:
> adverse effects. As number of uses of DNS require larger answers 
> than can be easily fit in 512 byte answers, it makes sense to 
> require modern DNS software to implement EDNS0. Thus Authorative 
> servers, Recursive Resolvers, Stub-resolver and middle-ware boxes 
> speaking DNS in any form MUST implement ENDS0 and MUST support 
> buffer size of at least 2K.

So-- if a DNS implementation does not claim to implement RFC2671 (or 
its successor), which RFC is the implementation incompliant with?

IMHO, text inside RFC X that RFC X is mandatory has only limited 
power.  Vendors usually describe which features they support by 
listing the RFC numbers (possibly with exceptions if they don't 
implement all the features of the spec) and I-D names and numbers.

If we want to mandate EDNS0 to be part of every compliant DNS 
implementation, I believe we should put that requirement in the 
upcoming profile or other BCP/standards track document (which in turn 
the vendor could claim to implement or not).

-- 
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: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 12 Mar 2008 10:37:42 -0400

Put it both places.
Donald

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pekka Savola
Sent: Wednesday, March 12, 2008 8:52 AM
To: Olafur Gudmundsson
Cc: [email-masked]
Subject: Re: DNS is mandatory text

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Mar 2008 13:13:44 -0400

I have a general problem with statements like "XYZ is mandatory." 
Especially in contrast with the mantra "the IETF has no protocol 
police."  What if a DNS implementation (which could be just a simple 
case of an application generating a query message and reading a 
response) doesn't have EDNS0 in it?  Will the IETF send in some kind 
of legal enforcement team to prevent the code from being labelled DNS 
in any way?

I can understand devising an extension to the DNS protocol or 
proscribing a means of putting DNS to use for a specific purpose that 
assumes that EDNS0 is available and in use.  I would see that 
happening by the extension/proscription including an applicability 
clause saying that "EDNS0 [RFC blah] is required."

But I can't support a blanket "from here on out, EDNS0 has to be in 
place."  There are turnkey uses of the DNS protocol that do not need 
and never will need EDNS0, writing a rule that causes these systems 
to have to implement EDNS0 is not beneficial.

For general purpose implementations (I am trying to define that in 
the AXFR document) it is a good idea to have EDNS0 included.  But 
this is where the IETF has to realize that it does not enforce it's 
own requirements.

Barring a complete rewrite of the DNS specification, there should 
remain a separate document defining EDNS0.  Any profile document 
ought to include ENDS0 as an essential feature of a general purpose 
implementation and recommend all other implementations either 
implement it or be aware that EDNS0 is defined.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Mar 2008 13:42:29 -0400

On Tue, Mar 11, 2008 at 11:31:54PM -0400,
 Olafur Gudmundsson <[email-masked]> wrote 
 a message of 32 lines which said:

> MUST support buffer size of at least 2K.

It is larger than the typical "Internet" MTU of 1.5K. Is it an issue?
Why 2K?

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 12 Mar 2008 19:02:43 +0100

> I (personally) have the feeling this is a question of short intense pain

I think this is a good idea. The interop issues when stuff (like firewalls)
don't grok EDNS0 and don't correctly signal this (making smooth downgrade
impossible) are irritating enough. It might only be usable as a larger
mallet on vendors, but that is sufficient for me. 

> boxes speaking DNS in any form MUST implement ENDS0 and MUST support

EDNS was specified in 1999 [RFC2671] and has been used frequently since
then, with minimal adverse effects. As the number of uses for DNS requiring
larger messages not fitting in the 512 byte pre-EDNS message size
increases, it makes sense to require modern DNS software, in name servers,
full-service resolvers and stub resolvers, as well as middle-boxes, to
implement EDNS version 0, and to support and advertise a buffer size of at
least 2 Kibibytes. 

-- 
Måns Nilsson                     Systems Specialist
+46 70 681 7204   cell                       KTHNOC
+46 8 790 6518  office                  MN1334-RIPE

VICARIOUSLY experience some reason to LIVE!!

---

From: Joe Abley <[email-masked]>
Date: Wed, 12 Mar 2008 20:15:32 -0400

On 12-Mar-2008, at 08:51, Pekka Savola wrote:

> upcoming profile or other BCP/standards track document (which in  
> turn the vendor could claim to implement or not).

I actually like the idea of making the statement in the EDNS0bis  
document, and marking that document as "standards track; updates RFC  
1035". That way people who claim to support 1034/1035 (or who  
undertake to provide such support) might be guided towards the light.

Including the sentiment in the profile document also seems sensible,  
however.

As to the original question, it seems sensible to me that DNS software  
and services MUST support EDNS0, insofar as an IETF MUST ever has any  
meaning outside the scope of standards development.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Mar 2008 15:37:01 +0200 (EET)

> mallet on vendors, but that is sufficient for me.

So, would the implication of this be that we don't need to make 
EDNS0bis to work "in the real world" (i.e., by providing sane fallback 
mechanisms if someone doesn't support it)?

I'm strongly opposed to EDNS0 mandate if the implication would be that 
DNS protocol does not work in the presence of no or incorrect support.

So, if we have a MUST support, we need to have MUST requirements for 
useful fallback mechanisms to work even in the presence of an 
incompliant (and legacy) implementations.

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 13 Mar 2008 15:02:39 +0100

--On torsdag, torsdag 13 mar 2008 15.37.01 +0200 Pekka Savola
<[email-masked]> wrote:

> So, would the implication of this be that we don't need to make EDNS0bis
> to work "in the real world" (i.e., by providing sane fallback mechanisms
> if someone doesn't support it)?

I do not advocate that legacy stuff should stop sending FORMERR and NOTIMP
when they don't grok EDNS. 

> DNS protocol does not work in the presence of no or incorrect support.

I would say that DNS, where we are taking it (DNSSEC etc), works less well
without, and thus it would be good to increase the pressure on vendors to
supply ENDS capable solutions. 
 
> useful fallback mechanisms to work even in the presence of an incompliant
> (and legacy) implementations.

Of course. Even if we wish to, we can't remove all the broken middle boxes
out there. But at the hot spots, where such boxes cause the most pain, we
could perhaps supply writings to make upgrade resistance softer. 

Look into my eyes and try to forget that you have a Macy's charge
card!

---

From: Florian Weimer <[email-masked]>
Date: Thu, 13 Mar 2008 15:58:13 +0100

* Olafur Gudmundsson:

> As number of uses of DNS require larger answers than can be easily
> fit in 512 byte answers, it makes sense to require modern DNS
> software to implement EDNS0.

Makes sense, I agree.

> Thus Authorative servers, Recursive Resolvers, Stub-resolver and
> middle-ware boxes speaking DNS in any form MUST implement ENDS0 and

Why 2K?  Why not 4K or 1.2K?

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 13 Mar 2008 14:59:29 -0400

>Why 2K?  Why not 4K or 1.2K?

<no-hat>
No reason, number larger than 1.5K was picked out of the hat.
The WG should work out what this number should be.
I would be happier with 4K as minimum.

         Olafur

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Mar 2008 20:12:42 +0000

> I would be happier with 4K as minimum.

me too.

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 14 Mar 2008 07:40:13 +0100

> I would be happier with 4K as minimum.

After some editing discussion, here is updated text.

EDNS was specified in 1999 [RFC2671] and has been used frequently since
then, with minimal adverse effects. As the number of uses for DNS requiring
larger messages not fitting in the 512 byte pre-EDNS message size
increases, it makes sense to require that modern DNS software, in name
servers, full-service resolvers and stub resolvers, as well as
middle-boxes, MUST implement EDNS version 0, and similiarily, that it MUST
support and advertise a buffer size of at least 4 Kibibytes.

The figure "4 KiB" is updated according to above. Still subject to WG
discussion, of course. 

Everywhere I look I see NEGATIVITY and ASPHALT ...

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 14 Mar 2008 11:11:00 -0400

Why picked out of a hat? Surely some reasoning can be given.

Presumably the problem with making this larger and larger is that you
will typically get more fragments and in congested environments the loss
of any one (or more) fragments will cause the answer to be thrown away
at the IP layer.

Two fragments is probably fine. So something like the most common MTU,
~1500 bytes, times two, minus a bit for headers / tunnels / good luck or
something, perhaps 2.5K bytes, would be good. If three fragment in the
typical case is considered OK, then 4K or a little bigger makes sense.

Of course, bigger answers also make traffic amplification attacks
worse... I'd go for 2.5K myself.

Donald

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Olafur Gudmundsson
Sent: Thursday, March 13, 2008 2:59 PM
To: Florian Weimer
Cc: [email-masked]
Subject: Re: DNS is mandatory text

<no-hat>

         Olafur

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Mar 2008 15:45:53 +0000

> Why picked out of a hat? Surely some reasoning can be given.

i don't think so.

> of any one (or more) fragments will cause the answer to be thrown away

yes, but that doesn't lead to a specific number.

> typical case is considered OK, then 4K or a little bigger makes sense.

the ratio of an atm cell size to the speed of an OC3c is 2X the ratio of
a maximum ethernet packet size to the speed of 10GbE.  and ATM cells were
called too small, where too much silicon had to go into switching them,
and too much bandwidth was being spent on headers (relative to payload.)

are we sure we want to enshrine the current observed internet MTU (1500)
in a recommendation?  i'm not.

> worse... I'd go for 2.5K myself.

i think we should say that 4096 is the absolute lowest recommended value
in 2008, giving as our reason that DNS applications have to be able to
assume something, and in 2008 the observed usual internet MTU is 1500,
and a couple of fragments here and there never hurt anybody, whereas TCP
is such a harsh penalty that most DNS application designers will want to
avoid it.

then we can leave it to our children to sort things out.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 18 Mar 2008 02:22:21 +0000

as a result of controversy around mandatoriness, i left it out of -01,
which according to the draftbot, was just now accepted into the system.