Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-roadblock-avoidance-04.txt

From: [email-masked]
Date: Sun, 03 Apr 2016 20:32:39 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

        Title           : DNSSEC Roadblock Avoidance
        Authors         : Wes Hardaker
                          Olafur Gudmundsson
                          Suresh Krishnaswamy
	Filename        : draft-ietf-dnsop-dnssec-roadblock-avoidance-04.txt
	Pages           : 18
	Date            : 2016-04-03

Abstract:
   This document describes problems that a DNSSEC aware resolver/
   application might run into within a non-compliant infrastructure.  It
   outline potential detection and mitigation techniques.  The scope of
   the document is to create a shared approach to detect and overcome
   network issues that a DNSSEC software/system may face.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-roadblock-avoidance-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Wouters <[email-masked]>
Date: Mon, 4 Apr 2016 17:23:23 -0400 (EDT)

> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-roadblock-avoidance-04

The new text states:

        If the resolver is labeled as "Validator" or "DNSSEC aware"

            Send query through this resolver and perform local
            validation on the results.

            If validation fails, try the next resolver

        Else if the resolver is labeled "Not a DNS Resolver" or
           "Non-DNSSEC capable"

            Mark it as unusable and try next resolver

        Else if no more resolvers are configured and if direct queries
        are supported
            1.  try iterating from Root

            2. If the answer is SECURE/BOGUS:
                 Return the result of the iteration
            3.  If the query is INSECURE:
                  Re-query "Non-DNSSEC capable" servers and return
                  answers from them w/o the AD bit set to  the client.
            This will increase the likelihood that spit-view unsigned
            answers are found.

        Else return an useful error code

Should item 3. be "if the answer is INSECURE" instead of "If the query is INSECURE" ?

And should it be "w/o the DO and AD bit set" instead of "w/o the AD bit set" ?

Paul