Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-no-response-issue

> On 19 Jul 2019, at 8:02 am, Wessels, Duane <dwessels=40verisign.com@dmarc.ietf.org> wrote:
> 
> 
> 
>> On Jul 17, 2019, at 5:17 AM, Tim Wicinski <tjw.ietf@gmail.com> wrote:
>> 
>> All
>> 
>> Since it seems that everyone is now getting their own Flag Day, this document's time is 
>> now to be published.   I want to thank Mark for being so patient with me as I've
>> sat through several review sessions, and addressing all the early feedback.   
>> 
>> Please note that the document is now marked as BCP.  If you feel this should not be 
>> the case, please speak up. 
>> 
>> The chairs will be looking to hear from folks during this WGLC as well as during
>> the meeting. So Flag Day People, please make yourself heard!
>> 
>> This starts a Working Group Last Call for draft-ietf-dnsop-no-response-issue
>> 
>> Current versions of the draft is available here:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/
>> 
>> The Current Intended Status of this document is: Best Current Practice 
>> 
>> Please review the draft and offer relevant comments.
>> If this does not seem appropriate please speak out. 
>> If someone feels the document is *not* ready for publication, please speak out with your reasons.
> 
> 
> Regarding intended status as BCP, I think thats fine, but I find it somewhat strange
> that the title and abstract frames these as problems and failures.  Maybe as a BCP it would
> be better to phrase it as something like "Identifying problems..." or "Testing for failures..."
> 
> Also if 2019 flag day was a great success, is this still such a "common" problem?

The 2019 flag day targeted dropping of queries as recursive servers where no longer going to
workaround that breakage.  It didn’t target the rest of the issues but flagged some of them as
you need to fix in the future.

https://ednscomp.isc.org had graphs for the EDNS issues.  I would say that there are still issues.
You can make up your own opinion.  One can drill down to individual failure modes.

For a complete zone there is https://ednscomp.isc.org/compliance/ts/govfull-graphs.html GSA
publishes all of .GOV.  You can compare that to the sample of .GOV that makes it into the
Alexa top 1 million.

>> Abstract
>> 
>>   The DNS is a query / response protocol.  Failing to respond to
>>   queries, or responding incorrectly, causes both immediate operational
>>   problems and long term problems with protocol development.
>> 
>>   This document identifies a number of common kinds of queries to which
>>   some servers either fail to respond or else respond incorrectly.
>>   This document also suggests procedures for TLD and other zone
>>   operators to apply to mitigate the problem.
> 
> 
> I'm not sure why TLDs are called out specifically here.  "TLD" appears only
> one other time in the document.
> 
> Maybe instead of "mitigate" it would be better to say "identify and remediate”?

Updated in .xml.

>> 3.  Common queries kinds that result in no or bad responses.
>> 
>>   This section is broken down into Basic DNS requests and EDNS
>>   requests.
> 
>> 
>> 3.1.  Basic DNS Queries
>> 
>> 3.1.1.  Zone Existence
>> 
>>   Initially, to test existence of the zone, an SOA query should be
>>   made.  If the SOA record is not returned but some other response is
>>   returned, this is an indication of a bad delegation.
> 
> 
> Some of the text in these subsections talk about tests or testing, which
> is either repeated or more appropriately placed in section 8 I think.
> 
> DW
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org