Re: [DNSOP] CloudFlare policy on ANY records changing
* 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 QTYPE=* queries in the first place? Yes, I do. They don't need to understand it, they just need to be able to receive it without choking. Correct, or not too much choking. Entering a fallback path is acceptable and the desired behavior (if you can speak of such in this context). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
* 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 with a type from the private use range (e.g. TYPE65531 or whatever), zero length rdata, and a long TTL. Maybe this could be a use for the NULL RRtype? :-) 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 DNS.” is not confidence-inspiring in this regard. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
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 DNS.” is not confidence-inspiring in this regard. On the other hand, it saves us the grief of allocating a code point, and it has an intuitive name: if I saw a NULL RR in a cache dump I'd immediately guess it was a placeholder. Your point is well taken, but if that hypothetical resolver behavior turns out not to commonplace, then I say let's run with it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
* 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 response all the time. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
* 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
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 the first place? They don't need to understand it, they just need to be able to receive it without choking. 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 with a type from the private use range (e.g. TYPE65531 or whatever), zero length rdata, and a long TTL. The resolver would get an answer, so it stops asking; it would *not* cache the answer as an empty node, so subsequent queries for other qtypes can still resolve. I like this better than any of the prior suggestions. (It doesn't address qmail's problem, but that's a lost cause no matter which method is chosen.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
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 :-) But you are right it needs to work for unsigned zones. NOERROR/NODATA responses to ANY will not work well. I did a quick test consisting of: dig any non.terminal # initially empty (echo 'update add non.terminal 3600 in txt braaains'; echo send) | nsupdate -l dig txt non.terminal For both signed and unsigned zones, the first query make BIND create a negtive cache entry which covers all types, so it doesn't recurse for the second query. This will make qmail fail deliveries with a permanent error. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South Utsire, Forties, Cromarty, Forth, Tyne, Dogger: Southerly or southeasterly 6 to gale 8, occasionally severe gale 9 in Forties, Cromarty and Forth, becoming variable 4 for a time. Moderate or rough, occasionally very rough at first in Forties, Cromarty and Forth. Rain for a time. Good, becoming moderate or poor for a time. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
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 we're losing. if we're serious about redefining ANY as a meta-query, then answering with RCODE=0/ANCOUNT=0 is correct. (as it would be for RD=0 queries against an RA=1 server.) but whatever we do, any new reaction to QTYPE=ANY has to ensure that the client gives up, and stops asking. I for one am concerned about doing away with QTYPE=ANY and would like to see something more along the lines of authorities returning results so dig +trace works for diagnosis. Perhaps building better tools for this which might remove my concern around ANY, that way it can iterate through various QTYPEs for me. - jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
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 NODATA. These are signed zones so the answer has to validate. Perhaps the answer should be just the NSEC(3) and RRSIG(NSEC(3)) records matching the QNAME, which is a plausible way to say, yes we have records here even though this answer doesn't contain them. i love this plan. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
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 existing clients, who only look for rcodes they understand. If you want to respond to ANY with NOTIMP/REFUSED, would you also be willing to include an OPT RR in your response (when appropriate)? as i wrote in http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/... ... So I know that we send REFUSED in response to a query when we don't like the client's IP address --- DNS servers do not even look at the question before deciding whether to send REFUSED. On the client side, if we hear a REFUSED we give up on that server and move on to the next server --- which means we assume that it was the client's IP address that the server is refusing, not the question we happened to be asking at that moment. Microsoft Windows will actually de-preference a name server if they hear too many REFUSED messages from it --- so BIND is not the only DNS software that interprets REFUSED in this way. What this boils down to is that REFUSED is all about the relationship between the client and the server, and has nothing to do with the particular question being asked. If SOPA or PIPA becomes law with a requirement to signal REFUSED when someone looks up an infringing or pirate domain name, then in the language of DNS we will be saying please stop asking this server any questions at all. There is no signal in DNS that means that's a bad question but please feel free to ask other questions. 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 we're losing. if we're serious about redefining ANY as a meta-query, then answering with RCODE=0/ANCOUNT=0 is correct. (as it would be for RD=0 queries against an RA=1 server.) but whatever we do, any new reaction to QTYPE=ANY has to ensure that the client gives up, and stops asking. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
