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

[Mark Andrews]

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 then get marked for a while as not
supporting EDNS.  This isn't a big issue until those servers are
serving a signed zone.  Once that server serves a signed zone you
have real issues as DNSSEC responses rely on EDNS queries and you
stop getting EDNS queries.  The client then doesn't get the RRSIGs
and can't validate.

PMTUD from the server to the client has a similar loss pattern to
drop on EDNS, answer on DNS.  Do you see the problems caused to
others by deciding to drop packets in a query / response protocol.

The same thing happens with servers that don't answer EDNS options.
The recursive server has to decide is this the EDNS option or EDNS
or just packloss.  Add in servers that don't like particular options
(yes there are servers that don't answer NSID queries but do answer
other EDNS options) and the problem for the recursive servers becomes
bigger for the recursive server.

We already have DNS zones that will not work with BIND 9.10.x and
BIND 9.11.x because the servers for those zones drop queries with
EDNS options present and the zones are signed.

The CORRECT behaviour for a recursive server is to retry the SAME
query.  No answer means PACKET LOSS, usually for load but sometimes
for corruption.  It does NOT mean that I don't like the query.  We
have a rcode for that: REFUSED.

When named drops packet (too many queries for the same question)
the expected behaviour from the client is to timeout and retry.
Its load shedding the same way as a link sheds load by dropping
packets.  It also isn't based on a EDNS option, EDNS flag, EDNS
version, QTYPE, QCLASS, DNS flag, opcode or similar.  It purely
load based.

For completeness named can also be configured to drop queries based
on address but is drops all queries so it behaves like a dead server
to that client.

A nameserver / firewall should not be looking at query content and
deciding not to answer based on that content.

If you don't want to implement a EDNS than don't implement it.  If
you don't want to use a EDNS option with some client then just
ignore the option.  Similarly for EDNS flags.  The client is expecting
that unsupported options and flags will be ignored not used to
decide to drop a query.

Mark
-- 
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

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

[Marek Vavruša]

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 server
>> > software and DNS-interfering middleboxes to understand the bad
>> > consequences of dropping queries or responses. If you understand these
>> > effects and still think you can improve things by dropping packets, then
>> > maybe go ahead. But it isn't a simple valid / invalid binary choice.
>>
>> Where does the "badness" occur? The server or resolver?
>
> Both. The resolver suffers extra latency; the server suffers extra traffic
> - even a well-behaved resolver has to retry in this situation.
>
>> The rational for a server to silently ignore a query often revolves
>> around malformed queries ...  Should a server attempt to answer
>> malformed queries or silently drop them?
>
> See section 7 of the draft. It would be reasonable to rate-limit
> responses.
>
> This kind of nuance is what this draft should discuss.
>
> Tony.

+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 attacker doesn't have to race NS->victim RTT anymore for
successful cache poisoning.

Marek

> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
> Trafalgar: In southeast, cyclonic, mainly easterly 6 to gale 8. In northwest,
> northerly or northeasterly 5 or 6, occasionally 7 later. Moderate or rough. In
> southeast, showers. In northwest, thundery showers. In southeast, moderate or
> good. In northwest, good occasionally poor.
>
> ___
> 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] The Larger Discussion on Differences in Response Drafts

[Tony Finch]

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.finch    http://dotat.at/  -  I xn--zr8h punycode
Northwest Fitzroy, Sole: Variable 3, becoming southwesterly 4 or 5. Slight or
moderate. Showers. Good.

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

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

[Tony Finch]

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 understand the bad
> > consequences of dropping queries or responses. If you understand these
> > effects and still think you can improve things by dropping packets, then
> > maybe go ahead. But it isn't a simple valid / invalid binary choice.
>
> Where does the "badness" occur? The server or resolver?

Both. The resolver suffers extra latency; the server suffers extra traffic
- even a well-behaved resolver has to retry in this situation.

> The rational for a server to silently ignore a query often revolves
> around malformed queries ...  Should a server attempt to answer
> malformed queries or silently drop them?

See section 7 of the draft. It would be reasonable to rate-limit
responses.

This kind of nuance is what this draft should discuss.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: In southeast, cyclonic, mainly easterly 6 to gale 8. In northwest,
northerly or northeasterly 5 or 6, occasionally 7 later. Moderate or rough. In
southeast, showers. In northwest, thundery showers. In southeast, moderate or
good. In northwest, good occasionally poor.

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

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

[william manning]

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:
>
> > 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 subsequent questions
> depend on a SRV target or an SPF include: directive.
>
> A big problem with additional data at the moment is a client doesn't know
> whether an absence of data (no  records) means the data doesn't exist,
> so it still has to make followup queries to double check. A DNSSEC proof
> of nonexistence could help.
>
> > Why not just ask for qtype ANY all the time, for data sets owned by the
> > same domain name.
>
> Doesn't work reliably through caches, or with draft-ietf-dnsop-refuse-any
> :-)
> Also, ANY doesn't actually improve latency compared to concurrent queries.
>
> Tony.
> --
> f.anthony.n.finch  >  http://dotat.at/  -  I
> xn--zr8h punycode
> Southeast Biscay: Variable 2 or 3, becoming northwesterly 4 or 5 for a
> time.
> Slight or moderate. Occasional showers. Good.
>
> ___
> 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] The Larger Discussion on Differences in Response Drafts

[Tony Finch]

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 host and the _http._tcp. SRV
> record in separate queries, not knowing if the latter even exists.

A client can query for A  and SRV concurrently. The extra latency is
due to the followup SRV target address queries and the higher rate of SRV
lookup failures.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Northwest Fitzroy, Sole: Variable 3, becoming southwesterly 4 or 5. Slight or
moderate. Showers. Good.

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

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

[Tony Finch]

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 subsequent questions
depend on a SRV target or an SPF include: directive.

A big problem with additional data at the moment is a client doesn't know
whether an absence of data (no  records) means the data doesn't exist,
so it still has to make followup queries to double check. A DNSSEC proof
of nonexistence could help.

> Why not just ask for qtype ANY all the time, for data sets owned by the
> same domain name.

Doesn't work reliably through caches, or with draft-ietf-dnsop-refuse-any :-)
Also, ANY doesn't actually improve latency compared to concurrent queries.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Southeast Biscay: Variable 2 or 3, becoming northwesterly 4 or 5 for a time.
Slight or moderate. Occasional showers. Good.

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

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

[Tony Finch]

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 think you can improve things by dropping packets, then
maybe go ahead. But it isn't a simple valid / invalid binary choice.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Southeast Fitzroy: Northerly or northeasterly 5 or 6, occasionally 7 later.
Moderate or rough. Thundery showers. Good occasionally poor.

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

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

[william manning]

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
and gain the information it things it needs.  WindowsXP had this
behaviour.  Servers can and do "blackhole" queries the operator deems
irrelevant/excessive with hold-down and supression capabilities.  The fix,
if there is one needed, needs to sit at the resolver/client side.

/Wm

On Thu, Aug 25, 2016 at 12:25 AM, Stephane Bortzmeyer 
wrote:

> 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
>  Blocking_DNS_Messages_Is_Dangerous.pdf>
>
> ___
> 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-no-response-issue-03

[Stephane Bortzmeyer]

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


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