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

[Mark Andrews <[e-mail]>]

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: [phone]                 INTERNET: [e-mail]