Subject: Re: [dnsext] Question on RFC 3225 - DO Bit and ANY

From: bert hubert <[email-masked]>
Date: Tue, 19 May 2009 20:29:56 +0200

On Tue, May 19, 2009 at 8:10 PM, George Barwood
<[email-masked]> wrote:
> RFC 3255 says :
>
> "Security records that match an explicit SIG, KEY, NXT, or ANY query, or are part of the
> zone data for an AXFR or IXFR query, are included whether or not the DO bit was set."
>
> AXFR and IXFR are a local matter, so I'm not worried about that.
>
> But for an ANY query, isn't there a significant risk of breaking ancient mail servers that use ANY ?

Sending ANY queries to a resolver is a 'bag of hurt' already, and
can't possibly work. So I don't think this will matter.

Resolvers only send out what is currently in their cache, which can be
a completely mixed bag of records.

    Bert

--
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: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 19 May 2009 22:13:33 +0200

> a completely mixed bag of records.

So, I agree with Bert here.  With ANY you can get unknown RR types back
also without DNSSEC, and good software implements RFC3597 to handle it.

Best regards,
   Wouter

---

From: SM <[email-masked]>
Date: Tue, 19 May 2009 14:10:08 -0700

At 13:38 19-05-2009, George Barwood wrote:
>"Sending ANY queries to a resolver is a 'bag of hurt' already, and 
>can't possibly work."
>
>Agreed. But it's the authority case that matters, I think it's 
>SendMail that uses ANY.

It's not sendmail. It's another well-known MTA.

>It may fall back to MX on truncation, or it may do something else ( 
>retry over TCP, fall over, who knows? ).

That MTA does not retry over TCP.

Regards,
-sm

---

From: bert hubert <[email-masked]>
Date: Tue, 19 May 2009 23:27:09 +0200

On Tue, May 19, 2009 at 11:10 PM, SM <[email-masked]> wrote:
>> Agreed. But it's the authority case that matters, I think it's SendMail
>> that uses ANY.
>

Can we please name names? Exchange? (I understand DNSEXT is not about
implementations, but it helps to know if this is a corner case or
something that is widely deployed).

>> It may fall back to MX on truncation, or it may do something else ( retry
>> over TCP, fall over, who knows? ).
>

Exchange has been known to have a love affair with DNS over TCP though..

  Bert

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 19 May 2009 14:36:08 -0700

> It's not sendmail. It's another well-known MTA.

I know qmail uses ANY queries, but it uses res_query(3) for handling
DNS queries, which at least on Debian 4.0 I have experimentally
confirmed that it retries queries over TCP after receiving truncated
UDP responses.

---

From: [email-masked]
Date: Tue, 19 May 2009 23:38:39 +0200 (CEST)

> Can we please name names? Exchange?

qmail.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: David Conrad <[email-masked]>
Date: Tue, 19 May 2009 15:19:08 -0700

> ancient mail servers that use ANY ?

Do you know of any instances of breakage?

> Can anyone re-assure me that this is safe?

The Internet is a dangerous place.  If software misbehaves when  
presented with something over the network, it most certainly isn't safe.

> It seems more conservative to send DNSSEC records only when the  
> client has indicated some knowledge of DNSSEC, so that an upgraded  
> server with a signed zone responds in exactly the same way as  
> before, unless DNSSEC support in the client is signalled by either  
> the DO bit or QTYPE.

There was discussion of this when 3225 was being written.  If I  
remember correctly (quite unlikely -- it was a long time ago), the  
consensus was that an application that requested ANY really needed to  
be able to handle anything that might be returned.

Regards,
-drc

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 19 May 2009 17:29:57 -0700

> confirmed that it retries queries over TCP after receiving truncated

Ah, my test case was somewhat faulty: res_query will repeat its query
over TCP, but qmail will still internally truncate the response to 512
bytes, causing a failure if the answers section exceeds this size.

(My first test case used dnscache, whose behavior for answering ANY
queries largely mitigates this problem; trying again with BIND exposed
it.)

---

From: David Conrad <[email-masked]>
Date: Tue, 19 May 2009 17:54:00 -0700

George,

On May 19, 2009, at 4:56 PM, George Barwood wrote:
> I didn't, but after some searching this link seems to suggest qmail  
> does break
>
> http://www.ripe.net/ripe/maillists/archives/dns-wg/2006/msg00013.html
>
> I think the semantics is cleaner if DO bit stops unrequested DNSSEC  
> records being sent.

Just to be clear, as I am no longer working for a DNS software  
implementer, I don't have a strong opinion either way.  However, to  
reiterate the arguments made oh so long ago...

> The ANY case is ambiguous, but the DO bit can resolve the ambiguity.

Well, no.  If you ask for ANY, I believe you're actually asking for  
ANY, which would include DNSSEC related stuff.  The fact that DNSSEC  
stuff is big and that sometimes triggers truncation is not really  
related to the fact that it is DNSSEC.

> If the client wants DNSSEC records, it will be sending an OPT record  
> anyway, and can set the DO bit.

If I do a "dig @server domain ANY, I would assume I want any records  
in that cache.  You are saying I should do "dig +dnssec @server domain  
ANY" to get any records in the cache.  When we add another RR type  
that has large rdata, should we add another flag both to the DNS  
protocol and dig so that qmail won't barf?

> Regardless, if I'm going to deploy DNSSEC, I need to be sure it  
> won't stop email being delivered.

I understand and agree.

> That's the real world.

So, in my experience, the real world is rarely that black and white.

You are suggesting that in order to deploy DNSSEC, we should revise an  
RFC and every DNS software implementer needs to update their  
implementation to support that revision.

The alternative is that the one mail server implementer that appears  
to have trouble with large responses returned by the ANY query fix his  
mail server so it can handle large response.

Either way, new software is going to need to be deployed.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 May 2009 11:35:01 +1000

Qmail is broken with or without DNSSEC records based on
	this thread.  ANY queries are a bad idea and should be
	stomped on with extreme prejudice.  ANY can cause the the
	64K TCP message size limit to be exceeded when individual
	queries for the desired records will succeed.  ANY queries
	make the querying application more complex than it otherwise
	needs to be as it still needs to fallback to individual
	queries when the desired records are not in the ANY response.

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

---

From: Emilio Perea <[email-masked]>
Date: Tue, 19 May 2009 22:33:13 -0500

> 	queries when the desired records are not in the ANY response.

FWIW, this was DJB's note on the ANY query change:

19961003 portability problem: all pre-4.9.4 versions of bind barf,
         badly, on CNAME queries to lame servers. what a crappy system.
	 even if the resolver doesn't barf, the next name server down
	 the line may barf. impact: qmail can't get mail through to
	 domains that are (1) lame and (2) running old versions of bind.
	 fix: never, ever, do a CNAME query. dns_cname() now does an ANY
	 query instead. this, like sendmail's analogous procedure, is
	 unreliable when a CNAME is mixed with other records.

---

From: David Conrad <[email-masked]>
Date: Tue, 19 May 2009 21:05:48 -0700

On May 19, 2009, at 8:33 PM, Emilio Perea wrote:
>> 	this thread.
...

1996?  BIND pre-4.9.4?

Seriously?

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 May 2009 14:43:46 +1000

In message <[email-masked]>, David Conrad
> > 19961003 portability problem: all pre-4.9.4 versions of bind barf,

	That was back when named loaded what it could and served
	that.  If queries came in for a type the wasn't loaded and
	there was a error loading it returned SERVFAIL.  MTA's
	idiotically made CNAME queries which were almost certain
	to fail with such zones as 99+% of email addresses are
	canonical w.r.t. the domain.  A plain MX/A query would have
	returned the CNAME as a side effect though the lack of a
	MX or A would still result in a SERVFAIL.  MTA's used ANY
	queries to work around this.

	We we told about this issue years after sendmail did this
	change and fixed named to reject the zone completely rather
	than depend on the operator to look at the log for errors.

	The best response would have been to tell us immediately
	so we could fix the bug and to tell sites running the old
	version of named to upgrade.  Work arounds have a habit of
	coming back to bite you which we can see at the moment with
	the handling of timouts on EDNS vs DNSSEC.

	Mark

---

From: SM <[email-masked]>
Date: Tue, 19 May 2009 23:42:39 -0700

At 16:56 19-05-2009, George Barwood wrote:
>I didn't, but after some searching this link seems to suggest qmail does break
>

There are other cases unrelated to DNSSEC.  If the response is 
greater than 512 bytes, it breaks unpatched versions of Qmail as 
Qmail does not fall back to using TCP.

>bytes, causing a failure if the answers section exceeds this size.

There is patch for Qmail to get around the 512 byte problem.

Regards,
-sm

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 20 May 2009 09:08:34 +0200

On Tue, May 19, 2009 at 09:05:48PM -0700,
 David Conrad <[email-masked]> wrote 

> Seriously?

Yes. Welcome to the wonderful world of djbware.

---

From: [email-masked]
Date: Wed, 20 May 2009 10:18:49 +0000

> be able to handle anything that might be returned.

	that is my recollection as well.
	imho, tweeking the DNS to accomodate another applications 
	short sighted behaviour is wrong. in that light, ANY should
	be retained (not exterminated as Mark Andrews seems to call for)
	and application developers who wish to use data from the DNS
	SHOULD adopt  a "Trust but Verify" mentality.

--bill

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 May 2009 15:09:27 +0000

> Date: Wed, 20 May 2009 10:18:49 +0000
> From: [email-masked]
> ...

queries for ANY, for NS and SOA, and for CNAME, are all diagnostic-only.
if an application is making such a query, that application is confused.

---

From: Tony Finch <[email-masked]>
Date: Wed, 20 May 2009 18:23:10 +0100

On Wed, 20 May 2009, Mark Andrews wrote:
>
> Qmail is broken with or without DNSSEC records based on this thread.

qmail has been abandoned by its author. The last release was nearly 11
years ago. It doesn't even compile on modern Unix without patches. It
would be a big mistake to twist the protocol to accommodate qmail's
brokenness.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: David Conrad <[email-masked]>
Date: Wed, 20 May 2009 11:48:49 -0700

On May 20, 2009, at 10:46 AM, George Barwood wrote:
> ANY is not by any means an explicit query for a DNSSEC RR.

Your opinion would appear to differ with the working group consensus  
from ages ago.  ANY requests anything, which would seem to include  
DNSSEC RRs to me.

> For academics living in Ivory towers, it is fine to declare that all  
> copies of qmail, and any similar software, must be updated.

"Academics living in Ivory towers".  Right.

Good luck with your efforts to get DNS software writers to modify  
their code.  I'm sure arguments like this will convince them.

Regards,
-drc

---

From: bert hubert <[email-masked]>
Date: Wed, 20 May 2009 21:15:54 +0200

On Wed, May 20, 2009 at 8:48 PM, David Conrad <[email-masked]> wrote:
> Your opinion would appear to differ with the working group consensus from
> ages ago.  ANY requests anything, which would seem to include DNSSEC RRs to
> me.

I agree.

> Good luck with your efforts to get DNS software writers to modify their
> code.  I'm sure arguments like this will convince them.

But here I don't - academics in ivory towers typically are not DNS
software writers. Any standard that would lead to more (bonafide) mail
being bounced will be frowned upon by anyone writing production
software.

So these arguments are in fact pretty convincing. Qmail is not large
enough to merit us changing the DNS spec for it, but (let's say)
Exchange would be.

Should this working group think otherwise (which I doubt), it would be
out of touch with reality.

     Bert

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 May 2009 15:35:07 -0400

At 21:15 +0200 5/20/09, bert hubert wrote:

>...is not large

I think otherwise.  In response to SiteFinder, it was said that DNS 
serves more than the web.  Keep that in mind, because DNS serves more 
than email.

The DNS protocol has to work equally well for all applications, for 
all kinds of zones.  Tugging on it to appease one protocol may have 
negative implications for another protocol.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: David Conrad <[email-masked]>
Date: Wed, 20 May 2009 14:22:49 -0700

Bert,

On May 20, 2009, at 12:15 PM, bert hubert wrote:
> software writers.

Indeed.  In fact, I'd say making accusations along these lines make  
the discussion relatively pointless.

> enough to merit us changing the DNS spec for it, but (let's say)

I dunno.  In this specific case, it seems to me that qmail is simply  
broken.  If I understand correctly, it is making invalid assumptions  
(that ANY response is always < 512 bytes) and has no way to recover  
(since it doesn't support TCP fallback).  The fact that DNSSEC  
responses are big has tickled this bug.  If 3225 redefined ANY to not  
really be ANY, but rather ANY except for DNSSEC-related types unless  
DO was set, then it really means ANY, it would hide the bug, not fix  
it.  As Mark Andrews points out, you can tickle the qmail bug with A  
RRs or AAAA RRs.  Even if Exchange or Sendmail or any other MTA did  
this, I suspect the answer would be the same.

> out of touch with reality.

So, for sake of argument, let's say Microsoft had released software  
that didn't conform to published standards, whereas numerous other  
vendors had implemented according to standard.  You are arguing that  
the right course of action is to revise the standard to match  
Microsoft's non-standard implementation?  In my experience, the IETF  
has taken the opposite view...

Regards,
-drc

---

From: "George Barwood" <[email-masked]>
Date: Wed, 20 May 2009 23:17:35 +0100

David

Seriously, wasn't the purpose of RFC 3225 to allow deployment, as per the abstract :

"In order to deploy DNSSEC (Domain Name System Security Extensions)
   operationally, DNSSEC aware servers should only perform automatic
   inclusion of DNSSEC RRs when there is an explicit indication that the
   resolver can understand those RRs."

I don't see how ANY can be taken as an explicit indiciation that the resolver understands DNSSEC RRs,
that's clearly not the case, so there is inconsistency.

I notice that RFC 4035, which updates 3225 is ambiguous :

"If the DO bit in an initiating query is not set, the name server side
   MUST strip any authenticating DNSSEC RRs from the response but MUST
   NOT strip any DNSSEC RR types that the initiating query explicitly
   requested."

since it doesn't define "explicit" (AFAIK). The dictionary says

"fully and clearly expressed or demonstrated; leaving nothing merely implied; unequivocal;"

Regards,
George

----- Original Message ----- 
From: "David Conrad" <[email-masked]>
To: "bert hubert" <[email-masked]>
Cc: "George Barwood" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 20, 2009 10:22 PM
Subject: Re: [dnsext] Question on RFC 3225 - DO Bit and ANY

>¶‹§²æìr¸›zÇ§u©ž²Æ zÚ'jg®Šiz»+z«ž²Ú)²'~ŠàÂ+a¶°¢·nžË›±Êâmè§jÈ§‚W¥Šwš²Ø^™ë,j{[¡ÜšÈb½èm¶Ÿÿ¢›"z×è®åŠËlþv¦yÚè¦—«³

---

From: [email-masked]
Date: Wed, 20 May 2009 22:30:24 +0000

> if an application is making such a query, that application is confused.

	perhaps you mean -most- applications are confused.

--bill

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 May 2009 23:16:41 +0000

> 	perhaps you mean -most- applications are confused.

i'm talking specifically about stubs, not server to server.  if an app is
asking CNAME or ANY questions, through a stub, it's for diagnostic purposes.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 May 2009 09:39:23 +1000

> asking CNAME or ANY questions, through a stub, it's for diagnostic purposes.

res_findzonecut() uses SOA queries to discover the zone cuts.

Mark

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 May 2009 01:21:20 +0000

> > i'm talking specifically about stubs, not server to server.  if an app
> > is asking CNAME or ANY questions, through a stub, it's for diagnostic
> > purposes.
> 

good one.  any others?

---

From: [email-masked]
Date: Thu, 21 May 2009 01:56:08 +0000

> asking CNAME or ANY questions, through a stub, it's for diagnostic purposes.

	and such an application is thereby -not- confused, but is doing
	what it was designed to do.

	the heartburn here is that folks who have written applications that
	pull data out of the DNS have been lazy and punted to "get everthing"
	aka ANY, w/o an understanding of what that ment, and while it worked
	for the most part, the underlaying protocol has changed what it means
	to "get everything" ... and instead of fixing the apps (or letting the
	orphans die a natural death) a few folks want the DNS protocol jocks
	to mod the protocol for their particular borked, EOL application.

	Ed said it better than me.

--bill

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 May 2009 12:28:05 +1000

> 	Ed said it better than me.

	From a protocol perspective nothing has changed.  ANY still
	means ANY.  There is just a data volume change over time.

---

From: [email-masked]
Date: Thu, 21 May 2009 03:00:47 +0000

> 	means ANY.  There is just a data volume change over time.

	no problem then.. however, I saw this posting, which suggests some would contemplate
	a protocol change (removing ANY)..

Date: Wed, 20 May 2009 11:35:01 +1000

        ANY queries are a bad idea and should be stomped on with extreme prejudice. 

--bill

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 May 2009 13:17:31 +1000

In message <[email-masked].>, [email-masked]
roshi.com writes:
> is

	They should be.  ANY queries just make the applications
	more fragile.  If the application need a type it still has
	to have code to explicity query for it if that type if it
	is not returned.

	Some people think ANY queries will speed up the processing
	but they can also slow up processing as you may still need
	to do all the explicit queries.

	Mark

---

From: David Conrad <[email-masked]>
Date: Wed, 20 May 2009 21:48:02 -0700

George,

> that's clearly not the case, so there is inconsistency.

As I said before, your opinion differs from the consensus of the  
working group at the time.  It's really quite simple: ANY was taken as  
meaning 'any'.  Not 'some'.  Not 'only the old stuff'.  Any.   
Including DNSSEC RRs.  I'm sorry you consider it inconsistent, but I  
won't bother arguing since it's actually irrelevant.

As far as I can tell, the reality today is that it appears exceedingly  
unlikely folks are going to hack their name servers in order to allow  
a decade plus old MTA that would appear to be broken out of the box to  
continue to limp along.  As more zones get signed, the folks that run  
those unpatched MTAs will increasingly see the bogus error message and  
either apply the patch to allow the MTA to deal with large responses  
(DNSSEC or not) or upgrade to a modern MTA.

It is, of course, possible that some folks like (presumably) yourself  
won't sign their zones fearing the < 6% of MTAs (I wonder how many of  
those are unpatched) that might not be able to send mail to them. That  
would be unfortunate, but I am somewhat skeptical that this would be  
sufficient mass to force DNS software vendors to modify their code.   
Maybe I'm wrong.

Regards,
-drc

---

From: [email-masked]
Date: Thu, 21 May 2009 11:46:04 +0200 (CEST)

> My purpose here is not to predict the future, but to flag the (potential) problem, 
> and also to safeguard my job my not installing something that may cause some 
> email to bounce.

Then you should use a different mail system than qmail. Unpatched qmail
has problems *today*, without DNSSEC.

---

From: [email-masked]
Date: Thu, 21 May 2009 12:01:15 +0200 (CEST)

> What will happen is that soon after installing DNSSEC and signing a zone, 
> email will start to bounce, the DNS operator will be notified of the problem
> ( after much head scratching ) and DNSSEC will be uninstalled until the 
> problem can be fixed. On the basis of once-bitten, twice shy, the deployment
> attempt may be abandoned permanently ( "DNSSEC is too much trouble" ).

No. Any qmail installation today which sees a significant volume of
traffic to and from the Internet either *already* has problems (which
are not due to DNSSEC), or has installed the necessary qmail patches.

If you google for "qmail patch dns" the very first entry says "Big DNS
patch for qmail", and is from 1998.

DNSSEC does not create any new problems for qmail.

---

From: [email-masked]
Date: Thu, 21 May 2009 11:41:29 +0000

On Thu, May 21, 2009 at 12:05:29PM +0100, George Barwood wrote:
> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Thursday, May 21, 2009 10:46 AM
> I don't use qmail, the problem is that I still want to receive email from people who are using it,
> including those who have not updated their systems since 1990, or who are using derivative software,
> or ..... a million other possibilities, which I have zero control over.

	Can't fault you for wanting to support "long-tail" ... 
	If I may, how long are you willing to wait for folks to 
	catch up?

	As a data point, I find there remains little community sympathy
	for my use of BIND 4.9.x code...  or sendmail 5x.

--bill

---

From: Basil Dolmatov <[email-masked]>
Date: Thu, 21 May 2009 15:53:37 +0400

George Barwood пишет:

> including those who have not updated their systems since 1990, or 

> who are using derivative software,

Plesk, for instance, is still widely used on hosting platforms and 
contains deeply-frozen qmail inside as main mail agent.

dol@

---

From: David Conrad <[email-masked]>
Date: Thu, 21 May 2009 07:47:37 -0700

> contains deeply-frozen qmail inside as main mail agent.

And that deeply-frozen qmail hasn't been modified to deal with large  
responses?

Regards,
-drc

---

From: bert hubert <[email-masked]>
Date: Thu, 21 May 2009 12:49:59 +0200

On Wed, May 20, 2009 at 11:22 PM, David Conrad <[email-masked]> wrote:
> So, for sake of argument, let's say Microsoft had released software that
> didn't conform to published standards, whereas numerous other vendors had
> implemented according to standard.  You are arguing that the right course of
> action is to revise the standard to match Microsoft's non-standard
> implementation?  In my experience, the IETF has taken the opposite view..

Tis a tricky thing. The scenario George Barwood outlined is a rather
plausible. If I perform what has been described as a harmless step in
joining the future, and sign my zone, and discover I start getting
complaints my mail is bouncing, I will be sorely tempted to unsign my
zone. [1]

DNSSEC was designed to fit the existing DNS infrastructure, and to not
break things.

Should a protocol labelled as such turn out to actually break things
in practice, even if those things had not been as liberal in what they
accepted as it should have been, this should give us pause for
thought.

It may be that the IETF is seen as powerful enough to break existing
installations through standards actions, and get away with it, but I
doubt it.

In effect, qmail is not what we should be worrying about as anybody
running qmail has gotten used to patching it anyhow, and 'the source
is out there'. Legacy email infrastructures however are a different
story.

    Bert

[1] at which point I might discover that 'going back' by itself can
lead to downtime for my entire zone

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 May 2009 12:18:44 -0400

>installations through standards actions, and get away with it, but I

The IETF is powerless.  In my years in the industry IETF goons have 
never broken down the doors and demanded I deploy what's in an RFC 
under any threat.

Organizations will enact a change to their systems if one of these 
two outcomes is anticipated:

   Cost of producing a product or service will drop, raising income
   Revenue from producing a product or service will rise, raising income

An important word there is "anticipated" - organizations know we 
don't have perfect future information.

DNSSEC did not get rolling in-house with the publication of RFCs on 
DNSSEC.  DNSSEC did get rolling when there was a clear incentive to 
go forward.  Did we start knowing all of the pitfalls?  No.  Did we 
know that?  Yes.  What do we include in our plans?  Testing.

The trust anchor redistribution problems documented on a non-IETF 
list not only altered our testing plans (increasing things to test), 
but also have provided contradictory evidence to the commonly held 
belief that DNSSEC will be dropped at the first hint of trouble.

DNSSEC is unapologetically a major change to the DNS.  It ranks up 
there in architectural and operational significance with the addition 
of IXFR and Dynamic Update, above even RFC 2181 and NCACHE.  It's a 
needed upgrade to the protocol, a need evidenced by the effort to 
date to just get this deployed.  DNSSEC is a well-crafted solution to 
a tough problem, grafted onto a security-unfriendly base.  Not only 
did the effort have to contend with poorly prepared definition 
documents (RFCs) but also a host of "in the field architectural 
updates" that were myopic[0] to various degrees.  DNSSEC is not easy 
on the engineers, but that was never the goal.  In presentations I 
gave 18 months ago, before the current push to deploy, even if DNSSEC 
never rolled out at all, we managed to clean up the DNS protocol to a 
great extent.

[0] = short sighted; a term referring to a condition of the eye
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 May 2009 16:48:04 +0000

> > I don't use qmail, the problem is that I still want to receive email
> > from people who are using it, including those who have not updated
> > their systems since 1990, or who are using derivative software,

that option is not on the table, and hasn't been, and not because of DNSSEC.

> contains deeply-frozen qmail inside as main mail agent.

i'd heard that plesk had the "big dns patch" applied many years ago, due
to customer complaints.

---

From: bert hubert <[email-masked]>
Date: Thu, 21 May 2009 19:48:32 +0200

On Thu, May 21, 2009 at 6:18 PM, Edward Lewis <[email-masked]> wrote:
> Organizations will enact a change to their systems if one of these two
> outcomes is anticipated:
>

To the extent this is true (I think you underestimate the lack of
rationality in organizational thinking), be aware that the cost of a
single 'customer problem interaction' is valued at around $7 for large
access providers.

I just measured, I consistently see 200 times fewer ANY queries than
MX queries on a large auth server. Many of these ANY queries indeed
appear to be email related.

So the upper limit of 'huge ANY answer'-problems appears to be 'one in
200 mail lookups'.

    Bert

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 May 2009 14:08:34 -0400

>single 'customer problem interaction' is valued at around $7 for large

I work for a large organization principally because I once felt they 
were irrational and wanted an inside look to see what was going on. 
What I have learned is that organizations are generally more rational 
than singleton human beings - largely because of the built-in checks 
and balances.  Often times an outsider might think a move is 
irrational, but that is usually because the outsider doesn't have the 
whole picture.  And often times an inside might question a move, but 
that is usually because the insider too doesn't have everything 
considered.

I don't get what the $7 figure means to the discussion.

>So the upper limit of 'huge ANY answer'-problems appears to be 'one in

I don't see a point to this observation, nor any supporting 
documentation for that matter.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 May 2009 18:09:42 +0000

> So the upper limit of 'huge ANY answer'-problems appears to be 'one in

there is nothing the DNS community can do to make those ANY queries succeed,
even if we revised RFC 3225, which appears unlikely at best.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 21 May 2009 19:13:07 +0100

> So the upper limit of 'huge ANY answer'-problems appears to be 'one in

Possibly OT for dnsext, but is there available data for number of queries
of a similar type over a many year time period? It would be interesting
to know if, for instance, ANY queries were decreasing over time, whilst
(presumably) MX queries grow.

--
Alex Bligh

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 21 May 2009 11:33:23 -0700

> (presumably) MX queries grow.

Just so there's no confusion, qmail only sends ANY queries to check
for CNAME records.  It still uses MX and A queries when it wants MX
and A records, respectively.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 21 May 2009 19:44:25 +0100

> and A records, respectively.

So if you run an authoritative nameserver, and sign a zone with DNSSEC,
it will only break receiving mail from 10 year old unpatched versions
of qmail if the zone you are signing itself contains a CNAME for an MX
record, which is (AFAIK) non-RFC compliant anyway, and could be fixed
by substituting the CNAME for the relevant A record prior to
signing. Or have I misunderstood?

(My original question was more directed at determining whether what is
x% this year will be y% next year, where y<x)

--
Alex Bligh

---

From: Tony Finch <[email-masked]>
Date: Thu, 21 May 2009 20:20:08 +0100

> appear to be email related.

That's an uncomfortably high proportion.

I've had a brief glance at the code and it looks like (unpatched) qmail
will be OK, since it only does ANY lookups when searching for CNAME
records in order to canonicalize a domain just before doing an MX lookup.
If the CNAME reply is truncated it should be alright so long as the DNSSEC
records are dropped not the CNAME record.

Tony.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 May 2009 15:22:54 -0400

At 21:04 +0200 5/21/09, bert hubert wrote:

>It means that a rational organization will weigh the impact of even a
>1% degradation of service very heavily if it means having to deal with
>all the people impacted by that 1%.

...

>It is sad that doing relevant measurements now elicits a response
>declaiming the lack of supporting documentation or 'point'.

What's wrong with asking for more info?  Displaying results of 
germane measurements is indistinguishable from plucking numbers from 
air without any means for the reader to verify the numbers.

E.g., what's a 1% degradation in service?  And how does an X% 
"degradation" imply there will be the same X - X% of customers 
calling in?

Having a point is good.  Without one, this list is just a pointless time sink.

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 21 May 2009 13:06:27 -0700

> records are dropped not the CNAME record.

No, if the CNAME response packet's answer section exceeds 512 bytes,
then parsing it will fail, and qmail will give up on trying to deliver
the message to try again later.  If you build the dnscname program
from qmail-1.03 ("make dnscname") and then run "dnscname isc.org"
using a DNS cache like BIND that returns all records it has in cache
in response to an ANY query, you'll get a soft error.  (You might run
"dig -t rrsig isc.org" first to ensure the RRSIG records are in cache,
and then run "dig -t any isc.org" to make sure the cache includes them
in the response to ANY queries; e.g., dnscache only returns NS records
in response to an ANY query for isc.org, so qmail would be able to
still deliver email to isc.org if configured to use dnscache instead
of BIND.)

---

From: bert hubert <[email-masked]>
Date: Thu, 21 May 2009 22:48:21 +0200

On Thu, May 21, 2009 at 9:22 PM, Edward Lewis <[email-masked]> wrote:
> What's wrong with asking for more info?  Displaying results of germane
> measurements is indistinguishable from plucking numbers from air without any
> means for the reader to verify the numbers.

It is indeed indistinguishable if the assumption is that this list is
inhabited by crooks and mountebanks that are wont to pluck numbers
from thin air and pass them off as credible measurements.

But if you want to reproduce, take an authoritative server, and run:
# tcpdump -i eth0 -n -s 0 -w dump3  port 53
$ /usr/sbin/tcpdump -n -r dump3 host 85.17.220.217 | grep -c "MX?"
109565
$ /usr/sbin/tcpdump -n -r dump3 host 85.17.220.217 | grep -c "ANY?"
1175
$ /usr/sbin/tcpdump -n -r dump3 host 85.17.220.217 | grep -c "? "
3866148

I previously made the mistake of searching for 'MX' and 'ANY' instead
of 'MX?' and 'ANY?', which artificially deflated the number of ANY
queries, since 'MX' matches both question and response, but 'ANY'
questions never get 'ANY' answers.

So the correct number from this one admittedly naive measurement is
that the ratio of MX queries to ANY queries is around 100:1.

    Bert

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 May 2009 09:12:32 +1000

In message <[email-masked]>, bert 
hubert writes:
> > What's wrong with asking for more info? =A0Displaying results of germane
> > measurements is indistinguishable from plucking numbers from air without =
> any

	Which has no relevence to the number of unpatched qmail
	MTA's vs working MTA's (qmail and others).

	Mark

---

From: Emilio Perea <[email-masked]>
Date: Thu, 21 May 2009 20:53:56 -0500

> and A records, respectively.

So you would have a problem receiving mail from unpatched qmail servers
which do not use dnscache (which I suspect is a very small percentage).
But only if you are foolish enough to use a CNAME instead of proper MX
and A records.  As a long-time qmail user, I don't see that as a big
problem.

If it ever becomes a problem, we'll fix it.  I can't say I'm fond of
DNSSEC, but I'm not particularly worried about it either.

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 21 May 2009 19:25:52 -0700

> which do not use dnscache (which I suspect is a very small percentage).

Yes.

> and A records.

No, the CNAME queries are distinct from the MX/A queries.

The CNAME queries are so qmail can rewrite [email-masked] to [email-masked]
if there's a CNAME record for "foo.com CNAME box.net".

The MX/A queries are so qmail can determine what IP address to connect
to when delivering mail to a certain domain's mail servers.

When qmail sends mail to another server, these queries will always be
for the same domain name, but the code that actually handles this
makes no such assumption.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 May 2009 02:45:59 +0000

> Date: Thu, 21 May 2009 19:25:52 -0700
> From: Matthew Dempsky <[email-masked]>
> ...

so, if there's no A or AAAA or MX RR at the target, the rewrite will be
from an undeliverable name to some other undeliverable name, which is
meaningless.

if qmail really wants to rewrite these names it should make RFC 974 style
queries (that is, for MX, then for A, and i guess for AAAA) and if it
gets a CNAME as part of the response it should do the rewrite.

there's nothing gained by the CNAME (or ANY) queries in this case.

but we digress.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 May 2009 13:16:49 +1000

> gets a CNAME as part of the response it should do the rewrite.

	Actually the rewrite code only needs to do a MX query.  If there
	is a CNAME it will be returned regardless of whether there is 
	a MX record or not.  In either case the local recursive server
	now knows whether there is a MX record or not.
 
> there's nothing gained by the CNAME (or ANY) queries in this case.

	Indeed.

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 21 May 2009 20:16:22 -0700

> from an undeliverable name to some other undeliverable name, which is

Sure, whatever.  I'm not arguing for its behavior, I'm just trying to
explain it so people worried about being compatible with its behavior
actually know what they need to be compatible with.

> gets a CNAME as part of the response it should do the rewrite.

I tried to be clear in my last email, but apparently not well enough.

In the qmail package, there's a program "qmail-remote".  It's invoked
by running "qmail-remote host sender recip [ recip ...]", and
providing an RFC 822 message on stdin.  E.g., to send a message to
isc.org's mail servers with an envelope from [email-masked] to
[email-masked], I would invoke it:

    qmail-remote isc.org [email-masked] [email-masked] < message

Because RFC 821 does not allow domain aliases in email addresses in
the envelope, qmail-remote needs to make sure [email-masked] is in
canonical form; it originally did this by making a CNAME query for
isc.org, but later changed to making an ANY query for isc.org, to be
compatible with sendmail's behavior at the time.

After converting all recipient addresses to canonical form,
qmail-remote then does the standard MX/A record lookups on the host
argument, which in the above use case *happens* to also be isc.org.

However, it would be perfectly acceptable for qmail-remote to be invoked as:

    qmail-remote gmail.com [email-masked] [email-masked] < response

Now qmail-remote does an ANY query for dempsky.org to ensure
[email-masked] is in canonical form, followed by MX/A queries for
gmail.com to find what mail servers to contact.  (The qmail package
would never pass invoke qmail-remote in such a way that the domain
names queried for are different, but qmail-remote does not make that
assumption.)

> there's nothing gained by the CNAME (or ANY) queries in this case.

Sure, but that's what the SMTP RFCs required at the time qmail was
written.  See http://cr.yp.to/im/cname.html.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 May 2009 13:40:11 +1000

In message <[email-masked]>, Matthew Demps
> compatible with sendmail's behavior at the time.

	Where as a MX query would have done the same thing and
	removed a redundant query from the processing.
 
> written.  See http://cr.yp.to/im/cname.html.

	No, they don't require a CNAME query.  They require the
	name not be a alias.  This can be satisfied without performing
	anything other than MX and A (and now AAAA) queries.
 
	Mark

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 21 May 2009 20:53:12 -0700

On Thu, May 21, 2009 at 8:16 PM, Matthew Dempsky <[email-masked]> wrote:
> [overly detailed explanation]

When qmail needs to deliver a message for [email-masked] over SMTP, it
performs an ANY query for domain.com.  If the DNS cache's response
packet's answer section exceeds 512 bytes, the delivery attempt will
soft fail, an error message will be written into qmail's logs, and the
message will eventually bounce.

It doesn't matter why or that it could do things differently.  This is
what it does.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 May 2009 04:09:58 +0000

> Date: Thu, 21 May 2009 20:16:22 -0700
> ... I'm just trying to explain it so people worried about being
> compatible with its behavior actually know what they need to be
> compatible with.

thanks for that.

> compatible with sendmail's behavior at the time.

sendmail's behaviour was horrid.  i fought on the side of "make the MX
and/or A query you would make to find RFC 974 deliverability, and if
you get a CNAME chain back, use it for rewrites.

> written.  See http://cr.yp.to/im/cname.html.

according to...

http://www.amazon.com/Sendmail-Theory-Practice-Frederick-Avolio/dp/1555581277/ref=sr_1_1?ie=UTF8&s=books&qid=1242965145&sr=8-1

...i was alive and well and working in the SMTP field in the old days, and
i can tell you that the SMTP RFC's of that era did not require that an ANY
query be made.  canonicalization can be done in several other ways.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 May 2009 14:20:41 +1000

In message <[email-masked]>, Matthew Demps
> message will eventually bounce.

	Good.  Unpatched qmail is broken and should be removed from
	the net.  Breaking email deliver, in this case, is a good
	thing.  It will increase the overall health of the global
	email system.
 
	Mark

---

From: Florian Weimer <[email-masked]>
Date: Fri, 22 May 2009 07:54:42 +0200

> even if we revised RFC 3225, which appears unlikely at best.

Server could be changed to return only RFC 1035 RR types in the result
(plus AAAA perhaps).

Until now, I didn't realize that BIND includes the RRSIG and NSEC
records from a signed parent zone in the answer sectin (see aol.se for
an example).  Isn't this in violation of RFC 2181?  It doesn look like
a good idea to me.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 May 2009 16:45:50 +1000

> Server could be changed to return only RFC 1035 RR types in the result

	Which *still* wouldn't prevent a unpatch qmail from falling over.
 
> an example).  Isn't this in violation of RFC 2181?

	No.  Both the parent and child are authoritative for NSEC.
	
> It doesn look like a good idea to me.
> 
> --

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 May 2009 14:49:58 +0000

> From: Florian Weimer <[email-masked]>
> Date: Fri, 22 May 2009 07:54:42 +0200
> 
> > there is nothing the DNS community can do to make those ANY queries
> > succeed, even if we revised RFC 3225, which appears unlikely at best.
> 

those ANY queries are picking up some SPF TXT RRsets, plus some large
A and AAAA RRsets, and are already failing.  so even if we rev'd RFC 3225
(which is unlikely) and even if every server who has DNSSEC types on board
were to upgrade (which is even more unlikely) then this problem would remain.

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Fri, 22 May 2009 11:29:19 -0400

Please stop posting on this topic the discussion it is not going anywhere.

         Olafur

---

From: Florian Weimer <[email-masked]>
Date: Fri, 22 May 2009 18:18:27 +0200

* Paul Vixie:

> those ANY queries are picking up some SPF TXT RRsets, plus some
> large A and AAAA RRsets, and are already failing.

The difference is that DNSSEC records are forced upon you by the
parent zone.  You can carefully control those other records if you
fear the eyeball hit.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 21 May 2009 20:16:25 +0200

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

* George Barwood:

> I don't see how ANY can be taken as an explicit indiciation that the
> resolver understands DNSSEC RRs, that's clearly not the case, so
> there is inconsistency.

Records at the QNAME of a query with QTYPE ANY are not DNSSEC records
in the sense of RFC 3225.

---

From: bert hubert <[email-masked]>
Date: Thu, 21 May 2009 21:04:30 +0200

Ask someone over at a large access provider about how they feel about
doing any change that might cause 1% of their customers to contact
them. As an example, over at a large access provider I once changed
the rounding algorithm used to determine if a mail user was over
quota, which in turn overwhelmed the helpdesk until we changed back
the rounding algorithm so it would round down again.

Life as seen from a registry or a registrar might very well be very
different - I haven't worked at one.

> I don't see a point to this observation, nor any supporting documentation
> for that matter.

The point is that I measured that there are indeed some ANY queries
occurring, but that that they are dwarfed by the amount of MX queries.
This is relevant to the preceding discussion.

It also actually supports the point that returning all records on a
DO=0 query, including the DNSSEC ones, is unlikely to trip over many
email related lookups.

   Bert