Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03

On Thu, Aug 25, 2016 at 04:35:52AM +, Viktor Dukhovni wrote a message of 89 lines which said: > When a nameserver consistently fails to respond: Add "it may make easier for a third-party to inject bogus responses". See

Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03

I'm with Ed here, A valid response is silence. The resolver/client has no way to determine if the lack of a reply is due to the server has chosen silence, or if there was something in-path which dropped the packet. In this case, client misbehaviour is panicking and sending many queries to try an

Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03

william manning wrote: > I'm with Ed here, A valid response is silence. I think it is important for people producing and deploying DNS server software and DNS-interfering middleboxes to understand the bad consequences of dropping queries or responses. If you understand these effects and still t

Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

Edward Lewis wrote: > The question I keep asking myself is: How is this different from a > client just hitting a server with all anticipated questions at one time? Me too :-) I can see an advantage to improving the case where the client can't predict all the questions in advance, e.g. when the

Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

Matthew Pounsett wrote: > > Also take for example the transition from not having HTTP SRV to having > it. One of the arguments against from the browser developer community is > the additional round trips. One of those extra round trips is the need to > request both the A/ of the requested ho

Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

Good thing refuse-any is just a draft then isn't it. Now any v. Concurrent queries. To ensure the resolver gets all the RRs, wouldn't you have to query for all defined RR types? Perhaps you want ALL instead of ANY? /Wm On Thursday, 25 August 2016, Tony Finch wrote: > Edward Lewis > wrote: >

Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03

On Thursday, 25 August 2016, Tony Finch wrote: > william manning > wrote: > > > I'm with Ed here, A valid response is silence. > > I think it is important for people producing and deploying DNS server > software and DNS-interfering middleboxes to understand the bad > consequences of dropping que

Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03

william manning wrote: > On Thursday, 25 August 2016, Tony Finch wrote: > > > william manning > wrote: > > > > > I'm with Ed here, A valid response is silence. > > > > I think it is important for people producing and deploying DNS server > > software and DNS-interfering middleboxes to understan

Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

william manning wrote: > > Now any v. Concurrent queries. To ensure the resolver gets all the RRs, But it doesn't want all the RRs, just the relevant ones. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Northwest Fitzroy, Sole: Variable 3, becoming southwesterly 4 or 5.

Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03

On Thu, Aug 25, 2016 at 9:23 AM, Tony Finch wrote: > william manning wrote: > >> On Thursday, 25 August 2016, Tony Finch wrote: >> >> > william manning > wrote: >> > >> > > I'm with Ed here, A valid response is silence. >> > >> > I think it is important for people producing and deploying DNS se

Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03

On Thu, Aug 25, 2016 at 11:11:22AM -0700, Marek Vavruša wrote a message of 56 lines which said: > +1, there are other implications besides performance. For example > attacker can silence > the NS for victim (either on path or off path with spoofed source > subnet). If successful, > the attacke

Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03

Not answering queries has effects on OTHER servers. Because there are servers out there that don't answer EDNS queries or only answer the first EDNS query resolvers have to ASSUME that no answer to a EDNS quere means "NO EDNS". They then make a plain DNS query and get a answer. Those servers th