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

[Viktor Dukhovni <[e-mail]>]

On Thu, Aug 18, 2016 at 02:34:54PM +0000, Edward Lewis wrote:

> ##1.  Introduction
> ##
> ##   The DNS [RFC1034], [RFC1035] is a query / response protocol.  Failure
> ##   to respond to queries or to respond incorrectly causes both immediate
> ##   operational problems and long term problems with protocol
> ##   development.
> 
> While the latter is true, operationally the DNS is not strictly query -
> response.  It's more like "query - if I want to respond".  I was
> "enlightened" during a project 10-15 years ago when I realized that some
> DNS implementations choose silence when deciding how to respond.

Of course nobody can compell a server to respond, and dropping some
queries may be unavoidable/necessary when under attack.  That said,
routine silence is substantially sub-optimal.  Especially (as is
typical) when said silence is the result of misguided "security
features" in middleboxes.

When a nameserver consistently fails to respond:

    * Queries will needlessly be sent to the remaining nameservers,
      increasing the traffic load.
    * For lack of a cached negative reply, queries will also be sent
      much more frequently.
    * DNS clients will experience significant latency retrying the
      query.
    * Security-aware applications may deduce a possible downgrade
      attack and defer or fail data transmission.

Similar considerations apply when inappropriate RCODEs are used in
replies for unsupported RRTYPEs that don't appear in the zone, and
thus a NODATA or NXDOMAIN would be the right response.  Compare:

    $ time dig +noall +ans +auth +comment +qu +cmd +nocl +nottl -t tlsa _25._tcp.pilot.jhuapl.edu
    ; <<>> DiG 9.10.3-P4 <<>> +noall +ans +auth +comment +qu +cmd +nocl +nottl -t tlsa _25._tcp.pilot.jhuapl.edu
    ;; global options: +cmd
    ;; connection timed out; no servers could be reached

    real    0m15.081s

with:

    $ time dig +noall +ans +auth +comment +qu +cmd +nocl +nottl -t aaaa _25._tcp.pilot.jhuapl.edu

    ; <<>> DiG 9.10.3-P4 <<>> +noall +ans +auth +comment +qu +cmd +nocl +nottl -t aaaa _25._tcp.pilot.jhuapl.edu
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40442
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;_25._tcp.pilot.jhuapl.edu. IN AAAA

    ;; AUTHORITY SECTION:
    jhuapl.edu.             SOA     infoblox-prod-gm.jhuapl.edu. nic-contact.jhuapl.edu. 13899920 10800 1080 2592000 600

    real    0m0.120s

Which would you say is the correct nameserver behaviour?
Given:

    $ dig +short -t mx jhuapl.edu | sort -n
    40 pilot.jhuapl.edu.
    40 piper.jhuapl.edu.

and that the same behaviour is observed for the TLSA records of
both MX hosts, the jhuapl.edu domain is a blackhole for email via
DANE-enabled sending MTAs.

> ##   Some servers fail to respond to ...
> 
> This doesn't establish a need to react to the situation.  "Some" might be
> one operator's code, etc.

While the situation is improving, non-response is still a real
issue, with some domains having all non-responsive nameservers,
and others having a subset of non-responsive nameservers.

-- 
	Viktor.