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

From: [email-masked]
Date: Wed, 01 Jul 2015 05:49:42 -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 Working Group of the IETF.

        Title           : DNSSEC Roadblock Avoidance
        Authors         : Wes Hardaker
                          Olafur Gudmundsson
                          Suresh Krishnaswamy
	Filename        : draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt
	Pages           : 16
	Date            : 2015-07-01

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

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

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: Olafur Gudmundsson <[email-masked]>
Date: Wed, 1 Jul 2015 08:52:14 -0400

This version is a final version from the editors. 
We explicitly punt on explaining how to overcome the situation when a ´proxy/forwarder’ “randomly” sends queries to 
Resolvers with different capabilities. 

Olafur

> On Jul 1, 2015, at 8:49 AM, [email-masked] wrote:
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 01 Jul 2015 09:31:44 -0400

Thanks Olafur.  The Workign Group should discuss this as it was 
originally planned to go into a Working Group Last Call.  It can still 
be taken in this direction.

tim

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 1 Jul 2015 10:12:38 -0400

> On Jul 1, 2015, at 9:31 AM, Tim Wicinski <[email-masked]> wrote:
> 
> 
> Thanks Olafur.  The Workign Group should discuss this as it was originally planned to go into a Working Group Last Call.  It can still be taken in this direction.
> 
> tim
> 
> 
Tim
We request a WGLC on the document

	Olafur

---

From: "Rose, Scott W." <[email-masked]>
Date: Fri, 10 Jul 2015 13:59:57 -0400

In general I support this document, with some minor comments below:

Abstract:
s/approache/approach

Section 1.1
2nd paragraph:
s/recomendations/recommendations

"it" is repeated twice in the sentence starting: "While these recomendations
   are mainly aimed at Host Validators it it..."

s/Validatating/Validating

Last paragraph:
s/directy/directly

"...can not talk directy to a Resolver
   the tests below do not address how to overcome that."

missing a semicolon?  Or "...Resolver. The tests below..." Don't know for sure but sounds strange the way it is currently.

Also, the paragraph talks about users, but maybe applications may be more appropriate since the end user may not be aware of or care about proxies.  The meaning is clear though so I can live with the current wording.

Section 1.2.
2nd paragraph:
	s/digiest/digest

Section 3
Title: 
	s/Compilance/Compliance

2nd paragraph
	s/assumtption/assumption

3rd paragraph:
	not a huge fan of the salty language since the goal should be to fix broken middleboxes and not just call them crap and move on.  Also, might want to mention that middleboxes can also cause strange behavior with some authoritative servers but that this should not necessary change the rank/use of a recursive resolver.  In other words, just because some queries start returning bad or strange results, that should not be used to change the rank/preference of the recursive resolver unless it happens with multiple queries.

Section 3.1.5
While the test for the AD bit gives the host information about the validating status of the upstream resolver, it really doesn't give full information about what trust anchors are in use.  This might become an issue with split DNS, which isn't mentioned.  I know the authors don't want to get stuck in that quagmire, but it exists and will need to be acknowledged (since it can't be solved).

Scott

>>>> ftp://ftp.ietf.org/internet-drafts/

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
https://www.had-pilot.com/
===================================