Re: [DNSOP] draft-ietf-dnsop-refuse-any

[tjw ietf]

The Badgering will continue!

We're waiting because the chairs feel we can do a short WGLC and have this
ready to go before London.

Thank you all for adding pressure.

Tim

On Mon, Feb 12, 2018 at 10:41 AM, Joe Abley  wrote:

> On 12 Feb 2018, at 06:30, Tony Finch  wrote:
>
> > Paul Wouters  wrote:
> >>> On Feb 9, 2018, at 20:22, Joe Abley  wrote:
> >>>
> >>> I aim to get it done before next week.
> >>
> >> Awesome! Thanks!
> >
> > And from me too - I was wondering about this draft the other day,
> > so thanks Paul for prodding before I got a round tuit.
>
> For various reasons I didn't in fact get it done before this week, but
> it's definitely on the to-do list.
>
>
> Joe
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any

[Joe Abley]

On 12 Feb 2018, at 06:30, Tony Finch  wrote:

> Paul Wouters  wrote:
>>> On Feb 9, 2018, at 20:22, Joe Abley  wrote:
>>> 
>>> I aim to get it done before next week.
>> 
>> Awesome! Thanks!
> 
> And from me too - I was wondering about this draft the other day,
> so thanks Paul for prodding before I got a round tuit.

For various reasons I didn't in fact get it done before this week, but it's 
definitely on the to-do list.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any

[Tony Finch]

Paul Wouters  wrote:
> > On Feb 9, 2018, at 20:22, Joe Abley  wrote:
> >
> >  I aim to get it done before next week.
>
> Awesome! Thanks!

And from me too - I was wondering about this draft the other day,
so thanks Paul for prodding before I got a round tuit.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Fair Isle, Faeroes: Cyclonic, mainly south or southeast for a time, 5 to 7,
increasing gale 8 or severe gale 9 for a time. Very rough or high. Wintry
showers. Moderate or poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any

[Paul Wouters]

> On Feb 9, 2018, at 20:22, Joe Abley  wrote:
> 
> Hi Paul,
> 
> This draft is waiting for me to commit changes to and submit a revised draft.
> 
>  I aim to get it done before next week.

Awesome! Thanks!

Paul


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any

[Joe Abley]

Hi Paul,

This draft is waiting for me to commit changes to and submit a revised draft.

My co-author and our esteemed chairs have been badgering me with full 
efficiency, and the delay is all my fault. I have some time this weekend so 
long as I don't have to deal with another metre of snow, and I aim to get it 
done before next week.


Joe

> On Feb 9, 2018, at 15:30, Paul Wouters  wrote:
> 
> 
> draft-ietf-dnsop-refuse-any
> 
> Didnt this reach the end of WGLC ?
> 
> The draft expired.
> 
> Don't we all really still want this?
> 
> Paul
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Paul Vixie]

Ray Bellis wrote:

... returning NOTIMP for ANY queries, ...

...

My reading of RFC 1035 is that it would be a perfectly appropriate
response from a server that doesn't support ANY.


the RFC was treated as a general guideline by most implementers, and 
once the code for some client or server appeared to work, it was 
shipped. it is that code which constraints our work now, not the RFC.



Unfortunately the retry semantics of DNS are not well specified and
therefore implementation differences may occur. If as a result NOTIMP
is really not usable then IMHO this should also be documented.


i think you'll find that NOTIMP causes try-next-server for many clients, 
but without poisoning, so if all servers return NOTIMP, then all those 
same servers will be tried again, without delay.


sometimes, withholding a response is the only way to keep the client out 
of this bombardment-mode. sometimes returning something poisonous like 
ANCOUNT=0 is nec'y. again, our guide today is how to get clients to do 
something constructive, ideally constructive for both them and us. it 
doesn't have to be true, and it doesn't have to be documented in an 
older RFC.


i agree that writing a new RFC whenever something like this is found to 
be necessary, and putting into that RFC more specific advice to client 
implementers so that the future might possibly improve, is a great idea.


-- P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Paul Vixie]

Ray Bellis wrote:

... returning NOTIMP for ANY queries, ...

...

My reading of RFC 1035 is that it would be a perfectly appropriate
response from a server that doesn't support ANY.


the RFC was treated as a general guideline by most implementers, and 
once the code for some client or server appeared to work, it was 
shipped. it is that code which constraints our work now, not the RFC.



Unfortunately the retry semantics of DNS are not well specified and
therefore implementation differences may occur.  If as a result NOTIMP
is really not usable then IMHO this should also be documented.


i think you'll find that NOTIMP causes try-next-server for many clients, 
but without poisoning, so if all servers return NOTIMP, then all those 
same servers will be tried again, without delay.


sometimes, withholding a response is the only way to keep the client out 
of this bombardment-mode. sometimes returning something poisonous like 
ANCOUNT=0 is nec'y. again, our guide today is how to get clients to do 
something constructive, ideally constructive for both them and us. it 
doesn't have to be true, and it doesn't have to be documented in an 
older RFC.


i agree that writing a new RFC whenever something like this is found to 
be necessary, and putting into that RFC more specific advice to client 
implementers so that the future might possibly improve, is a great idea.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Ray Bellis]

On 07/08/2017 16:44, Ólafur Guðmundsson wrote:

> This was the original proposal, 
> the drawback is that resolvers to not cache the answer, and to make
> things worse they ask ALL NS addresses for listed domain 
> thus it acts as a DDoS against the domain in question.  

Indeed - I've since confirmed that BIND does this.

I think my point still stands that this behaviour should be documented
in the section that talks about a possible new RCODE and why that option
was rejected.

kind regards,

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Ólafur Guðmundsson]

This was the original proposal,
the drawback is that resolvers to not cache the answer, and to make things
worse they ask ALL NS addresses for listed domain
thus it acts as a DDoS against the domain in question.

Olafur


On Mon, Aug 7, 2017 at 7:14 AM, Ray Bellis  wrote:

> Having looked at this a few months ago when one of our partners was
> (briefly) returning NOTIMP for ANY queries, I find myself wondering why
> this isn't discussed in the draft?
>
> The draft does talk about *new* RCODEs, but not existing ones.
>
> My reading of RFC 1035 is that it would be a perfectly appropriate
> response from a server that doesn't support ANY.
>
> Unfortunately the retry semantics of DNS are not well specified and
> therefore implementation differences may occur.  If as a result NOTIMP
> is really not usable then IMHO this should also be documented.
>
> Ray
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Petr Špaček

[Petr Špaček]

On 26.7.2017 12:56, Tony Finch wrote:
> Joe Abley  wrote:
>>
>> If anybody else here has thoughts about specific text or violent
>> objections to including QTYPE=RRSIG in general, please let me know (I
>> looked in the mail archive but couldn't find any there).
> 
> I think it's helpful to mention RRSIG explicitly since it isn't
> immediately obvious that it's a stealth ANY query. (It becomes
> apparent to implementers fairly rapidly tho!)
> 
>> As we discuss (see Stephane's points) in the case of multiple
>> transports, perhaps we can also recommend that implementors provide
>> configuration options to allow administrators to deal with ANY, RRSIG,
>> neither or both. That way we get flexibility that matches deployment,
>> but we also get a reference for handling RRSIG in a predictable way.
> 
> I think the draft should recommend a simple on/off switch and describe
> sensible behaviour when it is on. Mainly because I think we know what
> that sensible behaviour is, and I don't think it's a big enough feature
> to deserve a lot of configuration and documentation complexity.

I agree with Tony that we know what that sensible behaviour is so, with
my implementor hat on, I would be perfectly happy with
implementation-specific behavior with no knobs at all. If you don't like
it, feel free to pick another implementation.

Petr Špaček  @  CZ.NIC

> 
> Having said that, the initiator side (section 5) needs a bit of work.
> Something like,
> 
>ANY queries SHOULD be sent using the same choice of transport as other
>queries (typically, try UDP first, and only use TCP if the response is
>truncated). As an exception, debugging and diagnostics tools MAY have
>a special case for ANY queries.
> 
> (bleeding-edge versions of `dig` use TCP for ANY)
> 
> Tony.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from 神明達哉

[神明達哉]

Hi, sorry for the delayed response.

At Tue, 25 Jul 2017 16:53:12 -0400,
Joe Abley  wrote:

>   https://mailarchive.ietf.org/arch/msg/dnsop/zy86pvg139PaKFXo-BO6SPUfh3k
>
> > I've reviewed the 04 version.  I still do not think it's ready to move
> > forward as it still abuses HINFO.  I understand some other people
> > don't care about this point, and some others may even love the idea
> > (those who are using it right now).  But I've also seen yet some other
> > people have the same concern, so it shouldn't be only me.  I don't
> > think we have a clear consensus on this point yet.
>
> The draft at present doesn't require an implementer to abuse HINFO;
> it provides options to avoid doing so whilst still meeting the
> described objectives of the proposal. Since abusing HINFO is not
> mandatory, I presume you are objecting to the proposal sanctioning
> such shenanigans at all.

(If I understand the subtle nuance of this text:-) I think your
understanding is correct.
>
> If I have that right (please correct me if I'm wrong) I don't think
> I am the right person to make the call, being just a lowly document
> scribe. If this remains a concern for you, I suggest that we defer
> that question to our chairs and ask them to gauge consensus. My own

Agreed - I think we have to agree to disagree here and I think neither
of us can convince the other.  It should better be left to the wg
decision.

> personal views of pragmatism vs. elegance shouldn't enter into it;
> this is a working group document.

> > To be hopefully a bit more productive, I have a specific counter
> > proposal: remove the mandatory text about the use of HINFO, e.g.,
> >
> > - remove this bullet from section 4
> >2.  A DNS responder can return a synthesised HINFO resource record.
> >See Section 6 for discussion of the use of HINFO.
> > - remove ', in which case...' from Section 4.2
> >If there is no CNAME present at the owner name matching the QNAME,
> >the resource record returned in the response MAY instead be
> >synthesised, in which case a single HINFO resource record SHOULD be
> >returned.
> >
> > In fact, in terms of externally observable behavior, synthesizing
> > HINFO is just one form of "selecting one RRset of the QNAME"; the
> > HINFO is added and immediately removed at the time of answering the
> > ANY query, so in that sense we don't have to bother to mention it with
> > normative keywords.
>
> This text suggests that my interpretation above is wrong, and what
> you are objecting to is just the way that the HINFO approach is
> described. I think the specification is more clear if we spell out
> the whole synth-HINFO approach in its entirety and don't try to
> subsume it into the "return a subset of { RRSets that there } u {
> RRSets that we just synthesised }".

(As I said above) I believe you interpreted my objection correctly.
This suggestion was an attempt of compromise, assuming people already
(ab)using HINFO want to continue their practice.

[...]

> I am not sure I understand the benefit of not including it, given
> that it is observable behaviour for a large number of domains today
> (even if that is so due to the volume of domains hosted at a single
> operator). I think we do better service to operators and
> implementors by describing what is implemented. As you point out,
> Cloudflare's implementation may be less general-purpose than BIND9
> or NSD, and that might be a reason for the implementation choices to
> be different. Cloudflare is unlikely to be the last non-general
> implementation, however, so perhaps the mechanism most appropriate
> there will be relevant to others.

I agree that being silent for existing deployment may not be ideal.
If we (wg) can reach a consensus that the HINFO-based approach is an
abuse, however, we can think of other way to address it.  For example,
we could mention it and clarify that it should be considered an abuse,
should be discouraged, and newer implementations should use other
approaches.  My suggestion was just based on the anticipation that we
can probably not reach this kind of consensus (especially about the
discouragement).

> > I've also noticed a couple of other points I raised in my previous
> > review (
> > https://www.ietf.org/mail-archive/web/dnsop/current/msg18746.html
> > )
> > were not yet addressed.  These are (section numbers are for 03):
> >
> > - Section 3
> >
> >1.  A DNS responder can choose to select one or subset of RRSets at
> >the QNAME.
> >
> >   'one or subset of RRSets' sounds a bit awkward to me
>
> I agree. Perhaps "One or more of the RRSets at a QNAME". "... or a subset" 
> seems wrong, actually; since some vestigial fragment of a set theory lecture 
> in the depths of my pre-history is telling me that the empty set is always a 
> valid subset.
>
> > - Section 4
> >
> >A DNS responder which receives an ANY query MAY decline to provide a
> >conventional response, or MAY instead send a response with a single
> 

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

[Tony Finch]

Joe Abley  wrote:
> On 26 Jul 2017, at 13:28, Richard Gibson  wrote:
> >
> > I remain concerned about issuing incomplete responses to ANY queries
> > without indication of such, and predict that it will hinder
> > operational problem investigation and remediation (especially
> > pertaining to IPv4/IPv6 issues).
>
> OK. Your future tense is Cloudflare's past tense and I have not heard of
> an example of the kind of operational confusion that you're predicting
> there, but perhaps I'm just not listening in the right dark corners.

The only minimal-any confusion I have experienced recently was when the
BIND 9.12 development version of `dig` started using TCP for ANY queries
which made me think minimal-any wasn't working properly :-) But I think
in most cases this change will reduce the confusion Richard is worried
about.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Portland, Plymouth: Westerly 4 or 5, increasing 6 at times in north. Moderate,
occasionally rough in west Plymouth. Showers. Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

[Joe Abley]

On 26 Jul 2017, at 14:50, Richard Gibson  wrote:

> Yes, color me corrected on vocabulary but unconvinced on interference... 
> those slides seem to mostly demonstrate noncompliance by name servers 
> theirselves with respect to EDNS data in queries, whereas the data I'm 
> suggesting would only appear in responses.

My recollection was that the machinery Mark was using wouldn't distinguish 
between problems caused by nameservers and problems introduced by middleware, 
but it *was* a while ago. Anyway, I'm not arguing so much as trying to explain 
myself, and...

> That works. And I'm all out, so you're safe from me.

... thanks for that.

> Strikethrough and bold, eh? OK. :-) Suggestions are good, many thanks!
> 
> Ha! I'll use Markdown conventions in the future.

That would be a significant sideprovement.


Joe "text/plain" Abley

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

[Richard Gibson]

On Wed, Jul 26, 2017 at 2:24 PM, Joe Abley  wrote:

>
> On 26 Jul 2017, at 13:28, Richard Gibson  wrote:
>
> > The need for such a signal also came up recently in
> https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-
> responses-05#section-10 . But in this case particularly, middleboxes
> should be a complete non-issue... anyone expecting QTYPE=ANY passthrough is
> already asking for trouble.
>
> We may be imagining different things by "middlebox" -- I think you're
> thinking of a resolver, whereas I'm thinking more broadly about stateful
> inspection, firewalls, ALGs, proxies, forwarders, etc. I think there's an
> entirely reasonable and observable expectation that QTYPE=ANY passthrough
> works in that broader sense. Mark's  proceedings/92/slides/slides-92-dnsop-7.pdf> was an easy-to-find example
> of trouble in the real world.
>

Yes, color me corrected on vocabulary but unconvinced on interference...
those slides seem to mostly demonstrate noncompliance by name servers
theirselves with respect to EDNS data in queries, whereas the data I'm
suggesting would only appear in responses.

I will plan to add text to acknowledge the lack of signalling but not to
> change the mechanism to introduce any. People should throw rocks if that
> seems bad.


That works. And I'm all out, so you're safe from me.

> 2. Section 4.1 appears to have some errors in grammar and use RFC 2119
> terms, and should be reworded (removals in strikethrough, additions in
> bold):
>
> Strikethrough and bold, eh? OK. :-) Suggestions are good, many thanks!
>

Ha! I'll use Markdown conventions in the future.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

[Joe Abley]

On 26 Jul 2017, at 13:28, Richard Gibson  wrote:

> The need for such a signal also came up recently in 
> https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05#section-10
>  . But in this case particularly, middleboxes should be a complete 
> non-issue... anyone expecting QTYPE=ANY passthrough is already asking for 
> trouble.

We may be imagining different things by "middlebox" -- I think you're thinking 
of a resolver, whereas I'm thinking more broadly about stateful inspection, 
firewalls, ALGs, proxies, forwarders, etc. I think there's an entirely 
reasonable and observable expectation that QTYPE=ANY passthrough works in that 
broader sense. Mark's 
 was an 
easy-to-find example of trouble in the real world. 

>> I think it would be uncontroversial to note explicitly that the mechanism 
>> described in this document contains no such signalling, however. Let me know 
>> if that seems like a pragmatic solution.
> 
> I remain concerned about issuing incomplete responses to ANY queries without 
> indication of such, and predict that it will hinder operational problem 
> investigation and remediation (especially pertaining to IPv4/IPv6 issues). My 
> preference has not changed, but an explicit acknowledgment of the gap at 
> least provides a reference for future improvement.

OK. Your future tense is Cloudflare's past tense and I have not heard of an 
example of the kind of operational confusion that you're predicting there, but 
perhaps I'm just not listening in the right dark corners.

I will plan to add text to acknowledge the lack of signalling but not to change 
the mechanism to introduce any. People should throw rocks if that seems bad.

> How about updating document text to replace "conventional ANY queries" 
> (section 3) and "conventional response" (section 4.1) with "conventional ANY 
> response" and defining it in the Terminology section:
> In this document, "conventional ANY response" refers to an ANY Response that 
> would be produced by the algorithm in section 4.3.2 of RFC 1034. Conventional 
> ANY responses can include include records from an arbitrarily high number of 
> RRSets, up to message truncation.

OK, I'm fine with that.

> Also, it therefore appears that this draft needs to be noted as updating RFC 
> 1034.

Noted.

> In light of the above, referencing RFC 1035 actually seems misleading... the 
> relevant definitions come from RFC 1034, and this draft is consistent with it 
> in acknowledging use of QTYPE=255 for requesting records of all types, but 
> inconsistent with it in specifying responses that intentionally omit matching 
> records.

OK. I'll look at this again.

> I also discovered some incidental issues while confirming the above:
> 1. The draft should standardize on one of "RRSet" (capital S, 17 current 
> instances) or "RRset" (minuscule S, 7 current instances).

Noted. The RFC Editor is well-practiced at dealing with that kind of thing, but 
it doesn't help to give them less work ahead of time.

> 2. Section 4.1 appears to have some errors in grammar and use RFC 2119 terms, 
> and should be reworded (removals in strikethrough, additions in bold):

Strikethrough and bold, eh? OK. :-) Suggestions are good, many thanks!


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

[Richard Gibson]

On Tue, Jul 25, 2017 at 4:52 PM, Joe Abley  wrote:

> >- There is no mechanism for signaling section 4.1/ section 4.3
> "partial
> >response" behavior to clients (e.g., a new OPT record EDNS header flag
> >bit
> > dns-parameters.xhtml#dns-parameters-13>
> >).
>
> Correct. I presume you are suggesting that there should be one. I have not
> heard anybody else require such a thing, and new EDNS code points are
> thought by at least some to be thorny things to pass undigested through
> middleboxes so I think it's a non-trivial suggestion that would require a
> proposal that itself would need thorough review. That feels out of scope
> for this document, but perhaps something analogous to extended RCODEs in
> the sense that it's channel metadata.
>

The need for such a signal also came up recently in
https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05#section-10
. But in this case particularly, middleboxes should be a complete
non-issue... anyone expecting QTYPE=ANY passthrough is already asking for
trouble.

I think it would be uncontroversial to note explicitly that the mechanism
> described in this document contains no such signalling, however. Let me
> know if that seems like a pragmatic solution.
>

I remain concerned about issuing incomplete responses to ANY queries
without indication of such, and predict that it will hinder operational
problem investigation and remediation (especially pertaining to IPv4/IPv6
issues). My preference has not changed, but an explicit acknowledgment of
the gap at least provides a reference for future improvement.

>- "Conventional [ANY] response" is used but not defined.
>
> I am not sure why it's ambiguous without a definition. To me that phrase
> seems pretty straightforward; if your core objection is that the DNS
> standards are not written down with great accuracy, yeah. The only
> definition I can think of really is something like "A response to a query
> that had QTYPE=ANY which follows convention" which just seems longer, not
> more clear. What did you have in mind?
>

How about updating document text to replace "conventional ANY queries"
(section 3) and "conventional response" (section 4.1) with "conventional
ANY response" and defining it in the Terminology section:

In this document, "conventional ANY response" refers to an ANY Response
that would be produced by the algorithm in section 4.3.2 of RFC 1034.
Conventional ANY responses can include include records from an arbitrarily
high number of RRSets, up to message truncation.

Also, it therefore appears that this draft needs to be noted as updating
RFC 1034.

>- "ANY does not mean ALL" is misleading—RFC 1035
> ><
> > https://tools.ietf.org/html/rfc1035#section-3.2.3>
> >  is clear about
> >QTYPE=255 being "a request for *all* records" (emphasis mine). That
> >said, the proposed *response* behavior is consistent with that RFC.
>
> All records that the server constructing the response knows about?
>
> All records that the server can fit into the response given the
> constraints of the available transport?
>
> ALL THE RECORDS IN THE WHOLE WORLD! That was an obscure reference to
> Blackadder the Second that probably pleases nobody but me. ("Kill Bob!"
> "Never!")
>
> I think to that point we can implicitly acknowledge between ourselves that
> less ambiguity would be nice, but that on the whole this text as-is at
> worst does no harm, and at best helps illustrate the philosophy of the
> approach being described.
>
> Let me know how much of that you can live with :-)
>

In light of the above, referencing RFC 1035 actually seems misleading...
the relevant definitions come from RFC 1034, and this draft is consistent
with it in acknowledging use of QTYPE=255 for *requesting* records of all
types, but inconsistent with it in specifying *responses* that
intentionally omit matching records.

On Tue, Jul 25, 2017 at 4:53 PM, Joe Abley  wrote:

> >1.  A DNS responder can choose to select one or subset of RRSets at
> >the QNAME.
> >
> >   'one or subset of RRSets' sounds a bit awkward to me
>
> I agree. Perhaps "One or more of the RRSets at a QNAME". "... or a subset"
> seems wrong, actually; since some vestigial fragment of a set theory
> lecture in the depths of my pre-history is telling me that the empty set is
> always a valid subset.


Suggestion: "A DNS responder can choose to select one or more
nonempty matching RRSets". This works because existence is guaranteed by
the preceding text ("for names that exists that are used", probably better
phrased as "for QNAMEs with at least one nonempty RRSet"). And it has the
added benefit of correctly covering wildcard behavior.

I also discovered some incidental issues while confirming the above:
1. The draft should standardize on one of "RRSet" (capital S, 17 current
instances) or "RRset" (minuscule S, 7 current instances).
2. Section 4.1 appears to have some errors i

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Petr Špaček

[Tony Finch]

Joe Abley  wrote:
>
> If anybody else here has thoughts about specific text or violent
> objections to including QTYPE=RRSIG in general, please let me know (I
> looked in the mail archive but couldn't find any there).

I think it's helpful to mention RRSIG explicitly since it isn't
immediately obvious that it's a stealth ANY query. (It becomes
apparent to implementers fairly rapidly tho!)

> As we discuss (see Stephane's points) in the case of multiple
> transports, perhaps we can also recommend that implementors provide
> configuration options to allow administrators to deal with ANY, RRSIG,
> neither or both. That way we get flexibility that matches deployment,
> but we also get a reference for handling RRSIG in a predictable way.

I think the draft should recommend a simple on/off switch and describe
sensible behaviour when it is on. Mainly because I think we know what
that sensible behaviour is, and I don't think it's a big enough feature
to deserve a lot of configuration and documentation complexity.

Having said that, the initiator side (section 5) needs a bit of work.
Something like,

   ANY queries SHOULD be sent using the same choice of transport as other
   queries (typically, try UDP first, and only use TCP if the response is
   truncated). As an exception, debugging and diagnostics tools MAY have
   a special case for ANY queries.

(bleeding-edge versions of `dig` use TCP for ANY)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Bailey: East becoming cyclonic, 6 to gale 8. Moderate or rough, becoming rough
or very rough. Rain or showers. Good, occasionally poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[bert hubert]

On Mon, Feb 08, 2016 at 10:37:09AM -0500, Jared Mauch wrote:
> Or just having the TCP implementation in BIND get improved as it’s clear there
> are some more people pushing in this direction.  I’m looking at just putting
> something like DNSDIST on my hosts to process TCP and balance it across
> multiple daemons to do the query scale.

With a ltle work btw dnsdist could proxy TCP/IP questions over UDP with
gigantic packet sizes. This would get you TCP/IP to the unwashed BCP38-free
masses but UDP in your home network.

Might that be a good idea?

Bert

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Shane Kerr]

Bert,

At 2016-02-08 22:55:44 +0100
bert hubert  wrote:

> On Mon, Feb 08, 2016 at 10:37:09AM -0500, Jared Mauch wrote:
> > Or just having the TCP implementation in BIND get improved as it’s clear 
> > there
> > are some more people pushing in this direction.  I’m looking at just putting
> > something like DNSDIST on my hosts to process TCP and balance it across
> > multiple daemons to do the query scale.  
> 
> With a ltle work btw dnsdist could proxy TCP/IP questions over UDP with
> gigantic packet sizes. This would get you TCP/IP to the unwashed BCP38-free
> masses but UDP in your home network.
> 
> Might that be a good idea?

I guess so, but why not just nail up some persistent TCP connections
internally?

You should be able to keep a small pool for each backend server, so you
can handle significant concurrency (you shouldn't need that many
connections to an authoritative server, maybe something related to the
number of cores is reasonable, like 2x or 3x cores number of
connections).

Since the sessions are up, you won't pay any additional cost during
each query. In fact, you may even have fewer packets to a busy server,
since multiple messages can be collected into a single IP packet. One
of our developers (hi vorner!) found that proxying UDP into TCP was
actually faster than raw UDP (there are lots of details that may have
impacted this, but we can discuss it if you are curious).

Cheers,

--
Shane

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[bert hubert]

On Mon, Feb 08, 2016 at 10:37:09AM -0500, Jared Mauch wrote:
> Or just having the TCP implementation in BIND get improved as it’s clear there
> are some more people pushing in this direction.  I’m looking at just putting
> something like DNSDIST on my hosts to process TCP and balance it across
> multiple daemons to do the query scale.

With a ltle work btw dnsdist could proxy TCP/IP questions over UDP with
gigantic packet sizes. This would get you TCP/IP to the unwashed BCP38-free
masses but UDP in your home network.

Might that be a good idea?

Bert

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Tony Finch]

Ólafur Guðmundsson  wrote:

> Tony: the draft says right now: [...]
>
> Is that not sufficient ?

The most relevant bit in the current draft is:

   If the DNS query includes DO=1 and the QNAME corresponds to a zone
   that is known by the responder to be signed, a valid RRSIG for the
   RRSets in the answer section MUST be returned.

which does in fact imply that you can leave the RRSIGs out when DO=0
if you read it properly (which I evidently failed to do!) but it's
probably worth saying so explicitly.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Sole, Lundy, Fastnet: West gale 8 to storm 10, decreasing 6 to gale 8,
occasionally 11 at first except in Sole. Very high or phenomenal, becoming
very rough or high. Squally showers. Moderate or poor.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Ólafur Guðmundsson]

On Sun, Feb 7, 2016 at 2:16 PM, Tony Finch  wrote:

> Another question:
>
> In order to minimize responses even further, I have made my code omit or
> include signature records depending on whether DO=0 or DO=1. That is, and
> ANY query with DO=0 gets one arbitrary unsigned RRset in response, and an
> ANY query with DO=1 gets one arbitrary signed RRset.
>
> Is this sensible, and if do should it be suggested by the draft?
>
>
Tony: the draft says right now:

A DNS responder which receives an ANY query MAY decline to provide a
   conventional response, and MAY instead send a response with a single
   RRSet in the answer section.

   The RRSet returned in the answer section of the response MAY be a
   single RRSet owned by the name specified in the QNAME.  Where
   multiple RRSets exist, the responder MAY choose a small one to reduce

   its amplification potential.

Is that not sufficient ?

Olafur
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Jared Mauch]

> On Feb 8, 2016, at 10:33 AM, Tony Finch  wrote:
> 
> Doing anything more determinate would require an extra loop over the data
> to choose, before the loop that builds the response. (Actually I can
> probably avoid two loops if I'm clever.) I didn't think I cared enough to
> do that. However some answers from my zones (e.g. DNSKEY) are bigger than
> 512 bytes and so can cause truncation and TCP, so maybe I do care after
> all.

Or just having the TCP implementation in BIND get improved as it’s clear there
are some more people pushing in this direction.  I’m looking at just putting
something like DNSDIST on my hosts to process TCP and balance it across
multiple daemons to do the query scale.

- Jared
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Tony Finch]

Evan Hunt  wrote:
>
> Choose an arbitrary (preferably determinate) rrset to return, and
> include its covering signature if it exists and DO=1 so the response can
> validate.

Right.

My code currently just picks the first RRtype it gets from the backend
data store (or the type covered if the first RRtype is a signature type).
This is stable on a single server but different servers can return the
data in a different order.

Doing anything more determinate would require an extra loop over the data
to choose, before the loop that builds the response. (Actually I can
probably avoid two loops if I'm clever.) I didn't think I cared enough to
do that. However some answers from my zones (e.g. DNSKEY) are bigger than
512 bytes and so can cause truncation and TCP, so maybe I do care after
all.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Sole, Lundy, Fastnet: West gale 8 to storm 10, decreasing 6 to gale 8,
occasionally 11 at first except in Sole. Very high or phenomenal, becoming
very rough or high. Squally showers. Moderate or poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Evan Hunt]

On Sun, Feb 07, 2016 at 02:16:15PM +, Tony Finch wrote:
> Is this sensible, and if do should it be suggested by the draft?

Yes. I haven't looked in the draft recently, but I thought I mentioned that
when I originally described this trick.  Choose an arbitrary (preferably
determinate) rrset to return, and include its covering signature if it
exists and DO=1 so the response can validate.

eh

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and QTYPE=RRSIG

[Tony Finch]

Ólafur Guðmundsson  wrote:
>
> For all you care you an even return a forged RRSIG/SIG i.e. one that is
> made up on the fly just make sure it covers a non existing TYPE :-)

Make it an RRSIG covering an RRSIG with a private algorithm and you don't
even need to do any crypto :-) (Not entirely serious suggestion.)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Viking, North Utsire, South Utsire, Forties, Cromarty, Forth: Southerly or
southwesterly 6 to gale 8, occasionally severe gale 9 at first, decreasing 5
at times later. Rough or very rough, becoming high for a time except in
Cromarty and Forth. Rain or showers. Moderate or good, occasionally poor.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Tony Finch]

Another question:

In order to minimize responses even further, I have made my code omit or
include signature records depending on whether DO=0 or DO=1. That is, and
ANY query with DO=0 gets one arbitrary unsigned RRset in response, and an
ANY query with DO=1 gets one arbitrary signed RRset.

Is this sensible, and if do should it be suggested by the draft?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fair Isle: Southerly becoming cyclonic 5 to 7, occasionally gale 8 at first in
east. Rough or very rough. Rain or showers. Good, occasionally poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and QTYPE=RRSIG

[Ólafur Guðmundsson]

On Fri, Feb 5, 2016 at 10:10 PM, Tony Finch  wrote:

> Last weekend one of our authoritative name servers
> (authdns1.csx.cam.ac.uk) suffered a series of DoS attacks which made it
> rather unhappy. Over the last week I have developed a patch for BIND to
> implement draft-ietf-dnsop-refuse-any which should allow us to handle
> ANY flood attacks better. http://fanf.livejournal.com/140566.html
>
> I still have a potential problem with RRSIG queries, which work a lot like
> ANY queries. Cloudflare's approach is to simply refuse them, which makes a
> lot of sense because RRSIG queries don't have the same interop concerns as
> ANY queries. However, in an attack like the ones we had last weekend where
> the queries arrived at our authoritative servers from lots of real
> recursive servers, a refusal will cause retries and make the attack worse.
>
> Would it be reasonable as an alternative to follow the refuse-any approach
> and just return the RRSIG(s) for one RRset? If so, I think this suggestion
> should be included in the draft.
>
>
For all you care you an even return a forged RRSIG/SIG i.e. one that is
made up on the fly
just make sure it covers a non existing TYPE :-)

   Olafur
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and QTYPE=RRSIG

[Tony Finch]

Mark Andrews  wrote:
> In message , Tony 
> Fi
> nch writes:
> >
> > Would it be reasonable as an alternative to follow the refuse-any
> > approach and just return the RRSIG(s) for one RRset? If so, I think
> > this suggestion should be included in the draft.
>
> Yes, for both SIG and RRSIG.

Thanks :-)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
South Biscay: Southerly veering southwesterly 5 to 7, occasionally gale 8.
Moderate or rough, occasionally very rough later in northwest. Rain later.
Good, occasionally poor later.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and QTYPE=RRSIG

[Mark Andrews]

In message , Tony Fi
nch writes:
> Last weekend one of our authoritative name servers
> (authdns1.csx.cam.ac.uk) suffered a series of DoS attacks which made it
> rather unhappy. Over the last week I have developed a patch for BIND to
> implement draft-ietf-dnsop-refuse-any which should allow us to handle
> ANY flood attacks better. http://fanf.livejournal.com/140566.html
> 
> I still have a potential problem with RRSIG queries, which work a lot like
> ANY queries. Cloudflare's approach is to simply refuse them, which makes a
> lot of sense because RRSIG queries don't have the same interop concerns as
> ANY queries. However, in an attack like the ones we had last weekend where
> the queries arrived at our authoritative servers from lots of real
> recursive servers, a refusal will cause retries and make the attack worse.
> 
> Would it be reasonable as an alternative to follow the refuse-any approach
> and just return the RRSIG(s) for one RRset? If so, I think this suggestion
> should be included in the draft.
 
Yes, for both SIG and RRSIG.  They are not useful queries on their
own.  I am discounting the corner case of a non DNSSEC aware recursive
server in front of a validating client as that does not work reliably
with DNS loose coherency.

Mark

> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Thames, Dover: Southwest 5 to 7, occasionally gale 8 later, perhaps severe
> gale 9 later. Moderate, occasionally rough later. Occasional rain or drizzle.
> Moderate or good, occasionally poor.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop