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

[Mark Andrews]

See also https://ednscomp.isc.org/compliance/alexa-report.html

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

[Viktor Dukhovni]

On Thu, Aug 18, 2016 at 02:34:54PM +, 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

real0m15.081s

with:

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

; <<>> DiG 9.10.3-P4 <<>> +noall +ans +auth +comment +qu +cmd +nocl +nottl 
-t  _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 

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

real0m0.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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-02.txt

[神明達哉]

At Mon, 22 Aug 2016 21:57:12 +,
"Wessels, Duane"  wrote:

> > - Section 5.3
> >
> >   Unless the zone operator has intentionally added
> >   "_ta-" records to the zone, the server MUST generate an NXDOMAIN
> >   response.
> >
> >  Perhaps a pedantic comment, but I suspect this is not 100% accurate
> >  in that it could legitimately result in other response than
> >  NXDOMAIN, [...]
>
> I can be convinced either to keep it or to leave it.  My rationale for
> that sentence is to state that a server should not have some built-in logic
> that determines the response to these types of queries.  The response code
> should be determined by whether or not they are in the zone file (or as you 
> say
> covered by wildcard).

Okay, I see the point.  In that case I'd state that point more
specifically rather than through one such case of NXDOMAIN, but I'd
leave it to you.

> > - Section 5.3.1
> >
> >   When the response code for a key tag query is NXDOMAIN, DNS resolvers
> >   that implement aggressive negative caching will send fewer key tag
> >   queries than resolvers that do not implement it.
> >
> >  In the context of the interaction with nsec-aggressiveuse, I think
> >  this should be more generalized than the response to a key tag query
> >  itself, e.g.:
> >
> >   When a query results in an NXDOMAIN response with NSEC or NSEC3
> >   that covers the name of a key tag query, DNS resolvers that
> >   implement aggressive negative caching will send fewer key tag
> >   queries than resolvers that do not implement it.
>
> IMO your version adds a little unnecessary complexity to the sentence, while
> making the same point.

I don't think these two are exactly the same, but I won't insist on
the generalized text.

--
JINMEI, Tatuya

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