Re: [DNSOP] [Gen-art] Genart last call review of draft-ietf-dnsop-7706bis-07

[Alissa Cooper]

Ines, thanks for your review. All, thanks for your responses. I entered a No 
Objection ballot.

Alissa


> On Mar 2, 2020, at 8:18 AM, Ines Robles 
>  wrote:
> 
> Hi Warren,
> 
> Thank you very much for your reply,
> 
> Best wishes,
> 
> Ines..
> 
> On Fri, Feb 28, 2020 at 8:18 PM Warren Kumari  > wrote:
> On Fri, Feb 28, 2020 at 8:02 AM Ines Robles via Datatracker
> mailto:nore...@ietf.org>> wrote:
> >
> > Reviewer: Ines Robles
> > Review result: Ready with Nits
> >
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed
> > by the IESG for the IETF Chair.  Please treat these comments just
> > like any other last call comments.
> >
> > For more information, please see the FAQ at
> >
> >  > >.
> >
> > Document: draft-ietf-dnsop-7706bis-07
> > Reviewer: Ines Robles
> > Review Date: 2020-02-28
> > IETF LC End Date: 2020-02-28
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> >
> > The document is well written,  it supplies appendixes with examples.
> >
> > This document describes a method for the operator of a recursive resolver to
> > have a complete root zone locally, and to hide queries for the root zone 
> > from
> > outsiders, at the cost of adding some operational fragility for the 
> > operator.
> >
> > I have some minor questions.
> >
> > Major issues: None
> >
> > Minor issues: None.
> >
> > Nits/editorial comments:
> >
> 
> Thank you for the review!
> 
> > 1- Appendix B.5: it seems that the link is not valid:  > 
> >resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc- 
> > 
> >7706>
> >
> >   This link worked for me:
> >   https://knot-resolver.readthedocs.io/en/stable/modules-rfc7706.html 
> > .
> 
> Thanks - not just for pointing out the issue, but also finding a
> better version - as suggested, I am changing this (in a git branch
> where I am collecting updates) to
> https://knot-resolver.readthedocs..io/en/v5.0.1/modules-rfc7706.html 
>  -
> I believe that stability is the most important attribute. AD, please
> let us know if you disagree.
> 
> >
> > Questions:
> >
> > 1- It seems that this document replaces RFC7706, but the document states 
> > that
> > it updates RFC7706, is that correct?
> 
> Oh, good point - once this is published, it does replace 7706 (it is a
> bis, and contains all of the content from 7706), so Obsoletes is
> better.
> Thank you, changed.
> 
> >
> > 2- Abstract: "The cost of adding some operational fragility for the 
> > operator",
> > Does it introduce security considerations that have to be mentioned?
> >
> > 3- Section 1: "Research shows that the vast majority of queries going to the
> > root are for names that do not exist in the
> >root zone." - Do you have some references to that research that can be 
> > added
> >to the draft?
> 
> H... I think that we missed this because, within the DNS community
> this is sufficiently well known that we don't even think about /
> question it.
> There is quite a lot of research on this, but much if it is behind
> paywalls - while almost 20 years old now (Gods, I feel old!), I think
> that the best one to cite is still:
> https://www.caida.org/publications/papers/2001/DNSMeasRoot/dmr.pdf 
>  (
> DNS Measurements at a Root Server ) -- I will add this.
> 
> >
> > 4- I would expand KSK to Key signing key (KSK).
> 
> Thanks! Done!
> 
> >
> > 5- Should this draft add a reference to rfc8499?
> 
> Seems like a good idea, thanks! I'm adding:
> "Readers are expected to be familiar with ."
> 
> >
> > Thank you for this document,
> 
>  and thank you for the review.
> 
> W
> 
> >
> > Ines.
> >
> >
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [DNSOP] [Ext] New Version Notification for draft-fanf-dnsop-sha-ll-not-00.txt (fwd)

[John Levine]

In article <2914db1a-f7a3-4f1b-a2f0-da054b447...@icann.org> you write:
>If we can determine when something in the realm of "almost all" DNSEC signing 
>with algorithms that use SHA-1 is
>done, then it is reasonable for the WG to propose that software that validates 
>DNSSEC can stop doing so.

FWIW, the 2007 DKIM spec said that RSA keys SHOULD be at least 1024
bits but allowed 512 bits as what we intended as a short transition.
In fact, vast amounts of mail continued to have 512 bit signatures and
ignored all the pleas and warnings until 2012 when Google told the
world that they'd stop validating 512 bit signatures.  At that point
in about a week, everyone fixed their signers to use 1024.

The people who run DNS servers and the ones who run mail servers are often
not the same, but I don't see any reason to think DNS operators are any
less lazy.

What this tells me is that the IETF cannot make credible threats of
this kind, so don't try.  People will stop signing with SHA-1 when
large DNSSEC consumers stop accepting it.  Comcast, perhaps.
-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] Last Call: (A Common Operational Problem in DNS Servers - Failure To Communicate.) to Best Current Practice

[Warren Kumari]

On Wed, Mar 11, 2020 at 3:44 PM Warren Kumari  wrote:
>
> On Tue, Mar 10, 2020 at 6:34 PM Mark Andrews  wrote:
> >
> >
> >
> > > On 11 Mar 2020, at 00:54, Warren Kumari  wrote:
> > >
> > > On Thu, Dec 19, 2019 at 8:28 PM Warren Kumari  wrote:
> > >>
> > >> [ Note: CC list edited ]
> > >>
> > >> Hi there authors,
> > >>
> > >> During the IETF LC Stephane supported the document (an important
> > >> document, worthy of publication), but noted that:
> > >> 1: the document only deals with auth servers and that it should be
> > >> more explicit and
> > >
> > > So, finally a new version, but from what I can see, you didn't address
> > > the above, nor did you add an Acknowledgements section.
> >
> > Because it isn’t authoritative only.  I could add “when test recursive 
> > servers
> > set RD=1 and choose a zone name you know to exist, e.g. the root” for those 
> > test that depend
> > on the SOA record existing in the reply.  There are lots of tests in there 
> > that
> > should give the same result independent of the setting of RD or the QNAME.
> >
> > Will add
> >
> >   
> > When testing recursive servers set RD=1 and choose a zone
> > name that is know to exist and is not being served by the
> > recursive server.  The root zone (".") is often a good
> > candidate.  RD=1, rather than RD=0, should be present in
> > the responses for all test involving the opcode
> > QUERY.
> >   
> >
>
> Okey dokey - if you do this soon, I will approve posting this outside
> of the cut-off...
>

... and I just saw that this was posted - whoops, reading email out of order.
W

> W
>
> > [beetle:~/DNS-Compliance-Testing] marka% ~/DNS-Compliance-Testing/genreport 
> > -Rtf
> > . localhost
> > . @::1 (localhost.): dns=ok aa=ok ad=ok cd=ok ra=ok rd=ok tc=ok zflag=ok 
> > opcode=ok opcodeflg=ok type666=ok tcp=ok edns=ok edns1=ok edns@512=ok 
> > ednsopt=ok edns1opt=ok do=ok docd=ok edns1do=ok ednsflags=ok 
> > optlist=ok,nsid,cookie+badcookie,subnet ednsnsid=ok,nsid 
> > ednscookie=ok,cookie+badcookie ednsexpire=ok ednssubnet=ok,subnet 
> > edns1nsid=ok edns1cookie=ok edns1expire=ok edns1subnet=ok signed=ok,yes 
> > ednstcp=ok A=ok NS=ok MD=ok MF=ok CNAME=ok SOA=ok MB=ok MG=ok MR=ok NULL=ok 
> > WKS=ok PTR=ok HINFO=ok MINFO=ok MX=ok TXT=ok RP=ok AFSDB=ok X25=ok ISDN=ok 
> > RT=ok NSAP=ok NSAP-PTR=ok SIG=ok KEY=ok PX=ok GPOS=ok =ok LOC=ok NXT=ok 
> > SRV=ok NAPTR=ok KX=ok CERT=ok A6=ok DNAME=ok APL=ok DS=ok SSHFP=ok 
> > IPSECKEY=ok RRSIG=ok NSEC=ok DNSKEY=ok DHCID=ok NSEC3=ok NSEC3PARAM=ok 
> > TLSA=ok SMIMEA=ok HIP=ok CDS=ok CDNSKEY=ok OPENPGPKEY=ok CSYNC=ok ZONEMD=ok 
> > SPF=ok NID=ok L32=ok L64=ok LP=ok EUI48=ok EUI64=ok URI=ok CAA=ok AVC=ok 
> > DOA=ok AMTRELAY=ok TA=ok DLV=ok TYPE1000=ok
> > . @127.0.0.1 (localhost.): dns=ok aa=ok ad=ok cd=ok ra=ok rd=ok tc=ok 
> > zflag=ok opcode=ok opcodeflg=ok type666=ok tcp=ok edns=ok edns1=ok 
> > edns@512=ok ednsopt=ok edns1opt=ok do=ok docd=ok edns1do=ok ednsflags=ok 
> > optlist=ok,nsid,cookie+badcookie,subnet ednsnsid=ok,nsid 
> > ednscookie=ok,cookie+badcookie ednsexpire=ok ednssubnet=ok,subnet 
> > edns1nsid=ok edns1cookie=ok edns1expire=ok edns1subnet=ok signed=ok,yes 
> > ednstcp=ok A=ok NS=ok MD=ok MF=ok CNAME=ok SOA=ok MB=ok MG=ok MR=ok NULL=ok 
> > WKS=ok PTR=ok HINFO=ok MINFO=ok MX=ok TXT=ok RP=ok AFSDB=ok X25=ok ISDN=ok 
> > RT=ok NSAP=ok NSAP-PTR=ok SIG=ok KEY=ok PX=ok GPOS=ok =ok LOC=ok NXT=ok 
> > SRV=ok NAPTR=ok KX=ok CERT=ok A6=ok DNAME=ok APL=ok DS=ok SSHFP=ok 
> > IPSECKEY=ok RRSIG=ok NSEC=ok DNSKEY=ok DHCID=ok NSEC3=ok NSEC3PARAM=ok 
> > TLSA=ok SMIMEA=ok HIP=ok CDS=ok CDNSKEY=ok OPENPGPKEY=ok CSYNC=ok ZONEMD=ok 
> > SPF=ok NID=ok L32=ok L64=ok LP=ok EUI48=ok EUI64=ok URI=ok CAA=ok AVC=ok 
> > DOA=ok AMTRELAY=ok TA=ok DLV=ok TYPE1000=ok
> > [beetle:~/DNS-Compliance-Testing] marka%
> >
> >
> > -R set RD=1.
> > -t test know types
> > -f full test set (excludes types)
> >
> >
> > > I'm putting it back in Revised ID needed; please address the comments,
> > > or I will be forced to send it back to the WG
> > >
> > > W
> > >
> > >> 2: that Section 3 is confusing, and that Matt had provided some text
> > >> which helps make this better --
> > >> https://mailarchive.ietf.org/arch/msg/dnsop/_Nq8PAVOapIVal2BS7P-jlWmnuc
> > >>
> > >> Having reread section 3 (and Matt's suggestions) I agree with Stephane
> > >> on both of these - I also think that addressing these should be quite
> > >> easy (I don't think it requires a "restructuring"), especially as Matt
> > >> has provided suggested text...
> > >> I'd appreciate if you can address these, and SHOUT LOUDLY once you've
> > >> had a chance to do so (or let me know how else you'd like to handle
> > >> this).
> > >>
> > >> I also think that it would be worth adding an Acknowledgements section...
> > >>
> > >> Thanks,
> > >> W
> > >>
> > >>
> > >>
> > >> On Thu, Dec 5, 2019 at 9:00 PM The IESG  wrote:
> > >>>
> > >>>
> > >>> The IESG has received a request from the 

Re: [DNSOP] Last Call: (A Common Operational Problem in DNS Servers - Failure To Communicate.) to Best Current Practice

[Warren Kumari]

On Tue, Mar 10, 2020 at 6:34 PM Mark Andrews  wrote:
>
>
>
> > On 11 Mar 2020, at 00:54, Warren Kumari  wrote:
> >
> > On Thu, Dec 19, 2019 at 8:28 PM Warren Kumari  wrote:
> >>
> >> [ Note: CC list edited ]
> >>
> >> Hi there authors,
> >>
> >> During the IETF LC Stephane supported the document (an important
> >> document, worthy of publication), but noted that:
> >> 1: the document only deals with auth servers and that it should be
> >> more explicit and
> >
> > So, finally a new version, but from what I can see, you didn't address
> > the above, nor did you add an Acknowledgements section.
>
> Because it isn’t authoritative only.  I could add “when test recursive servers
> set RD=1 and choose a zone name you know to exist, e.g. the root” for those 
> test that depend
> on the SOA record existing in the reply.  There are lots of tests in there 
> that
> should give the same result independent of the setting of RD or the QNAME.
>
> Will add
>
>   
> When testing recursive servers set RD=1 and choose a zone
> name that is know to exist and is not being served by the
> recursive server.  The root zone (".") is often a good
> candidate.  RD=1, rather than RD=0, should be present in
> the responses for all test involving the opcode
> QUERY.
>   
>

Okey dokey - if you do this soon, I will approve posting this outside
of the cut-off...

W

> [beetle:~/DNS-Compliance-Testing] marka% ~/DNS-Compliance-Testing/genreport 
> -Rtf
> . localhost
> . @::1 (localhost.): dns=ok aa=ok ad=ok cd=ok ra=ok rd=ok tc=ok zflag=ok 
> opcode=ok opcodeflg=ok type666=ok tcp=ok edns=ok edns1=ok edns@512=ok 
> ednsopt=ok edns1opt=ok do=ok docd=ok edns1do=ok ednsflags=ok 
> optlist=ok,nsid,cookie+badcookie,subnet ednsnsid=ok,nsid 
> ednscookie=ok,cookie+badcookie ednsexpire=ok ednssubnet=ok,subnet 
> edns1nsid=ok edns1cookie=ok edns1expire=ok edns1subnet=ok signed=ok,yes 
> ednstcp=ok A=ok NS=ok MD=ok MF=ok CNAME=ok SOA=ok MB=ok MG=ok MR=ok NULL=ok 
> WKS=ok PTR=ok HINFO=ok MINFO=ok MX=ok TXT=ok RP=ok AFSDB=ok X25=ok ISDN=ok 
> RT=ok NSAP=ok NSAP-PTR=ok SIG=ok KEY=ok PX=ok GPOS=ok =ok LOC=ok NXT=ok 
> SRV=ok NAPTR=ok KX=ok CERT=ok A6=ok DNAME=ok APL=ok DS=ok SSHFP=ok 
> IPSECKEY=ok RRSIG=ok NSEC=ok DNSKEY=ok DHCID=ok NSEC3=ok NSEC3PARAM=ok 
> TLSA=ok SMIMEA=ok HIP=ok CDS=ok CDNSKEY=ok OPENPGPKEY=ok CSYNC=ok ZONEMD=ok 
> SPF=ok NID=ok L32=ok L64=ok LP=ok EUI48=ok EUI64=ok URI=ok CAA=ok AVC=ok 
> DOA=ok AMTRELAY=ok TA=ok DLV=ok TYPE1000=ok
> . @127.0.0.1 (localhost.): dns=ok aa=ok ad=ok cd=ok ra=ok rd=ok tc=ok 
> zflag=ok opcode=ok opcodeflg=ok type666=ok tcp=ok edns=ok edns1=ok 
> edns@512=ok ednsopt=ok edns1opt=ok do=ok docd=ok edns1do=ok ednsflags=ok 
> optlist=ok,nsid,cookie+badcookie,subnet ednsnsid=ok,nsid 
> ednscookie=ok,cookie+badcookie ednsexpire=ok ednssubnet=ok,subnet 
> edns1nsid=ok edns1cookie=ok edns1expire=ok edns1subnet=ok signed=ok,yes 
> ednstcp=ok A=ok NS=ok MD=ok MF=ok CNAME=ok SOA=ok MB=ok MG=ok MR=ok NULL=ok 
> WKS=ok PTR=ok HINFO=ok MINFO=ok MX=ok TXT=ok RP=ok AFSDB=ok X25=ok ISDN=ok 
> RT=ok NSAP=ok NSAP-PTR=ok SIG=ok KEY=ok PX=ok GPOS=ok =ok LOC=ok NXT=ok 
> SRV=ok NAPTR=ok KX=ok CERT=ok A6=ok DNAME=ok APL=ok DS=ok SSHFP=ok 
> IPSECKEY=ok RRSIG=ok NSEC=ok DNSKEY=ok DHCID=ok NSEC3=ok NSEC3PARAM=ok 
> TLSA=ok SMIMEA=ok HIP=ok CDS=ok CDNSKEY=ok OPENPGPKEY=ok CSYNC=ok ZONEMD=ok 
> SPF=ok NID=ok L32=ok L64=ok LP=ok EUI48=ok EUI64=ok URI=ok CAA=ok AVC=ok 
> DOA=ok AMTRELAY=ok TA=ok DLV=ok TYPE1000=ok
> [beetle:~/DNS-Compliance-Testing] marka%
>
>
> -R set RD=1.
> -t test know types
> -f full test set (excludes types)
>
>
> > I'm putting it back in Revised ID needed; please address the comments,
> > or I will be forced to send it back to the WG
> >
> > W
> >
> >> 2: that Section 3 is confusing, and that Matt had provided some text
> >> which helps make this better --
> >> https://mailarchive.ietf.org/arch/msg/dnsop/_Nq8PAVOapIVal2BS7P-jlWmnuc
> >>
> >> Having reread section 3 (and Matt's suggestions) I agree with Stephane
> >> on both of these - I also think that addressing these should be quite
> >> easy (I don't think it requires a "restructuring"), especially as Matt
> >> has provided suggested text...
> >> I'd appreciate if you can address these, and SHOUT LOUDLY once you've
> >> had a chance to do so (or let me know how else you'd like to handle
> >> this).
> >>
> >> I also think that it would be worth adding an Acknowledgements section...
> >>
> >> Thanks,
> >> W
> >>
> >>
> >>
> >> On Thu, Dec 5, 2019 at 9:00 PM The IESG  wrote:
> >>>
> >>>
> >>> The IESG has received a request from the Domain Name System Operations WG
> >>> (dnsop) to consider the following document: - 'A Common Operational 
> >>> Problem
> >>> in DNS Servers - Failure To Communicate.'
> >>>   as Best Current Practice
> >>>
> >>> The IESG plans to make a decision in the next few weeks, and solicits 
> >>> final
> >>> comments on this action. Please send substantive comments to 

Re: [DNSOP] DNS for Cloud Resources in draft-ietf-rtgwg-net2cloud-problem-statement-08

[Morizot Timothy S]

Yes, I believe that suggestion is much stronger and expresses the intent and 
meaning better.

Thanks,

Scott

-Original Message-
From: DNSOP  On Behalf Of Hollenbeck, Scott
Sent: Wednesday, March 11, 2020 1:19 PM
To: linda.dun...@futurewei.com
Cc: dnsop@ietf.org
Subject: [DNSOP] DNS for Cloud Resources in 
draft-ietf-rtgwg-net2cloud-problem-statement-08

Could we make the last sentence stronger, perhaps with a statement like this 
from the US CERT WPAD Name Collision Vulnerability alert dated May 23, 2016?

"Globally unique names do prevent any possibility of collision at the present 
or in the future and they make DNSSEC trust manageable. Consider using a 
registered and fully qualified domain name (FQDN) from global DNS as the root 
for enterprise and other internal namespaces."

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

[DNSOP] DNS for Cloud Resources in draft-ietf-rtgwg-net2cloud-problem-statement-08

[Hollenbeck, Scott]

(Sorry, this is a late response to a review request original sent to the dnsop 
list on 11 February)

Section 3.4 (DNS for Cloud Resources) includes these sentences:

"Globally unique names do prevent any possibility of collision at the present 
or in the future and they make DNSSEC trust manageable. It's not as if there is 
or even could be some sort of shortage in available names that can be used, 
especially when subdomains and the ability to delegate administrative 
boundaries are considered."

Could we make the last sentence stronger, perhaps with a statement like this 
from the US CERT WPAD Name Collision Vulnerability alert dated May 23, 2016?

"Globally unique names do prevent any possibility of collision at the present 
or in the future and they make DNSSEC trust manageable. Consider using a 
registered and fully qualified domain name (FQDN) from global DNS as the root 
for enterprise and other internal namespaces."

https://www.us-cert.gov/ncas/alerts/TA16-144A

The alert actually says "other internal namespace", but I think that's a typo.

Scott

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

[DNSOP] Éric Vyncke's Yes on draft-ietf-dnsop-7706bis-10: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-dnsop-7706bis-10: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-7706bis/



--
COMMENT:
--

Thank you for the work put into this document. With the heavy load on this week
telechat and the workload related to the cancellation of the IETF-107 in-person
meeting, I must admit that this review was not as thorough as I had hope :-(

Please find below some non-blocking COMMENTs and NITs. An answer will be
appreciated to my first comment (and possible the other ones).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Out of curiosity, was it considered to run the 'mirror root' on one global
anycast address of the root server, e.g., 2001:7fd::1, and modify the root
cache to only have this one? (I am sure that you know that Linux can have a
'local' route for any IPv4/IPv6 address to the loopback)

-- Section 1 --
Very minor, s/their customers,/their clients,/ as there is not always a contract

s/during network attacks/during network attacks against the root servers/ ?

The sentence in parenthesis "(Although the..." is important and deserves a
paragraph on its own IMHO.

-- Appendix B --
"were checked recently" means little thing... can you replace with "March 2020"
?

-- Section B.1 --
I would have preferred the use of "::1" rather than "127.12.12.12;" in the
example...



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

[DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-rfc2845bis-07: (with COMMENT)

[Mirja Kühlewind via Datatracker]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dnsop-rfc2845bis-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/



--
COMMENT:
--

I only had limited time for a quick review of this document, so I might not be
aware of all the needed background and details. Still I have two quick
questions on retries:

1) Sec 5.2.3:
"Implementations should be aware
   of this possibility and be prepared to deal with it, e.g. by
   retransmitting the rejected request with a new TSIG once outstanding
   requests have completed or the time given by their time signed plus
   fudge value has passed."
I might not be aware of all protocol details and maybe this is already
specified somewhere: While unlikely, it is possible that a request might be
retransmitted multiple times, as that could cause president congestion over
time, it's always good practice to define a maximum number of retransmissions.
If that is already defined somewhere, maybe adding a note/pointer would be good
as well.

2) Sec 5.3.1:
"   This allows the client to rapidly detect when the session has been
   altered; at which point it can close the connection and retry."
When (immediately or after some waiting time) should the client retry and how
often? You further say "The client SHOULD treat this the
   same way as they would any other interrupted transfer (although the
   exact behavior is not specified here)."
Where is that specified? Can you provide a pointer in the text?

3) Sec 8.  Shared Secrets: Would it be appropriate to use more normative
language here? There are a bunch of lower case shoulds in this section; is that
on purpose?



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

[DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-17.txt

[internet-drafts]

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 WG of the IETF.

Title   : A Common Operational Problem in DNS Servers - Failure 
To Communicate.
Authors : M. Andrews
  Ray Bellis
Filename: draft-ietf-dnsop-no-response-issue-17.txt
Pages   : 26
Date: 2020-03-11

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 zone operators to apply to
   identify and remediate the problem.

   The document does not look at the DNS data itself, just the structure
   of the responses.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-17
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-no-response-issue-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-no-response-issue-17


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/


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