* Evan Hunt:
On Thu, Mar 12, 2015 at 11:38:04PM +, Darcy Kevin (FCA) wrote:
So you're thinking it's more likely that we'll get folks to understand
this new type, that's designed to frustrate QTYPE=* queries in a
more-or-less graceful way, than it is to convince them to stop making
* Tony Finch:
Evan Hunt e...@isc.org wrote:
This could be a pretty brilliant solution, actually: If you're
authoritative for a signed zone and you receive a query of type ANY,
return the applicable NSEC/NSEC3; if the zone is *not* signed, synthesize
a response containing a single RR
On Sat, Mar 14, 2015 at 09:10:03PM +0100, Florian Weimer wrote:
We'd have to be reasonably sure that no resolver treats is as a
meta-type and turns the upstream response into a FORMERR upon seeing
it in the answer section. “NULLs are used as placeholders in some
experimental extensions of the
* Evan Hunt:
(It doesn't address qmail's problem, but that's a lost cause no
matter which method is chosen.)
I think it does. qmail already copes correctly with a partially
cached ANY response (due to TTL mismatch between RRset), does it?
The new behavior just looks like a partially cached
On Wed, Mar 11, 2015 at 12:13:42PM +, Tony Finch wrote:
These are signed zones so the answer has to validate.
... they are? I thought the proposal was to restrict/deprecate
qtype=ANY for all zones, not just signed ones.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
* Tony Finch:
I also tried a stupid hack to send an ANY RR in the response. BIND's
resolver treats this as a FORMERR and returns SERVFAIL to the client.
What about introducing a new non-meta RR type for this purpose? It
would not increase the response size by much.
On Thu, Mar 12, 2015 at 11:38:04PM +, Darcy Kevin (FCA) wrote:
So you're thinking it's more likely that we'll get folks to understand
this new type, that's designed to frustrate QTYPE=* queries in a
more-or-less graceful way, than it is to convince them to stop making
QTYPE=* queries in
Evan Hunt e...@isc.org wrote:
On Wed, Mar 11, 2015 at 12:13:42PM +, Tony Finch wrote:
These are signed zones so the answer has to validate.
... they are? I thought the proposal was to restrict/deprecate
qtype=ANY for all zones, not just signed ones.
At least some of them are signed
On Mar 10, 2015, at 8:05 PM, Paul Vixie p...@redbarn.org wrote:
we are, in this case, defining a protocol. our goal is to get the client to
stop asking the ANY question. if we send is a signal that sounds right
(REFUSED, for example) but merely has the effect of go to next server then
Tony Finch wrote:
Evan Hunt e...@isc.org wrote:
I'm concerned that a NOERROR/NODATA for qtype=ANY, once cached, would be
identical to the cache representation of an empty nonterminal node, and
that all subsequent queries for any other qtype would then be answered
with the cached
On Mar 10, 2015, at 9:34 AM, Paul Hoffman paul.hoff...@vpnc.org wrote:
On Mar 10, 2015, at 8:46 AM, David C Lawrence t...@akamai.com wrote:
Paul Hoffman writes:
On Mar 10, 2015, at 6:25 AM, Yunhong Gu g...@google.com wrote:
So the problem is, why NOTIMP? REFUSED sounds like a better
Wessels, Duane mailto:dwess...@verisign.com
Wednesday, March 11, 2015 6:19 AM
As Paul suggests, I'll attempt to redirect the conversation to dnsop.
Does it make sense to define an Extended RCODE for additional signaling?
e.g. REFUSED_BECAUSE_QTYPE_ANY
no, because the problem is with
12 matches
Mail list logo
