Re: [DNSOP] Fwd: New Version Notification for draft-ogud-dnsop-any-notimp-00.txt

Ralf Weber <> Fri, 06 March 2015 22:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3E0931A03A5 for <>; Fri, 6 Mar 2015 14:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.847
X-Spam-Level: **
X-Spam-Status: No, score=2.847 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, HOST_EQ_STATICB=1.372, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hWGnMDavrjxH for <>; Fri, 6 Mar 2015 14:34:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 086F71A02BE for <>; Fri, 6 Mar 2015 14:34:16 -0800 (PST)
Received: by (Postfix, from userid 107) id 9B5C15F40EAA; Fri, 6 Mar 2015 23:34:13 +0100 (CET)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4CD3F5F40E75; Fri, 6 Mar 2015 23:34:12 +0100 (CET)
Date: Fri, 06 Mar 2015 14:33:36 -0800
From: Ralf Weber <>
To: Paul Vixie <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Cc: Olafur Gudmundsson <>,
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-ogud-dnsop-any-notimp-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Mar 2015 22:34:17 -0000


On Fri, Mar 06, 2015 at 01:51:53PM -0800, Paul Vixie wrote:
> that's a big "if". here's another: if your diagnostic tools can use some
> method other than "dig" to do your debugging for you, then, again, you
> don't need ANY. those are two very big "if"'s.
I can answer them with yes, so I think I'm good. I do need dig for lots
of stuff, but not to find out what records at a give node my resolver

> >  I would like to see it deprecated to
> > the level that no one relies on the query being answered with a record.
> me too. that's why i'm saying, ACL, default "nobody".
ACL is something application specific. There may be applications that
may want to have a default behavior, thus we should not put ACL in the
draft. The only thing to define in the draft is to what a requester
can expect when issuing a ANY query.
> > So even the resolver can answer with NOTIMP. 
> any RCODE other than 0 or 3 will cause spectacularly bad storms. i
> prefer RCODE=0/ANCOUNT=0 to refuse "ANY".
That would look confusing to me as it looks like an valid answer.
NOTIMP looks clearer to me. What do you think this will cause given 
that we want to get people of off it?

> i heard several people enumerate the TCP initiators they could think of,
> when arguing about whether to change the client's behaviour to
> "keepopen". as i said there-- our ability to enumerate means precisely
> nothing: if someone somewhere coded a reasonable expectation based on
> RFC text and tested to work, then we have to act as if there are an
> unknown, and treat as unknowable, but real and relevant set of users of
> that encoding.
I really could not parse or understand this. After reading it a couple of
times I think that I say:
     There is no reason to use RRSIG queries in a validator
and you say:
     It is not forbidden to use RRSIG queries in a validator
both are true. We can't stop people from doing unreasonable things.

> if you want to change how DNSSEC works, i'll listen. but there's no
> reasonable interpretation of past or current specifications by which
> QTYPE=RRSIG can be categorized a "meta-query". (unlike
> QTYPE=ANY/IXFR/AXFR, or RD=0 when speaking to a recursive-only server.)
I never said that RRSIG is a meta query. I said that implementing RRSIG
is as hard as implementing ANY with regard to the aspect that you have
to use/look for more than one query type, which is different from
all other query types.

> you could multiply all those numbers by six trillion, and they would
> still not be relevant to the standard of care by which the DNS
> specification must evolve.
Yeah I noticed over the years that people were very concerned on even
minor changes. Yet when I look at all the things that implementations
of DNS servers did that were against the specs and others had to work
around, maybe sometimes a disruptive change is good. One of the point
of the numbers was to show that so far people have been reasonable 
about RRSIG.

So long