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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
