[DNSOP]Re: Second (short) WGLC for draft-ietf-dnsop-zoneversion

[Wessels, Duane]

Hi Donald,

Thanks for the suggestions.  We’ve implemented all your suggested changes in 
the source document.  We’ll wait a few days for any more changes and then 
publish a new revision.

DW


> On May 12, 2024, at 1:30 AM, Donald Eastlake  wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> 
> 
> Hi,
> 
> I support this draft but have the following comments:
> 
> I would assume this has been discussed before but, presumably, the purpose of 
> this document is to see that the zoneversion option will interoperate between 
> different implementations. So, why isn't it Standards Track?
> 
> NSID should be expanded on first use and a reference to RFC 5001 added.
> 
> Section 2: The first line is sort of run-on at the end of the line. Suggest 
> some more parentheses;
> OLD
>This document specifies a new EDNS(0) Section 6.1.2 of [RFC6891]
> NEW
>This document specifies a new EDNS(0) (Section 6.1.2 of [RFC6891])
> 
> Section 6: "In special for"? Maybe "In gratitude for"? or probably better yet 
> "Special thanks for"
> 
> Section 8: There are other ways to obtain trustworthiness. Suggest the 
> following:
> OLD
>be necessary to use an encrypted and authenticated DNS transport.
> NEW
>be necessary to use an encrypted and authenticated DNS transport, TSIG 
> [RFC8946], or SIG(0) [RFC2931].
> 
> Very minor: The RFC Editor understands "[this document]" and "TBD". All the 
> current RFC Editor instructions in this draft are superfluous and could be 
> deleted.
>   
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
> 
> 
> On Tue, May 7, 2024 at 10:25 PM Suzanne Woolf 
>  wrote:
> Colleagues, 
> 
> 
> Back in October 2023, the WG requested publication of "The DNS Zone Version 
> (ZONEVERSION) Option" 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). 
> 
> When our AD reviewed it before taking it to IETF Last Call, he felt there 
> were some issues that needed to be addressed, and returned it to the WG. At 
> the time, the chairs asked the authors to address the comments, and told the 
> WG we'd run another WGLC before requesting publication again.
> 
> The authors have addressed Warren's comments, so we're opening a 1-week WGLC 
> on the revised zoneversion document. Please review the new version and speak 
> up on the list to support advancing it or tell us where you think it still 
> needs work.
> 
> We'll close the WGLC in one week, May 15.
> 
> Current version: 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/
> Warren's AD review: 
> https://mailarchive.ietf.org/arch/browse/dnsop/?q=%22AD%20Review%3A%20draft-ietf-dnsop-zoneversion%22
> Diff : 
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-zoneversion-05
> 
> 
> Thanks,
> Suzanne (for the chairs)
> 
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-qdcount-is-one

[Wessels, Duane]

I’ve reviewed qdcount-is-one-02 and find it to be ready for publication as an 
RFC.

DW
 


> On Mar 5, 2024, at 6:51 AM, Suzanne Woolf  wrote:
> 
> Hi,
> 
> We're leaving this open a few more days to allow for any other comments. We'd 
> like to submit it for publication before IETF 119.
> 
> 
> Thanks,
> Suzanne
> For the chairs
> 
>> On Feb 15, 2024, at 10:57 AM, Suzanne Woolf  wrote:
>> 
>> Hi,
>>  
>> The qdcount draft is brief and straightforward, and there have been no new 
>> changes proposed or issues introduced since the -01 version was posted. We 
>> think there’s likely consensus to advance it for publication.
>>  
>> This note starts a Working Group Last Call for 
>> draft-ietf-dnsop-qdcount-is-one.
>>  
>> Current version of the draft is available here: 
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-qdcount-is-one/ 
>> 
>>  
>> The Current Intended Status of this document is: Proposed Standard
>>  
>> Please review the draft and offer relevant comments.
>>  
>> For WGLC, we need positive support and constructive comments; lack of 
>> objection is not enough. So if you think this draft should be published as 
>> an RFC, please say so.
>>  
>> If you feel the document is *not* ready for publication, please speak out 
>> with your reasons.
>>  
>> This starts a two week Working Group Last Call process, and ends on:  29 
>> February, 2024.
>>  
>> thanks,
>> Suzanne (for the chairs)
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/18BZXO046m-S-gFeTS8XVcBsn9c8bXsZLW_u3jUtVr3RvaQjL6K1zd0EeNxHSeBG8rRzmBD0skEhWfjqDfjet_3mXJAWwn_kG94MFRIEQrA6ucQRfzAUFMzMwdrz1P8lCnXIwK8oJWEiyeY6x6HzH-XvLrcZpzOqqzJhCIHidCQv2B9XsjiUdWoxLTwwqEb35o6GYSm67GIxNfKHWw6KBxtUXzFM-WkA0cY4LHZGgNwdPEYRNkczNlmIiGK_JeHj39iGlhOf_mpLCvzTp7E6CZdxg8snEGSdjLFNcijnvz5o/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt

[Wessels, Duane]

Hi, some initial thoughts:

RFC 2181 says "Data from a zone transfer, other than glue” but this draft 
doesn’t make any exceptions for glue or non-authoritative data from a zone 
transfer.  Is that intentional?

Should RFC 8767 stale data be ranked differently than fresh data?

Should EDNS Client Subnet play into ranking?

DW




> On Mar 4, 2024, at 6:37 PM, Benno Overeinder  wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
>  Forwarded Message 
> Subject: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt
> Date: Mon, 04 Mar 2024 13:12:26 -0800
> From: internet-dra...@ietf.org
> To: i-d-annou...@ietf.org
> 
> Internet-Draft draft-toorop-dnsop-ranking-dns-data-00.txt is now available.
> 
>   Title:   Ranking Domain Name System data
>   Authors: Paul Hoffman
>Shumon Huque
>Willem Toorop
>   Name:draft-toorop-dnsop-ranking-dns-data-00.txt
>   Pages:   4
>   Dates:   2024-03-04
> 
> Abstract:
> 
>   This document extends the list ranking the trustworthiness of domain
>   name system (DNS) data (see Section 5.4.1 of [RFC2181]).  The list is
>   extended with entries for root server names and addresses built-in
>   resolvers, and provided via a root hints file with the lowest
>   trustworthiness, as wel as an entry for data which is verifiable
>   DNSSEC secure with the highest trustworthiness.  This document
>   furthermore assigns ranked values to the positions of the list for
>   easier reference and comparison of trustworthiness of DNS data.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://secure-web.cisco.com/1-KFlj_oYrZOH-5BhyKqBeDYA57SqQxpkiil5nsPhQR9QBqNk5C1dftYIqaAaBo55ch7u5zlzSyavgTQh3U4JVQSRVGLu4rDLk6FjqWp5kurgOW2oqCka2YyZ9SzqiOfjQbUP2XEQi9izTnWo90VgorxeKRntDUgxyVOYihvFygAM6nuXgV8jBlXpMb2pxDPAfbX70Wv0uqDcZiq1A979EWVqSt9MCvNxQr2kerBKq7OAzltfygzvl6X_KUg8Hoq1R3TOzWDL9uJCJdiWawGKtp80A9QP2MuAXF70_-cRUAI/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-toorop-dnsop-ranking-dns-data%2F
> 
> There is also an HTMLized version available at:
> https://secure-web.cisco.com/1MS_L_uLvJbHCh42n3cgkh_vZRkcg-dAAs_ThN8dzzEXCzyNrE60Pow2LR2HWuKjY1rtp9zIXQPO9QWmDyKZ3drYTqpRRPAhOG408US3yeZ_ybTUwx5ZmGVFIDhhZCDyIuP4Rg_kj_e4KE4mxsKgzgEfIQdwq7bK01e2Edkb4wSY0JIrc-Hzwsw6uz-xNn84Qrb8f3ltQ4Ei9RGjHCnWzJ4NFCNmChSwQ7D9QkgFVPeZKGEVSEIwpohbW91IyDYpcHAs4A1RD-dezuELyugLuLafMYiooQeTs6JwhnK9UPXc/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-toorop-dnsop-ranking-dns-data-00
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/1tsEMQC3Zecz5o61auTq0E97pflQrX3OHLUXtw4gyrJms3GEbkEmq1XikMPMvYLfFtsbpF0ywAkAOP674RMmrkeAJCnXXx9NyLN0KU9uKmvS3lhZ4ste6C9PM-fjBLzZQeg8oaUexDd7FDoDEkx6l4vrXi5QadmS-ZydnLgKxJsLB2arRZlHXiMm_UXCLHZWYGwTlCYoxupX1buUc3jOw3QN7hp6TmPsUEaNJUIJoiustJUfO4pppH1yzrjf_B9-bnwZJBnApnH_AL9Dep-ELQxFrkCKXZONXLa_VZgKV50M/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop
> 



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Editorial Errata Reported] RFC9520 (7838)

[Wessels, Duane]

This errata seems to be valid. I have no idea why the DOI reference changed, 
but it appears to have changed since it was added to the document in 
November/December last year.

DW


> On Mar 5, 2024, at 9:02 PM, RFC Errata System  
> wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> The following errata report has been submitted for RFC9520,
> "Negative Caching of DNS Resolution Failures".
> 
> --
> You may review the report below and at:
> https://secure-web.cisco.com/1VbjSuWJx5oy1T-Ua7n1iI_SDgRrTt_Lvn9n-UDSifjZm8QaU9N4sQvIa93jzMNm9w2ZAEu2ZZOYvMsD2D7ioZ9QHTqV8jEHryfvOC9Tx53J1SGMrtcSZrHU0FlPrghJ9G7LQdzR6tAz3HpXQAu2riJ5I8LEqNUq0dskyvGu82WhekS82imHk9yVzGp8u8ozw9c-NL3ntpHCse3uefxc2S0p23gjiNSuXw-QixLt5evJjNhvMN3tmNfYG3pVeW77qaEXObECupbCrui7iTlHdbWBWQfvGlBDXEnNuROJctlQ/https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid7838
> 
> --
> Type: Editorial
> Reported by: Xiang Li 
> 
> Section: 7.2
> 
> Original Text
> -
> [TuDoor]
> ...
> DOI 10.1109/SP54263.2024.00046, 2024, 
> .
> 
> 
> Corrected Text
> --
> [TuDoor]
> ...
> DOI 10.1109/SP54263.2024.00172, 2024, 
> .
> 
> 
> Notes
> -
> The reference link has changed to 10.1109/SP54263.2024.00172 from 
> 10.1109/SP54263.2024.00046
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --
> RFC9520 (draft-ietf-dnsop-caching-resolution-failures-08)
> --
> Title   : Negative Caching of DNS Resolution Failures
> Publication Date: December 2023
> Author(s)   : D. Wessels, W. Carroll, M. Thomas
> Category: PROPOSED STANDARD
> Source  : Domain Name System Operations
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] unrelated name server name recommendation

[Wessels, Duane]

I understood Fujiwara’s proposal to be slightly different:

If you are a DNS provider (hosting other zones) then the provider should use 
in-domain name servers.

DW


> On Mar 4, 2024, at 3:14 PM, Paul Wouters  wrote:
> 
> On Mar 4, 2024, at 14:04, Paul Vixie  
> wrote:
>> 
>> 
>> 
>> this means a zone will always be reachable through at least one in-zone data 
>> path (name server name and associated address records.) the result would be 
>> that a full resolver would never have to pause its current lookup while 
>> searching for address records matching an out-of-zone name server name.
>> 
>> i think it's a solid recommendation,
> 
> It means every registrant, who doesn’t know about DNS, has to create host 
> objects for glue and whenever the ISP changes nameserver names (eg gets 
> bought, sold or merges), or IP address, the ISP has to talk to the registrant 
> to fix things at their registry. I can promise you those in-domain name 
> servers will quickly become very unreliable.
> 
> Paul
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/1a3MNvrMgvJke3ozLjb1HCuRHhuKPU4kcf25J9eCUq4p-aOa0Aqy6qmiTdxMr02KJy3Ai80ZFNKl9j_c-7cA3MZpUD5480mMQT5pKWiSiUhWWeiTjjFCC6bZdqrh-FHCqvl1sM64AGrDIt4zjPKgcxERVilTSw7U3KPYhiGQ1IMY8wwa-dVkcU7s4T0z9flJabKEE7sH-IvWVC-Sv4i0fKZUk1g-ek5vkhx5JIA8TeMvtjP17WZaKrO79M9HpU6TNwB0ypkRbRMX8btrJZ9nSBar6W3gL2W4TKNRPrzyBFB8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis

[Wessels, Duane]

Paul,

Here is some specific proposed text to address the concern that I raised:

Whereas the priming response is not a referral, and whereas root server 
addresses in the priming response are therefore not considered glue records, 
RFC 9471 does not apply to the priming response.  Root servers are not required 
to set the TC bit in a priming response if not all root server addresses fit 
within message size constraints.  There are no requirements on the number of 
root server addresses that a root server must include in a priming response.

DW


> On Feb 6, 2024, at 1:39 PM, Paul Hoffman  wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> I have submitted -03, which covers the issues you raised in your AD review. 
> Note that Duane and Mark had more to say on the topic of TC from the roots, 
> but there was no agreement nor specific text proposed.
> 
> --Paul Hoffman
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/1U98vDfdUh-VITwB6fwCdeqAzIC9TAvh0PR_dhvmt312mdwsd3QwvIEi-5zkK2xu5FUXbFHbmHJcNnRuHmVo-Jx9ivcmH95-tpEO5qRBER-_VrCnmKhOgfexsfCYyO_ZNUJQFVBawYfduf9BON3TGTLvMpU0Sd5rZ3VrOwCT36kCNdYxsZlsoo1N0zj3wxa6taF1TiJRt2miLLyya4F70bPtuGI4WU5INGMxnDlLyMgKX0cjpJMtvwupkhZD-UTik4mNpuD08puUESib8l0rMhwAnUCz9FfA-rz4dNa-Deqc/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop
> 



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis

[Wessels, Duane]

> On Jan 31, 2024, at 5:57 PM, Paul Hoffman  wrote:
> 
>> As Mark just clarified. This isn't glue, so perhaps the text just needs
>> updating.
> 
> The current text is:
> 
> If some root server addresses are omitted from the Additional section, 
> there is no expectation that the TC bit in the
> response will be set to 1. At the time that this document is written, many of 
> the
> root servers are not setting the TC bit when omitting addresses from the 
> Additional section.
> 
> Note that  updates  with 
> respect to the use of the TC bit.
> It says "If message size constraints prevent the inclusion of all glue 
> records for in-domain name servers,
> the server must set the TC (Truncated) flag to inform the client that the 
> response is incomplete
> and that the client should use another transport to retrieve the full 
> response."
> 
> Maybe we should add to the second paragraph:
> 
> Note, however, the root server addresses are not glue records, so setting the 
> TC bit in truncated responses from
> the root servers is not required by RFC 9471.
> 
> Does this solve your and Warren's issues?


I have to confess that “root server addresses are not glue records” is a very 
subtle point that was lost on me, and
maybe lost on a lot of us, as evidenced by this discussion.

I’m not particularly comfortable with the terseness of the statement above.  
The terminology RFC doesn’t really help here because it doesn’t provide a 
definition of what glue is glue or what is not glue.  It just references 
semi-conflicting statements in other RFCs.  

So I think if 8109bis is going to make the statement that root server addresses 
are not glue, it deserves more explanation of why that is the case.

I also worry that it creates a new problem, which is what sort of truncation 
policy applies to a priming response?  If RFC 9471 does not apply, does RFC 
2181 Section 9 apply?  Is a priming response with zero root server IP addresses 
acceptable?

DW
 



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Wessels, Duane]

I made a pass through the document and have the following feedback.


> Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034].  The
> scenario used in that description, that of a recursive server that is
> also authoritative, is no longer as common.

Since RFC 1034 doesn't use the term "priming" maybe it would be good to be more 
descriptive here? For example:

   Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034], where
   it is referred to as a "safety belt" or part of the SBELT structure.

> Research shows that after those addresses change, some resolvers
> never get the new addresses.

If you feel like this would benefit from a reference, 
https://indico.dns-oarc.net/event/24/contributions/378/ is one such that would 
fit.

> Root server
> identifier and address changes are the main reasons that resolvers
> need to do priming instead of just going from a configured list to
> get a full and accurate list of root servers.

I find "to get a full..." at the end here to be confusing.  Maybe a slight 
reordering and rewording?

   Root server identifier and address changes are the main reasons that
   resolvers need to use priming to get a full and accurate list of root
   servers, instead of just using a statically configured list.

> A priming query is a DNS query used to get the root server
> information in a resolver.

I find the above imprecise.  Perhaps:

   A priming query is a DNS query whose response provides root server
   names and addresses.

> If a resolver chooses to pre-fetch the root NS RRset before that
> RRset has expired in its cache, it needs to choose whether to use the
> addresses for the root NS RRset that it already has in its cache or
> to use the addresses it has in its configuration.  Such a resolver
> SHOULD send queries to the addresses in its cache in order to reduce
> the chance of delay due to out-of-date addresses in its
> configuration.

This section doesn't say what a non-pre-fetching resolver should do.
Does it imply or mean that a non-pre-fetching resolver can only re-prime
from the original configuration?

> Resolver software SHOULD NOT expect 13 NS RRs because

This is somewhat out of the blue.  There is no prior discussion on the number of
root server identifiers.  Although there is immediately after...

> If the Additional section is truncated, there is no expectation that
> the TC bit in the response will be set to 1.  At the time that this
> document is written, many of the root servers are not setting the TC
> bit on responses with a truncated Additional section.

I think I tried to argue about this phrasing before, but looks like I was 
unsuccessful.
IMO truncated should mean TC=1 and TC=1 should mean truncated.  I don't think
its okay to say that a message can be truncated but TC bit not set.  RFC 1035 
says:

TCTrunCation - specifies that this message was truncated
due to length greater than that permitted on the
transmission channel.

It would be better to use "partial" instead of "truncated" here.  e.g.:

   If the Additional section contains a partial set of A /  RRsets, there 
is no expectation that
   the TC bit in the response will be set to 1.  At the time that this
   document is written, many of the root servers are not setting the TC
   bit on responses when not all A /  RRsets fit in the Additional section.

DW


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

Re: [DNSOP] DNS IPv6 Transport Operational Guidelines (draft-momoka-dnsop-3901bis-00)

[Wessels, Duane]

Hi Momoka,

I see that your draft often uses “in-bailiwick” or “out-of-bailiwick”.  If you 
are not already aware, the latest version of the DNS terminology document 
(draft-ietf-dnsop-rfc8499bis) notes that “bailiwick” should be considered 
historic at this point.  The preferred language is to refer to the relationship 
between the NS record owner name, the name in the NS RDATA and the zone origin 
as either in-domain, sibling domain, or unrelated.

DW

From: DNSOP  on behalf of Momoka Yamamoto 

Date: Sunday, October 22, 2023 at 11:13 AM
To: dnsop 
Cc: "tfie...@mpi-inf.mpg.de" 
Subject: [EXTERNAL] [DNSOP] DNS IPv6 Transport Operational Guidelines 
(draft-momoka-dnsop-3901bis-00)


Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hello DNSOP Working Group,

My name is Momoka Yamamoto and I've recently submitted an Internet-Draft titled 
"DNS IPv6 Transport Operational Guidelines" (draft-momoka-dnsop-3901bis-00) 
with my co-author Tobias tfie...@mpi-inf.mpg.de. 
This draft discusses the operational guidelines for operating authoritative and 
recursive DNS servers in mixed IPv4 and IPv6 environments, expanding on RFC3910 
to address the progressing IPv4 exhaustion and the long-term necessity of 
IPv6-only resolvers.

I would greatly appreciate any feedback, comments, or questions you may have 
regarding this draft. I believe this document could contribute significantly to 
the current discussions and work of the DNSOP working group, especially in 
light of the wide adoption of IPv6 over the last 20 years since BCP91 was 
written.

The draft is open for discussion and I am looking forward to engaging with the 
community to refine and improve it.
Momoka Y

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Mon, Oct 23, 2023 at 3:02 AM
Subject: New Version Notification for draft-momoka-dnsop-3901bis-00.txt
To: Momoka Yamamoto mailto:momoka@gmail.com>>, Tobias 
Fiebig mailto:tfie...@mpi-inf.mpg.de>>


A new version of Internet-Draft draft-momoka-dnsop-3901bis-00.txt has been
successfully submitted by Momoka Yamamoto and posted to the
IETF repository.

Name: draft-momoka-dnsop-3901bis
Revision: 00
Title:DNS IPv6 Transport Operational Guidelines
Date: 2023-10-20
Group:Individual Submission
Pages:9
URL:  
https://www.ietf.org/archive/id/draft-momoka-dnsop-3901bis-00.txt
Status:   
https://datatracker.ietf.org/doc/draft-momoka-dnsop-3901bis/
HTML: 
https://www.ietf.org/archive/id/draft-momoka-dnsop-3901bis-00.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-momoka-dnsop-3901bis


Abstract:

   This memo provides guidelines and documents Best Current Practice for
   operating authoritative and recursive DNS servers given that queries
   and responses are carried in a mixed environment of IPv4 and IPv6
   networks.  It expands beyond [RFC3910] in so far that it now
   considers the reality of progressing IPv4 exhaustion, which will make
   IPv6-only resolvers necessary in the long-term.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   

Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

[Wessels, Duane]

> On Sep 20, 2023, at 2:23 PM, Paul Wouters  wrote:
> 
> 
>>>   To prevent such unnecessary DNS traffic, security-aware resolvers
>>>   MUST cache DNSSEC validation failures, with some restrictions.
>>> 
>>> What are these "some restrictions" ?
>> 
>> Here our intention is to update this statement from RFC 4035 so that MAY
>> becomes MUST and "invalid signatures" becomes "validation failures while
>> leaving the "some restrictions" in place.  AFAICT the restrictions that 4035
>> talks about are using short TTLs (as above) and (I think) to have some
>> query threshold for caching validation failures.  i.e., retry before
>> caching.
> 
> Should some of this make it into the document so the reader understands
> the "some restrictions" ?
> 


Sure, how about this:

   One of the restrictions mentioned in [RFC4035] is to use a small TTL
   when caching data that fails DNSSEC validation.  This is, in part,
   because the provided TTL cannot be trusted.  The advice from
   Section 3.2 herein can be used as guidance on TTLs for caching DNSSEC
   validation failures.

DW

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

Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

[Wessels, Duane]

> On Sep 6, 2023, at 8:56 PM, Paul Wouters via Datatracker  
> wrote:
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for this document and my apologies for being involved/related to two
> of the five outages you described :-)

Ha! :-)

> 
> 
>Consistent with [RFC2308], resolution failures MUST NOT be cached
>for longer than 5 minutes.
> 
> If an expired RRSIG has a TTL of 3600, what should happen? The resolution
> failed because the signature is no longer valid but the individual
> components of this validation failure are all successful lookups of RRs that
> are now in the cache.  Wouldn't this result in a resolution failure of
> 3600? How would an implementation limit this to 5 minutes? By deleting
> the RRSIG from its cache within 5 minutes, overriding its TTL?
> 
> If so, is there value stating this in the document?

Section 4.7 of RFC 4035 talks about the “BAD cache” where an implementation can
cache data with invalid signatures.  It says:

   o Since RRsets that fail to validate do not have trustworthy TTLs,
 the implementation MUST assign a TTL. This TTL SHOULD be small,
 in order to mitigate the effect of caching the results of an
 attack.

I would expect an implementation to treat an expired signature the same
as described here, and not cache it for the full 3600 seconds in your
example, but rather the TTLs we talk about in this draft, from 1-300 seconds
(ideally with backoff).

> 
> 
>also known as 'lame'
> 
> I thought the WG agreed the definition of 'lame' was not agreed upon and
> the term is no longer being favoured for use. Why not just remove this part?

In this text where lame appears we are simply quoting RFC 4697.  Given the
can of worms that was the lame delegation discussion, we are somewhat
reluctant to write more about it in this document.  Although we could make
a reference to the new terminology document if you think that would be helpful.


> 
>To prevent such unnecessary DNS traffic, security-aware resolvers
>MUST cache DNSSEC validation failures, with some restrictions.
> 
> What are these "some restrictions" ?
> 

Here our intention is to update this statement from RFC 4035 so that MAY
becomes MUST and "invalid signatures" becomes "validation failures while
leaving the "some restrictions" in place.  AFAICT the restrictions that 4035
talks about are using short TTLs (as above) and (I think) to have some
query threshold for caching validation failures.  i.e., retry before
caching.

DW




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

Re: [DNSOP] Éric Vyncke's Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

[Wessels, Duane]

> On Sep 7, 2023, at 4:08 AM, Éric Vyncke via Datatracker  
> wrote:
> 
> 
> 
> --
> COMMENT:
> --
> 
> 
> # Éric Vyncke, INT AD, comments for
> draft-ietf-dnsop-caching-resolution-failures-07
> 
> […]
> 
> # COMMENTS
> 
> ## Abstract
> 
> `RFC 2308 specifies requirements for DNS negative caching` should this
> statement only apply to (2) responses and not (1) responses (as this would be
> positive caching) ?

Yes indeed!  Glad you caught that.

> 
> ## Section 2.2 (and other places)
> 
> Is there a reason why EXAMPLE.COM is in uppercase in the text ? This is really
> unusual.

Fixed.

> 
> Please follow RFC 5952 and write IPv6 address is lower case (BTW thanks for
> using modern addressing)
> 

Fixed.  (Erik Kline beat you to it)

DW

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

Re: [DNSOP] Zaheduzzaman Sarker's No Objection on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

[Wessels, Duane]

> On Sep 7, 2023, at 2:32 AM, Zaheduzzaman Sarker via Datatracker 
>  wrote:
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for working on this specification. My review does yield any TSV related
> issues.
> 
> I have following minor comments that I believe will improve the document
> quality when addressed -
> 
>  # While this specification updates RFC2308, RFC4038 and RFC4697, the
>  Introduction section only mentions RFC2308. Would be good to give emphasis on
>  all the updates.

Good catch, this has been updated.

> 
>  # Regarding Motivation section, I like the motivation section up front and
>  understanding of the problem to solve before going into solution description.
>  So I would like to keep this section where it is.

Thank you.

> 
>  # Section 2 says -
> 
>If any one of the available servers provides a useful response, then it
>is not considered a resolution failure.
> 
>with that I am not sure why responses in section 2.1 and 2.2 are qualified
>as useful responses. Please add some clarification texts in those sections.


The types of responses described in 2.1 (SERVFAIL) and 2.2 (REFUSED) should not 
be
considered “useful”.  Rather they are NOT useful because they neither provide 
the
requested data, a referral, nor indicate that the requested data does not exist.

Since the meaning of useful might not be as clear as it could be, we would 
propose to
add this to the opening paragraph of section 2:

A response is considered
useful when it provides either the requested data, a delegation a 
descendant zone,
or an indication that no data exists at the given name.

Does that clear up the confusion?

DW

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

Re: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

[Wessels, Duane]

> On Sep 6, 2023, at 11:46 PM, Murray Kucherawy via Datatracker 
>  wrote:
> 
> 
> --
> COMMENT:
> --
> 
> Thanks to Barry Leiba for his ARTART review.
> 
> I think the SHOULD in Section 3.2, paragraph 2, is not appropriate use of
> SHOULD as it doesn't address interoperability or operations or security
> recommendations.  A regular "should" is fine.

Thanks for the suggestion.  We’ve made that change.


DW

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

Re: [DNSOP] Robert Wilton's Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

[Wessels, Duane]

> On Sep 5, 2023, at 3:52 AM, Robert Wilton via Datatracker  
> wrote:
> 
> --
> COMMENT:
> --
> 
> Hi,
> 
> Thanks for working on this document - I'm not a DNS expert but it looks like 
> good advice.
> 
> A couple of minor comments for your consideration:
> 
> (1) p 2, sec 1.  Introduction
> 
>   This document updates [RFC2308] to require negative caching of DNS
>   resolution failures and provides additional examples of resolution
>   failures.
> 
> Perhaps "caching of all DNS resolution failures"?

Agreed.

> 
> 
> (2) p 2, sec 1.1.  Motivation
> 
>   RFC Editor: We'd like your thoughts on moving the Motivation and
>   Related Work sections to appendices.  Is that a preferred style?
> 
> Not the RFC editor, but I would keep the motivation here, as a subsection of 
> the introduction.

Excellent, thanks for the feedback.

DW

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

Re: [DNSOP] Intdir telechat review of draft-ietf-dnsop-caching-resolution-failures-07

[Wessels, Duane]

Carlos,

Thank you for the suggestions.  We’ve made all these changes.

DW


> On Sep 6, 2023, at 1:59 PM, Carlos Pignataro via Datatracker 
>  wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> Reviewer: Carlos Pignataro
> Review result: Ready
> 
> Hi!
> 
> draft-ietf-dnsop-caching-resolution-failures
> Review type: intdir - Telechat review
> Reviewer: Carlos Pignataro 
> 
> I find this a complete and well written document. Only some minimal nits for 
> your consideration:
> 
> 2.  Conditions That Lead To DNS Resolution Failures
> 
> CMP> "to"   
> 
> 
> 3.2.  Caching
> 
>   Resolvers SHOULD employ an exponential or linear backoff algorithm to
>   increase the cache duration for persistent resolution failures.  For
>   example, the initial time for negatively caching a resolution failure
>   might be set to 5 seconds, and increased after each retry that
>   results in another resolution failure, up to a configurable maximum,
>   not to exceed the 5 minute upper limit.
> 
> CMP> "5-minute"
> 
> 
> 3.3.  Requerying Delegation Information
> 
>   The problem of aggressive requerying to parent zones is not limited
>   to queries of type NS.  This document updates the requirement from
>   section 2.1.1 of [RFC4697] to apply more generally: Upon encountering
>   a zone whose name servers are all non-responsive, a resolver MUST
>   cache the resolution failure.  Furthermore, the resolver MUST limit
>   queries to the non-responsive zone's parent zone (and other ancestor
>   zones) just as it would limit subsequent queries to the non-
>   responsive zone.
> 
> CMP> "(and *to* other ancestor"
> 
> 
> 1.2.  Related Work
> 
>   An expired Internet Draft describes "The DNS thundering herd problem"
> 
> and
> 
> 10.2.  Informative References
> 
>   [thundering-herd]
>  Sivaraman, M. and C. Liu, "The DNS thundering herd problem
>  (expired Internet Draft)", June 2020,
> 
> 
> CMP> s/Internet Draft/Internet-Draft/g?
> 
> Thanks again!
> 
> Carlos.
> 
> 
> 

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

Re: [DNSOP] Erik Kline's No Objection on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

[Wessels, Duane]

> On Aug 27, 2023, at 3:47 PM, Erik Kline via Datatracker  
> wrote:
> 
> ## Nits
> 
> ### S1.2
> 
> * "only exacerbated" -> "further exacerbated"?
> 
>  Use of "only" here might be misread.
> 
> ### S2.2
> 
> * s/2001:DB8:1::/2001:db8:1::/g
> 
>  in accordance with RFC 5952 section 4.3
> 


Thanks Erik, I’ve made these changes to the document.

DW


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-07.txt

[Wessels, Duane]

DNSOP,

This version of the draft addresses various comments from the Artart, Genart, 
and Dnsdir reviewers:

   *  Artart review: minor editorial clarifications
   *  Genart review: remove confusing and superfluous section
  references.
   *  Genart review: clarify resolution failure caching time range.
   *  Genart review: better define DNS transports
   *  Dnsdir review: clarify FORMERR response retries.

DW


> On Aug 22, 2023, at 4:47 PM, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Domain Name System
> Operations (DNSOP) WG of the IETF.
> 
>   Title   : Negative Caching of DNS Resolution Failures
>   Authors : Duane Wessels
> William Carroll
> Matthew Thomas
>   Filename: draft-ietf-dnsop-caching-resolution-failures-07.txt
>   Pages   : 19
>   Date: 2023-08-22
> 
> Abstract:
>   In the DNS, resolvers employ caching to reduce both latency for end
>   users and load on authoritative name servers.  The process of
>   resolution may result in one of three types of responses: (1) a
>   response containing the requested data; (2) a response indicating the
>   requested data does not exist; or (3) a non-response due to a
>   resolution failure in which the resolver does not receive any useful
>   information regarding the data's existence.  This document concerns
>   itself only with the third type.
> 
>   RFC 2308 specifies requirements for DNS negative caching.  There,
>   caching of type (1) and (2) responses is mandatory and caching of
>   type (3) responses is optional.  This document updates RFC 2308 to
>   require negative caching for DNS resolution failures.
> 
>   RFC 4035 allows DNSSEC validation failure caching.  This document
>   updates RFC 4035 to require caching for DNSSEC validation failures.
> 
>   RFC 4697 prohibits aggressive requerying for NS records at a failed
>   zone's parent zone.  This document updates RFC 4697 to expand this
>   requirement to all query types and to all ancestor zones.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-caching-resolution-failures/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-caching-resolution-failures-07
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-caching-resolution-failures-07
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/1xhHP4VLQU5cOfCVEYviz3Xe_zigUgwRx4lgc4GJH6EcH9YgPMiS0mJ4bXYeGdOAH4CcwK6hjzuoP8H1tyglsbc6aCN-G6lUXhozvkS8QdNY331E0DULUvm9YUqAeammQvXwtwOaikdoac4hJtLb5b_9-BUVH3cL-BjKNFrmjar_4DUIJrc8ZSr7SAHM9rBxdSBuF8sb8c8ZcOM6GqHKprLJSG2OMlg8wlC84hH9pIJuYDY1vK6QklKJ47SPwy6gFrYGf-d7JeW0sBnHfw2fvppMYjhP_FOPvNvz08bNId_0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop
> 

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

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-caching-resolution-failures-06

[Wessels, Duane]

> On Aug 11, 2023, at 5:36 AM, Lucas Pardue via Datatracker  
> wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> Reviewer: Lucas Pardue
> Review result: Ready with Issues
> 
> 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-caching-resolution-failures-??
> Reviewer: Lucas Pardue
> Review Date: 2023-08-11
> IETF LC End Date: 2023-08-17
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document was well-written with clear motivation statements and
> normative text for addressing the indicated problems

Hi Lucas, thanks for the detailed review.


> 
> Major issues: None
> 
> Minor issues:
> 
> * Section 3.1 describes retries and places the normative requirement "A
> resolver MUST NOT retry a given query to a server address over a given
> transport protocol more than ...". However, the definition of "transport
> protocol" is not 100% clear to me, and the terms "transport" and "transport
> layer protocol" seem to be used interchangeably through the document.  Perhaps
> this is clearer to those in the DNS area, but as a transport area person, DNS
> over TCP and DNS over TLS both use the same transport protocol. Section 2.3
> would seem to imply that DNS over TCP and DNS over TLS are treated as 
> different.
> 
> I think it would help to better define exactly what "a given transport
> protocol" in section 3.1 means. Perhaps that definition already exists
> somewhere that can be cited and imported into the terminology section.

You’re right that we have not been especially precise when using the word 
“transport.”
The authors did intend for DNS over UDP, over TCP, and over TLS, etc to 
essentially
be treated as separate transports, or separate ways a client can talk to a 
server.

I’m not sure how best to fix this.  On one hand, as far as we know, there is
currently not a good term that collectively refers to DNS over UDP, TCP, TLS, 
HTTPS,
QUIC, and whatever else may come our way.  So maybe we need to define one.  I’m
hesitant, though, because I’m not sure this document is where such a term should
be introduced, and because definitions often turn out to be like cans of worms.

Nonetheless, we have taken a stab at it:

   *  DNS Transport: In this document, DNS transport means a protocol
  used to transport DNS messages between a client and a server.
  This includes "classic DNS" transports, i.e., DNS-over-UDP and
  DNS-over-TCP [RFC1034] [RFC7766], as well as newer encrypted DNS
  transports such as DNS-over-TLS [RFC7858], DNS-over-HTTPS
  [RFC8484], DNS-over-QUIC [RFC9250], and similar communication of
  DNS messages using other protocols.  NOTE: at the time of this
  writing not all DNS transports are standardized for all types of
  servers, but may become standardized in the future.

…

3.1.  Retries and Timeouts

   A resolver MUST NOT retry a given query to a server address over a
   given DNS transport more than twice (i.e., three queries in total)
   before considering the server address unresponsive over that DNS
   transport for that query.

   A resolver MAY retry a given query over a different DNS transport to
   the same server if it has reason to believe the DNS transport is
   available for that server and is compatible with the resolver's
   security policies.







> 
> Nits/editorial comments:
> 
> * In section 1, there exists "section 5" and "section 7" usages that do make 
> it
> clear if these are internal or external references.

We propose to just remove those section references.

> 
> * I appreciated the text in sections 1.1 and 1.2, dealing with motivation and
> related use cases respectively. However, as a generalist reviewer, the most
> useful part of Section 1.1 was the first sentence. The remainder of the text 
> in
> 1.1 feels like case studies, that while interesting manifestations, are not
> pure motivation. As a purely editorial suggestion you can take or leave,
> consider modifying the last paragraph of Section 1 to something like
> 
> "Operators of DNS services have known for some time that recursive resolvers
> become more aggressive when they experience resolution failures; see Appendix 
> A
> for a collection of anecdotes, 

Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-06

[Wessels, Duane]

> On Aug 14, 2023, at 1:40 AM, Peter van Dijk via Datatracker 
>  wrote:
> 
> Reviewer: Peter van Dijk
> Review result: Ready with Nits
> 
> Thank you for processing my previous comments. The document is in great shape.
> I have one nit:
> 
> One of the new sections based on my earlier comments is "2.7.  FORMERR
> Responses". It currently says
> 
>> Upon receipt of a FORMERR response, recursive clients generally retry their
> queries without EDNS(0).
> 
> For most resolver implementations (Knot, Unbound, PowerDNS, but not BIND), 
> this
> is only true if the FORMERR response does not contain EDNS(0)/OPT. There are
> auths out there that send FORMERR+OPT responses, and they are not getting
> non-EDNS0 fallback behaviour from such resolvers.
> 
>> Thus, resolution failures from FORMERR responses are rare.
> 
> This, meanwhile, remains true. When they happen, they tend to be persistent,
> and noticed, leading to fixes.
> 
> I don't have a strong suggestion for rewording. Perhaps replace "recursive
> clients generally" with "some recursive clients might"? I can also live with
> the current text, but I did want to point out this nuance.
> 

Peter, thanks for the feedback.

How about this change to that paragraph?

   Upon receipt of a FORMERR response, some recursive clients will retry
   their queries without EDNS(0), while others will not.  Nonetheless,
   resolution failures from FORMERR responses are rare.

DW


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

Re: [DNSOP] Artart last call review of draft-ietf-dnsop-caching-resolution-failures-06

[Wessels, Duane]

Thanks Barry for the good feedback.  I've updated our source document with the 
changes you've suggested.

DW

On 8/9/23, 1:10 PM, "Barry Leiba via Datatracker" mailto:nore...@ietf.org>> wrote:



Reviewer: Barry Leiba
Review result: Ready with Nits


Thanks for a well-written document. I found the background information in
Section 1.1 to be particularly interesting. Just a couple of very small
editorial points there:


operating system vendor was providing non-root trust anchors to the
recursive resolver, which became out-of-date following the rollover.


Nit: This use of “out of date” should not be hyphenated, as it’s not directly
modifying anything (“out-of-date trust anchors” would be hyphenated, but “the
trust anchors are out of date” would not be).


In 2021, Verisign researchers used botnet query traffic to
demonstrate that certain large, public recursive DNS services exhibit
very high query rates when all authoritative name servers for a zone
return REFUSED or SERVFAIL [botnet]. When configured normally, query
rates for a single botnet domain averaged approximately 50 queries
per second. However, when configured to return SERVFAIL, the query
rate increased to 60,000 per second.


In the two “when configured” phrases it’s not clear what was configured,
normally and otherwise. Taken as written, it’s “query rates”, but those are
clearly not things that get configured. In trying to figure out what you *are*
referring to, I find that a reader could infer either “public recursive DNS
services” or “authoritative name servers”. Let’s not make readers work that
hard:


NEW
In 2021, Verisign researchers used botnet query traffic to
demonstrate that certain large, public recursive DNS services exhibit
very high query rates when all authoritative name servers for a zone
return REFUSED or SERVFAIL [botnet]. When the authoritative servers
were configured normally, query rates for a single botnet domain
averaged approximately 50 queries per second. However, with the
servers configured to return SERVFAIL, the query rate increased to
60,000 per second.
END


I have no other comments on the document, and I think it's ready to go.







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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-06.txt

[Wessels, Duane]

DNSOP,

Based on some discussions both in person at IETF 117 and on the list, we have 
updated some of the requirements language for caching resolution failures.  
We’ve also used an excerpt of Evan’s previous email to the list in the 
Implementation Status section of the document.  It would be nice to have 
additional notes from other implementations (open source and proprietary), if 
possible.

OLD:

Resolvers MUST cache resolution failures for at least 5 seconds. The
value of 5 seconds is chosen as a reasonable amount of time that an
end user could be expected to wait.

Resolvers SHOULD employ an exponential backoff algorithm to increase
the amount of time for subsequent resolution failures. For example,
the initial time for negatively caching a resolution failure is set
to 5 seconds. The time is doubled after each retry that results in
another resolution failure. Consistent with [RFC2308], resolution
failures MUST NOT be cached for longer than 5 minutes.

NEW:

Resolvers MUST cache resolution failures for at least 1 second.
Resolvers MAY cache different types of resolution failures for
different (i.e., longer) amounts of time. The minimum cache duration
SHOULD be configurable by the operator. A longer cache duration for
resolution failures will reduce the processing burden from repeated
queries, but may also increase the time to recover from transitory
issues.

Resolvers SHOULD employ an exponential or linear backoff algorithm to
increase the cache duration for persistent resolution failures. For
example, the initial time for negatively caching a resolution failure
might be set to 5 seconds, and increased after each retry that
results in another resolution failure, up to a configurable maximum.
Consistent with [RFC2308], resolution failures MUST NOT be cached for
longer than 5 minutes.


> On Jul 27, 2023, at 3:44 PM, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Domain Name System
> Operations (DNSOP) WG of the IETF.
> 
>   Title   : Negative Caching of DNS Resolution Failures
>   Authors : Duane Wessels
> William Carroll
> Matthew Thomas
>   Filename: draft-ietf-dnsop-caching-resolution-failures-06.txt
>   Pages   : 18
>   Date: 2023-07-27
> 
> Abstract:
>   In the DNS, resolvers employ caching to reduce both latency for end
>   users and load on authoritative name servers.  The process of
>   resolution may result in one of three types of responses: (1) a
>   response containing the requested data; (2) a response indicating the
>   requested data does not exist; or (3) a non-response due to a
>   resolution failure in which the resolver does not receive any useful
>   information regarding the data's existence.  This document concerns
>   itself only with the third type.
> 
>   RFC 2308 specifies requirements for DNS negative caching.  There,
>   caching of type (1) and (2) responses is mandatory and caching of
>   type (3) responses is optional.  This document updates RFC 2308 to
>   require negative caching for DNS resolution failures.
> 
>   RFC 4035 allows DNSSEC validation failure caching.  This document
>   updates RFC 4035 to require caching for DNSSEC validation failures.
> 
>   RFC 4697 prohibits aggressive requerying for NS records at a failed
>   zone's parent zone.  This document updates RFC 4697 to expand this
>   requirement to all query types and to all ancestor zones.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://secure-web.cisco.com/1LPtXLkDvbOCPxlDPD5CaqPhJ7pJBz5g4gpuyT27ndNKUQ3wwfnBWfT06g30XAy3DcfrXGxzwN7AOnwWFSUwO2p5fRIMROg3PmGMgm9koQ56YVb2nie1L3ddAM3hLdNhLDKeF9FwJoti8oUMc3pfK1WtEQrbGj1W5dJdeISiIdmzgoDHALFJPAubOwndXSSqG-LfcPrJEhosMik0RpL6DF8w66DrYysUMPO3HkV6coWXI-KHOjNIGzBGYu6pquvkNGpzdUORkeB-83KFpYsPFPS9HkJs6YSA3NKR21-LukxlO2n8VqysxtX3smdbrcsHW/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-caching-resolution-failures%2F
> 
> There is also an htmlized version available at:
> https://secure-web.cisco.com/1RuWnzxYtUSdl1039aW5onITseotw57Ca1Ta9aHPhFR16svfwpXkGztb-1bZ2bx1mTNVD2Vlp6WLRMZuCLjcvJNepxgZPQIVd8t34jnKOoyOjUKyzL1qVcOtWyZ1SIvMqpDSW6WvI5sCJ2mCOeFnAET87u0kmsyI40-VKlPmbseMjT02OYrcqBB_iY14PDHJ1CtDUjC1I-XoJLWNt-iLUEWqqvRgZNenndiIVT09hYTlWbYaBcXCdCynvFKRQrxnUTaf2npmSIoX0MljrxFllHZTvKi5XTQ7vtGCwt6MEelqaZL7W3xuMoEHI_iIjSjFz/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dnsop-caching-resolution-failures-06
> 
> A diff from the previous version is available at:
> 

Re: [DNSOP] A question on values in draft-dnsop-caching-resolution-failures

[Wessels, Duane]

Evan,

> On Jul 24, 2023, at 10:34 AM, Evan Hunt  wrote:
> 
> The original text says a series of seven resolution failures would increase
> the duration before a retry to five minutes: 5 seconds to 10 to 20 to 40 to
> 80 to 160 to 300. Lowering the starting value to one second means it would
> take nine failures to reach 300.
> 

It was not our intention that “2” would be the only possible exponent in the 
backoff
algorithm.  Would this slightly revised text be more agreeable?

   Resolvers SHOULD employ an exponential or linear backoff algorithm to 
increase
   the amount of time for subsequent resolution failures.  For example,
   the initial time for negatively caching a resolution failure is set
   to 5 seconds.  The time is increased after each retry that results in
   another resolution failure.  Consistent with [RFC2308], resolution
   failures MUST NOT be cached for longer than 5 minutes.


DW

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

Re: [DNSOP] A question on values in draft-dnsop-caching-resolution-failures

[Wessels, Duane]

Tim,

You said you received some operational feedback.  I wonder if it would be 
appropriate to add this operational (or implementation?) feedback to the 
(currently empty) Implementation Status section that Peter van Dijk suggested 
we add, in his DNS directorate review?

I’m not necessarily opposed to reducing the minimum caching time from 5 to 1, 
especially if we can document valid reasons for doing so.  However, I do think 
it is going a bit to far to weaken both the minimum caching time and the 
requirement level for exponential backoff.  So I would really argue to keep the 
SHOULD in the second paragraph.

Alternatively, we might consider something like 5 seconds without an 
exponential backoff implementation OR an initial 1 second cache time with an 
exponential backoff.

DW


 
> On Jul 23, 2023, at 9:00 PM, Tim Wicinski  wrote:
> 
> 
> 
> All,
> 
> We had a discussion this morning during the hackathon about a value with 
> the document caching-resolution-failures.  The current text in 3.2 says:
> 
> Resolvers MUST cache resolution failures for at least 5 seconds.  The
> value of 5 seconds is chosen as a reasonable amount of time that an
> end user could be expected to wait.
> 
> Resolvers SHOULD employ an exponential backoff algorithm to increase
> the amount of time for subsequent resolution failures.  For example,
> the initial time for negatively caching a resolution failure is set
> to 5 seconds.  The time is doubled after each retry that results in
> another resolution failure.  Consistent with [RFC2308], resolution
> failures MUST NOT be cached for longer than 5 minutes.
> 
> 
> There was some operational feedback that suggests 1 second is also 
> a very reasonable value here.  With some discussion, here is some 
> suggested text:
> 
> Resolvers MUST cache resolution failures for at least 1 second.
> The initial duration SHOULD be configurable by the operator.  A
> longer cache duration for resolution failures will reduce the
> processing burden from repeated queries, but will also lengthen
> the recovery period from transitory issues.
> 
> Resolvers MAY* employ an exponential backoff algorithm to increase
> the cache duration when resolution failures are persistent.  For
> example, the initial time for negatively caching a resolution
> failure could be set to 5 seconds, and doubled after each retry
> that results in another resolution failure, up to a configurable
> maximum.
> 
> Consistent with [RFC2308], resolution failures MUST NOT be cached
> for longer than 5 minutes.
> ---
> 
> * Note that the original text has this as SHOULD. I've heard reasons for both 
> SHOULD and MAY. 
> 
> We'd like to hear from the working group on this value, and what the working 
> group thinks of this change
> 
> thanks
> tim
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/1EOBeLhMBEWg1uxqfTYxtUCMTcEb3F3FEA2EO7c3JOioTtVNfCLJH16XnnbuotVr49ldBsx_KxI4Vx5CjDqNuYdQ17vtalwP-jShq2peErxec4rVO5LJ33FG2rYySJ-hZugq-0SR7DVGxYLZEl-uJBfoRv8Zktrm5CSMGpC4jjfksy9itIXwMXbnVKRQ8qOV2E-xDb5PqUtQMLBambGxjnlXoTHtQl2dqFRx1kA7Tyg6-9vnpU5kAoRVbl_5ghCwqXM4Go0HV4s-Z-P0vPvWnuXP40ATm_rhOsymJUvwkppy58V9UrsCxC81vA7ic1gIe/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop

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

Re: [DNSOP] Working Group Last Call for Negative Caching of DNS Resolution Failures

[Wessels, Duane]

> On Jun 30, 2023, at 2:32 PM, Joe Abley  wrote:
> 
> 
> 
> I have read -04. i like it. I think it's useful and sensible and it should be 
> published. Whether this particular rev is ready for publication I would say 
> depends on whether the authors disagree with all the pedantic nonsense that 
> follows. They should feel free not to agree.

Thanks Joe, some responses inline.

> 
> There are some nits that the authors might want to address or prepare to be 
> outraged at the suggestion of.
> 
> The last paragraph in section 1.3 defines terms that are not used in this 
> document except in that paragraph, I think? Perhaps they are vestigial.

Good catch, we’ve removed the reference to Private Use, Reserved, etc.


> 
> In section 2.1 the phrase "Authoritative servers, and more specifically 
> secondary servers, return server failure responses when they don't have any 
> valid date for a zone." I don't think secondary servers are special from the 
> perspective of a client sending a query; such clients cannot usually 
> distinguish between primary and secondary servers and there are a wealth of 
> well-used authoritative servers deployed that don't use zone transfers 
> anyway. I suggest removing the qualifying "and more specifically secondary 
> servers".

We’re inclined to agree and have removed the phrase as you suggest.

> 
> In section 2.1 the phrase "server failure responses" is used in place of 
> SERVFAIL. In section 2.2 return codes are referred to as RCODEs and REFUSED 
> is used in place of "refused return codes" or something. I don't think it 
> matters too much which is used, but it seems like the document should be 
> consistent. I like the all-caps representations, personally, but if you go 
> with that there's an argument that they should be defined, e.g. by means of a 
> reference to whatever the latest dns-terminology draft is in section 1.3.

We’ve made changes to be more consistent when talking about SERVFAIL, REFUSED, 
and FORMERR responses, using the short all-caps names as you suggest.

> 
> I wonder whether another subsection of section 2 would be useful to discuss 
> transactions that don't time out, but whose transports return positive 
> indications of failure, e.g. a TCP handshake failure or RST, or a TLS 
> negotiation failure when using DoT or DoH. These are not

> timeouts, but they also lack RCODEs (since they lack responses). Is it worth 
> suggesting that failures that are transport-specific be cached, e.g. to 
> record that server 192.0.2.1 doesn't respond on TCP so don't bother 
> bombarding it with SYNs? You talk about this in 3.1; perhaps a forward 
> reference from section 2 would be helpful.

Based on your points here, we suggest this update to section 2.3:

2.3.  Timeouts and Unreachable Servers

   A timeout occurs when a resolver fails to receive any response from a
   server within a reasonable amount of time.  Additionally, a transport
   layer protocol may more quickly indicate lack of reachability in a
   way that wouldn't be considered a timeout.  For example: an ICMP port
   unreachable message, a TCP "connection refused" error, or a TLS
   handshake failure.  [RFC2308] refers to these conditions collectively
   as "dead / unreachable servers."

   Note that resolver implementations may have two types of timeouts: a
   smaller timeout which might trigger a query retry and a larger
   timeout after which the server is considered unresponsive.
   Section 3.1 discusses the requirements for resolvers when retrying
   queries.

> 
> Section 2 talks at some length about RCODEs like SERVFAIL and REFUSED but is 
> silent on the existence of the extended error option. This may be ok, e.g. 
> since the EDE spec is quick to specify that it "does not change the 
> processing of RCODEs" and since the purpose of your draft is presumably to 
> deal with retry behaviour regardless of whether EDE is supported, but it 
> feels odd not to mention it at all even if it's just to clarify why it's ok 
> for this specification to deal just with RCODEs.

We’ve added this:

   Although the extended DNS errors method exists "primarily to extend
   SERVFAIL to provide additional information," it "does not change the
   processing of RCODEs" [RFC8914].  This document operates at the level
   of resolution failure and does not concern particular causes.

> 
> Section 3.1 uses the phrase "a server's transport". I stared at that for 
> quite a bit and I'm not sure I know for sure what it means. I think you're 
> talking about the number of successive transmission of the same query using 
> the same transport that are sent to the same server address. Perhaps that's 
> obvious to other people (or perhaps my interpretation illustrates that there 
> is some ambiguity).

That is the intention.  Is this more verbose text better?

   A resolver MUST NOT retry a given query to a server address over a
   given transport protocol more than twice (i.e., three queries in
   total) before considering 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-04.txt

[Wessels, Duane]

This revision includes some changes in response to Peter van Dijk's DNS 
directorate review, as well as addressing the left over "for discussion" 
topics.  Although our conversation with Peter may still be ongoing, we wanted 
to get this version out so that other people can review the document as a whole 
in the meantime.

DW


On 6/30/23, 1:31 PM, "DNSOP on behalf of internet-dra...@ietf.org 
" mailto:dnsop-boun...@ietf.org> on behalf of internet-dra...@ietf.org 
> wrote:


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


Title : Negative Caching of DNS Resolution Failures
Authors : Duane Wessels
William Carroll
Matthew Thomas
Filename : draft-ietf-dnsop-caching-resolution-failures-04.txt
Pages : 16
Date : 2023-06-30


Abstract:
In the DNS, resolvers employ caching to reduce both latency for end
users and load on authoritative name servers. The process of
resolution may result in one of three types of responses: (1) a
response containing the requested data; (2) a response indicating the
requested data does not exist; or (3) a non-response due to a
resolution failure in which the resolver does not receive any useful
information regarding the data's existence. This document concerns
itself only with the third type.


RFC 2308 specifies requirements for DNS negative caching. There,
caching of type (1) and (2) responses is mandatory and caching of
type (3) responses is optional. This document updates RFC 2308 to
require negative caching for DNS resolution failures.


The IETF datatracker status page for this Internet-Draft is:
https://secure-web.cisco.com/1OwCImNw2PA9Wo17Q8aEqLytC1RP0oGi5WKJ41cpxQEKEw9VZiJHDBhotEYwUHPYl3ivi2kLtVCc7kPZpcO15J3V5-aTcxuQiCjyw_pxY7V0tA9UZ9RFG5hVrhtDubS_b_Bv5a2aNz6f-4ifEzDyN2OuXvANkhxT1O-lKZ0zb01GgYSta2d6mqCbdbPwVk_jQKdnbbNnJlOczz96StIidL6s4mHuk3X0daekc4QilkS8TuPwqmvlPH0HmhFBQ4dZHZBWccKjFwIk_nWSYcG5RbAz6DgwD8O950v_xL33wFBQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-caching-resolution-failures%2F
 



There is also an htmlized version available at:
https://secure-web.cisco.com/1DpyEyJ5UqQFPgxeVLmSp_8DqEXGgk5Px9g_3lIEl--fuiQgSF6ch9RJy6voDPXIGgu5OCVaQwFKn5QZiTh_iW4enizK-nvIqJiSyT07kziDZyptRX54oBrJDpxL0r_jcpnHn26BhMu0g9hAc_OKykYY0ZC68WrJ6CRnvo-CVHUDesdXWMC7IpjjgPCGZ2BhPHCL7osOXd5JNZa9yL2iWAs3JpybcRPibEB_2HXjkP9rwj2RbRHMey0MpYZ7_bLZeRMOFTuarXvvlKKpxEbHQ4caGkrH8oIarGDjDuzNQrH0/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dnsop-caching-resolution-failures-04
 



A diff from the previous version is available at:
https://secure-web.cisco.com/1bn_iNzpDhB2yHSrxPja5HjIbPI2Q4Bx67XzycqYhmNca_Xh3xzm_O_QgEcCQRgNNKLBT1jjuLk2_lpMH5tzoD8b5Fa_QzA7yspSzRtUEI6XcOOqtzvuypRbsHyXJnFJys5d6RTC1boPX0r6yRRm0U2-3qOaiza1kXVf0AK3Aco0liOnqS_VyTbq6Y0QDhJT9cI4tKHokH38M9hlx_ZlAlYZ1V7eCnV-YOPcVMqSs_XBvBVeQN1NRPrtYu6WyrsG4xzxya5ZpGQNChlDwTKLpHoZXNRO-KAg4Eo6W6nbCTtY/https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-dnsop-caching-resolution-failures-04
 



Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts




___
DNSOP mailing list
DNSOP@ietf.org 
https://secure-web.cisco.com/10Davxpn2GVxfE0qHaASfSIn5r6yAI_Hb6JiPqMhZ1oEuXN7L-4OymURDpVqHQLCSSJI5bnBGrhR5_fnzzkyP9LiJToGfSvqvEzCCM83VaCZdDcwa9ctBVg7dZQtRJVxDy9t3Eotezt_gua4AKVd1KtF-WAbHqRK9VUyKSnl7XaeAKPnMTfp8Ad-FcffBbdqN0sNf6E9_jnQxf0xIeHtDzWTKuBe7jwNDb0aakGuUgi8StmEZ0sPrues_Fy_PL2cbf2XiUIS2OuMnWBr-zpRqjhTVKdhZpGut5IspWRDXBTI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop

Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-03

[Wessels, Duane]

Hi Peter,

Thank you for the detailed review.  Responses from the authors are inline below.



> On Jun 26, 2023, at 7:47 AM, Peter van Dijk via Datatracker 
>  wrote:
> 
> Reviewer: Peter van Dijk
> Review result: Almost Ready
> 
> I have been selected as the DNS Directorate reviewer for this draft. The
> DNS Directorate seeks to review all DNS or DNS-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the ADs.
> For more information about the DNS Directorate, please see
> https://secure-web.cisco.com/1C33i4Dh-oRD64xG7a2vNsTYqSkPmK_TtaZK5jIi1iKC1wcUTEdFfOLVw2n8nSUfJfqkbodz3_NdwV50FyoYhfQgSizKNv3M_ep9Yx9lkNt6oLgHQ4Vzp63kYnLezQGHdj0sornqx_SXzMbvj1BAzh7zPtyqF42myyeJXxiCyrr6e3QAdSUEYSAtaWewUcT8nEODhdq9BzBue8j3jhmGSCvOkEqY7Y8Tgfwi52mCcXFC6XNOjWYytI5iJuWrXd6WvjALuITYr8tv11C5mJVNaMj6-jLCgBzJbwJt0tkCxrL4MjxM4GuoUUvZ29P9i3K07/https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Fdnsdir
> 
> This document is generally in good shape. It is not too prescriptive, leaving
> room to implementers to honour the requirements in a way that makes sense for
> their implementations. The document has not seen a lot of WG discussion; I 
> hope
> this means people have read it and generally agree.
> 
> Section 3.3 contains a "FOR DISCUSSION" note. I believe this means the 
> document
> cannot currently pass Last Call. (See below for some notes on that discussion
> item.)
> 
> I have various nits and suggestions. Please see them below. Section numbers 
> are
> for -03.
> 
> ## 2
> 
> I know section 2 is not meant to be exhaustive, but I wonder if FORMERR
> deserves a mention. In theory, a FORMERR response will not improve with time
> until an auth operator actively intervenes (by updating/replacing software to 
> a
> more compliant version). SERVFAILs, by comparison, can be much more transient.

Good suggestion, we’ve added a short section on FORMERR.

> 
> ## 2.1
> 
> current:
> 
>> Authoritative servers, and more specifically secondary servers,
>> return server failure responses when they don't have any valid data
>> for a zone.  That is, a secondary server has been configured to serve
>> a particular zone, but is unable to retrieve or refresh the zone data
>> from the primary server.
> 
> proposed:
> 
>> Authoritative servers, and more specifically secondary servers,
>> return server failure responses when they don't have any valid data
>> for a query.  For example, a secondary server has been configured to serve
>> a particular zone, but is unable to retrieve or refresh the zone data
>> from the primary server.

Yes, thanks.

> 
> ## 2.2
> 
> The first paragraph correctly mentions "policy reasons". The second paragraph
> correctly says "they are not authoritative". I am not sure not being
> authoritative can be considered a policy reason, so perhaps these two
> paragraphs can be connected with an "or"?

I see your point.  We propose this change to the introduction sentence:

A name server returns a message with the RCODE field set to REFUSED
when it refuses to process the query, e.g., for policy or other reasons.


> 
> ## 2.3
> 
> "If, however, the implementation does not join outstanding queries together,
> ..." - this could use a reference to 5452 4.3 and 5452 5, pointing out that
> implementations really should be joining queries together for security reasons
> whenever they can, beside the reason given in the draft of not overloading
> authoritatives.

Added.

> 
> ## 3.1
> 
> "A resolver MUST NOT retry a given query over a server's transport  more than
> twice" - should this be clarified to say "in a short period of time" or
> something like that? Clearly a retry is allowed *eventually*.

For reference, here’s the sentence in question at the start of 3.1:

   A resolver MUST NOT retry a given query over a server's transport more
   than twice (i.e., three queries in total) before considering the
   server's transport unresponsive for that query.

We feel that “a given query” and “for that query” in the sentence sufficiently 
limits the
scope here, and there is no need to qualify it by some amount of time.

As an example, let’s say that a recursive has been asked to lookup 
www.example.com (our “given” query).  The example.com zone has two name 
servers, each of which has two IP addresses, and (presumably) two transports.  
It can send 3 queries to 199.43.135.53 over UDP (then that transport is 
unresponsive), 3 queries to 199.43.133.53 over UDP, same over TCP, over IPv6, 
and so on.  In total the recursive can send 2x2x2x3 = 24 queries before it has 
to give up if all servers and all transports are unresponsive. At this point 
the resolver gives up on that query and returns SERVFAIL.

Then, section 3.2 is about caching and says that the resolution failure MUST be 
cached for at least 5 seconds, but otherwise gives implementations a lot of 
freedom in how to do that.  Could be by query tuple, by server/transport, or 
some 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-09.txt

[Wessels, Duane]

Thanks to all the IESG reviewers for their feedback.  We've made the following 
updates in revision -09:

- No more uppercase RFC2119 keywords in the abstract
- Added a reference to the DNS terminology RFC
- Added a reference to the dig command

At this point the authors believe the IESG feedback has been sufficiently 
addressed.

DW


> On Jun 14, 2023, at 7:48 AM, internet-dra...@ietf.org wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Domain Name System
> Operations (DNSOP) WG of the IETF.
> 
>   Title   : DNS Glue Requirements in Referral Responses
>   Authors : M. Andrews
> Shumon Huque
> Paul Wouters
> Duane Wessels
>   Filename: draft-ietf-dnsop-glue-is-not-optional-09.txt
>   Pages   : 12
>   Date: 2023-06-14
> 
> Abstract:
>   The DNS uses glue records to allow iterative clients to find the
>   addresses of name servers that are contained within a delegated zone.
>   Authoritative Servers are expected to return all available glue
>   records for in-domain name servers in a referral response.  If
>   message size constraints prevent the inclusion of all glue records
>   for in-domain name servers, the server must set the TC flag to inform
>   the client that the response is incomplete, and that the client
>   should use another transport to retrieve the full response.  This
>   document updates RFC 1034 to clarify correct server behavior.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-glue-is-not-optional-09.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-glue-is-not-optional-09
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

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

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

[Wessels, Duane]

My preferred definition is the one originally given by Paul Vixie, amended by 
myself, and further amended by Peter Thomassen:

A lame delegation is said to exist when one or more authoritative
servers designated by the delegating NS rrset or by the child's apex NS
rrset answers non-authoritatively for a zone.

I don’t think it is perfect, but it is an improvement.  I don’t think 
perfection will be achievable.  

IMO “[or not at all]” does not belong in the definition.  I don’t think we 
should allow timeouts to be confused for or considered as lame delegation.

If something like the above definition is adopted then the document can note 
there is some historical lack of agreement or consistency in use of the term.

DW
 


> On May 1, 2023, at 9:09 AM, Paul Hoffman  wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> It would be grand if a bunch more people would speak up on this thread.
> 
> --Paul Hoffman, wearing my co-author hat
> 
> On Apr 27, 2023, at 1:05 PM, Benno Overeinder  wrote:
>> 
>> Dear WG,
>> 
>> The WGLC was closed for draft-ietf-dnsop-rfc8499bis, and the discussion
>> on lame delegation did not find consensus, but two specific suggestions
>> were put forward.  We would like to include one of them in rfc8499bis if
>> we can get consensus to do so.
>> 
>> The chairs are seeking input on the following two suggestions:
>> 
>> * Either we leave the definition of “lame delegation” as it is with the
>> comment that no consensus could be found, or
>> 
>> * alternatively, we include a shorter definition without specific
>> examples.
>> 
>> 1) Leaving the definition of lame delegation as in the current
>>  draft-ietf-dnsop-rfc8499bis, and including the addition by the
>>  authors that:
>> 
>>  "These early definitions do not match current use of the term "lame
>>  delegation", but there is also no consensus on what a lame delegation
>>  is."  (Maybe change to ... no consensus what *exactly* a lame
>>  delegation is.)
>> 
>> 2) Update the definition as proposed by Duane and with the agreement of
>>  some others (see mailing list 
>> https://secure-web.cisco.com/1X5AMTQJt2cXj7u31WPDppT_N_lSyi56z_C_stVVEipVVZkqvDApuQPa0iKxw5z8KkYh6lUYaa8WwEbu1lbUw_3U3-oCZDRWfYload0wQnMB3d76sNuzWFVBh7JB6a-2AOK0wOchJz8ErMhve7dpEUAX3u3v-rv-1jqen-3Ar6uMAJe4pFpHNVMWX8RyUI7uPYRUghgCekgBWibFm6LiPtCBLmTeUAdGkHdbCvCQ-SgAe56iNE4EwIGnrBWJTVJZlM-Dv3FrK04mE2gMsQs6HDzz40kt4871oRIkuNMadfKo/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdnsop%2F4E1AQKGivEHtJDB85gSNhofRuyM%2F):
>> 
>>  "A lame delegation is said to exist when one or more authoritative
>>  servers designated by the delegating NS RRset or by the child's apex
>>  NS RRset answers non-authoritatively [or not at all] for a zone".
>> 
>> The chairs ask the WG to discuss these two alternative definitions of
>> the term "lame delegation".  We close the consultation period on
>> Thursday 4 May.
>> 
>> Regards,
>> 
>> Benno
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/1XVxOCcNMkTcMeadUBQk9SlINRiQvUqtUMpxSKIOYBnT1ERKTnDtcFN1UjyDbfzk5FQqhfy31BXnCbOKFunIXd_OgZghAR9dJnnqlAmKIktWHve95FPY6YA3UinPiPabOUAEi7sOIwtzoF6rScnH_ml4EN5VeCkDj_DbUdU1FINNiKRFrKNlopElAMuHQoV1jehl-oCQtlNNopUy_X-mm_fPAbRNsYgc4S411S5vVePb4M-3xft1EktHXfsQNSe-y_vNR947juf5DmA2OYgq3gw0Efu3o0GxuyisOZ23nNj0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop

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

Re: [DNSOP] [Ext] Meaning of lame delegation

[Wessels, Duane]

I think Paul’s definition is good and matches the way I think of a lame 
delegation. 

My one quibble would be with the ending part that says “that zone is said to 
have…” This is somewhat confusing because the definition combines both a 
parent-child delegation and an apex/self delegation.  If we’re talking about a 
name server in the delegation from com to example.com, I’m not sure it is 
correct to say that the example.com zone has the lame delegation.

Perhaps:

“A lame delegation is said to exist when one or more authoritative servers 
designated by the delegating NS rrset or by the apex NS rrset answers 
non-authoritatively for a zone”.

DW


> On Apr 9, 2023, at 12:31 AM, paul=40redbarn@dmarc.ietf.org wrote:
> 
> 
> "If one or more authoritative servers designated by the delegating NS rrset 
> or by the apex NS rrset answers non-authoritatively for a zone, that zone is 
> said to have a lame delegation."
> 
> p vixie
> 
> On Apr 9, 2023 04:13, Paul Hoffman  wrote:
> I have been on vacation this week and am just seeing this thread now. Now 
> that a bunch of people have spoken up on the topic, if someone wants to 
> propose a *specific* change to the definition in draft-ietf-dnsop-rfc8499bis, 
> this would be a very good time to do it, given that we are after WG Last Call 
> but waiting for AD writeup. Otherwise, the current wording will be used for 
> IETF Last Call. 
> 
> --Paul Hoffman 
> 

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

Re: [DNSOP] Meaning of lame delegation

[Wessels, Duane]

Thank you everyone for your feedback on the meaning of lame delegation.  I 
expected some different interpretations, although maybe not this many!  I will 
take this feedback to the SSAC work party for discussion there about whether or 
not to use the term in the report (perhaps with a disclaimer).

DW


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

[DNSOP] Meaning of lame delegation

[Wessels, Duane]

Dear DNSOP,

I am participating in an SSAC work party where we are writing about DNS 
delegations where a delegated name server might be available for registration, 
allowing an attacker to participate in the resolution for the domain.  During 
report drafting we considered using the term "lame delegation" to describe this 
and a broader class of delegation problems.

Naturally, we turned to RFC 8499, DNS Terminology, but found the entry not 
particularly helpful since it simply quotes previous, imprecise uses of the 
term:

   Lame delegation:  "A lame delegations exists [sic] when a nameserver
  is delegated responsibility for providing nameservice for a zone
  (via NS records) but is not performing nameservice for that zone
  (usually because it is not set up as a primary or secondary for
  the zone)."  (Quoted from [RFC1912], Section 2.8) Another
  definition is that a lame delegation "...happens when a name
  server is listed in the NS records for some domain and in fact it
  is not a server for that domain.  Queries are thus sent to the
  wrong servers, who don't know nothing [sic] (at least not as
  expected) about the queried domain.  Furthermore, sometimes these
  hosts (if they exist!) don't even run name servers."  (Quoted from
  [RFC1713], Section 2.3)

The first appears to assume that the name server exists, while the latter 
parenthetically notes the name server might not exist, but without any specific 
meaning of existence.  We are wondering if the idea of a lame delegation should 
be interpreted broadly, or more narrowly to include only cases where a response 
is proof of lameness.  Consider a delegation of the domain EXAMPLE.NET to name 
server NS.EXAMPLE.ORG.  There are three possible situations in which this might 
be considered a lame delegation:

(1) NS.EXAMPLE.ORG resolves to an IP address.  Queries to the IP address result 
in a REFUSED, SERVFAIL, upward referral, or some other indication the name 
server is not configured to serve the zone.

(2) NS.EXAMPLE.ORG resolves to an IP address.  Queries to the IP address do not 
elicit a response (e.g., timeout).

(3) NS.EXAMPLE.ORG does not resolve to an IP address, so there is nowhere to 
send a query.

We welcome the working group's thoughts whether "lame delegation" encompasses 
these three possibilities.

DW


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

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Wessels, Duane]

> On Mar 29, 2023, at 10:53 AM, Shumon Huque  wrote:
> 
> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  wrote:
> 
> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
> 
> 
> On 3/28/23 03:14, Shumon Huque wrote:
> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni  > > wrote:
> > 
> > On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> > Can we at least state that domains with cyclic dependencies are a bad
> > idea, and may not be supported by all resolvers.  In other words, that
> > the domain owner can't **rely** on the sibling glue recommended to be
> > sent in this draft to save the day.
> > 
> > My strong preference is still to delete all reference in the draft to
> > cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
> > sibling glue primarily as a performance optimisation, and secondarily
> > as a last resort when the nameserver IP addresses are wrong or gone
> > from the authoritative zone (another bad practice).
> > 
> > 
> > Viktor - I've so far not seen many other people speak up in support of your
> > position. I suspect this is because this draft was discussed to death many
> > months ago during long discussion threads on the list, and there is likely
> > already rough consensus for the current content. Personally, I would be ok
> > with adding a statement that configurations involving cyclic dependencies
> > are not recommended, but others will likely have to also speak up in support
> > of this too.
> 
> I support adding such a statement about cyclic dependencies.
> 
> As do I. 
>  
> 
> In addition, I would support saying that data suggests that, while 
> (non-cyclic) glue records may have a benefit in certain cases, they 
> frequently are a source of harm (time-outs), and the trade-off remains 
> unclear.
> 
> I would support this as well.
> 
> In my anecdotal experience as an operator, I routinely encounter mismatches 
> in sibling glue and child zone NS sets that appear to be due to the glue 
> being forgotten.  My assumption is that, because it's not necessary to 
> operate, when operators fail to update it they don't receive any kind of 
> signal that something is wrong.
> 
> Viktor's numbers are pretty clear data, though, so nobody should need my 
> anecdotes to be convinced.  While sibling glue may be a useful optimisation 
> in some cases, given how poorly maintained it is it seems to cause more 
> problems than it solves.
> 
> 
> I'd like to remind folks that the scope of this draft when it was adopted by 
> the working group was very narrow. Mainly to say that 'required' glue must 
> set TC=1 if it doesn't fit into the DNS response payload. That required 
> talking about other types of non-mandatory glue like sibling, but has not 
> proposed to change authoritative server behavior in those areas.
> 
> If folks want to deprecate sibling glue entirely, it would be best to write 
> another draft saying that and see if we can get consensus on that.
> 

I agree with this position.  The scope of the draft is about message size and 
behavior when glue records don’t fit.  Although the “glue is not optional” name 
is catchy, in hindsight I think a different name would better reflect the 
intent of the document.

DW


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-21.txt

[Wessels, Duane]

Thank you authors for the update which addressed my concern about formatting of 
the special use considerations as an enumerated list.

Forgive me if I am being difficult, but I feel that the first sentence of the 
privacy section, which says “... so should not attempt to be resolved using the 
global DNS” is in contradiction with #4 which says "and SHOULD NOT perform any 
special handling”, and to some extent #3 which says "Regular DNS resolution 
APIs and libraries are not expected to recognize or treat names in the .alt 
pseudo-TLD differently”.

Given the wording of the considerations in section 3.2, maybe just delete “, 
and so...” from that sentence in the privacy section?

DW



> On Feb 24, 2023, at 10:42 AM, internet-dra...@ietf.org wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This Internet-Draft is a work item of the Domain Name System Operations WG of 
> the IETF.
> 
>Title   : The ALT Special Use Top Level Domain
>Authors : Warren Kumari
>  Paul Hoffman
>  Filename: draft-ietf-dnsop-alt-tld-21.txt
>  Pages   : 12
>  Date: 2023-02-24
> 
> Abstract:
>   This document reserves a TLD label, "alt" to be used in non-DNS
>   contexts.  It also provides advice and guidance to developers
>   developing alternative namespaces.
> 
>   

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

[Wessels, Duane]

I will reiterate some of my concerns with the draft:

I find the format of section 3.2 to be very strange.  As a paragraph it jumbles 
some items together.  It should be a list format like the ones in RFCs 6761 and 
7686.

Section 3.2 does not say how applications that do not use .alt should behave.

Section 3.2 does not say how APIs and libraries should behave (only that 
.alt-aware applications will probably use specialized APIs and libraries).

Section 3.2 uses “will” several times instead of BCP 14 requirements keywords.

I still think the requirements for library (stub) and caching resolver behavior 
should be stronger.  i.e. MUST NOT put .alt queries on the wire.  But this is 
probably a minority opinion.

“Caching Resolvers performing aggressive use of DNSSEC-validated caches ... 
will not send any queries for names under .alt to the root zone.”  This 
statement is too strong.  RFC 8198 says SHOULD, not MUST. Not to mention cache 
misses.

DW


From: DNSOP  on behalf of Suzanne Woolf 
Date: Tuesday, December 13, 2022 at 12:26 PM
To: "dnsop@ietf.org" 
Cc: "dnsop-cha...@ietf.org" , "Rob Wilton (rwilton)" 

Subject: [EXTERNAL] [DNSOP] WGLC for draft-ietf-dnsop-alt-tld


Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


Dear colleagues,


This message will serve to start a Working Group Last Call on “The ALT Special 
Use Top Level Domain” 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/).
 Due to the end-of-year holidays, we’re starting it now and will give it four 
weeks.


As you’ve seen from Paul Hoffman’s email, the authors have updated to version 
19 based on the feedback they heard at IETF 115. Thanks Paul and Warren!


The WG is very familiar with this document by now, and the WGLC is to determine 
whether the document has rough consensus to progress. The chairs need to know 
whether you support it (which, for this purpose, includes “I can live with 
it”), or actively oppose publishing it.


Please also assume that any necessary liaison communications with ICANN will be 
undertaken if this document has WG consensus to move forward. Managing the 
potential for misunderstanding or differences of opinion among relevant 
organizations is the primary reason why the IETF has liaison relationships. The 
IETF liaison to the ICANN Board is Harald Alvestrand, who has been monitoring 
the conversations about alt-tld on the mailing list and has discussed the draft 
with the chairs and with Rob Wilton as the responsible AD.


Start date: 13 December 2022

End date:  10 January 2023


Many thanks,

Suzanne, Tim, and Benno



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

Re: [DNSOP] .alt filtering in recursive servers

[Wessels, Duane]

I find the latest alt-tld draft to be inconsistent when it first
says “[alt names] should not be looked up in a DNS context” and
"DNS stub and recursive resolvers do not need to look them up in
the DNS context” but then later "Caching DNS servers will treat
[alt names] just as they would any other name whose TLD does not
appear in the global DNS root.”  Since caching servers lookup names
with non existent TLDs in the DNS, then of course alt names will
also be looked up in the DNS context.

I'm also struck how radically different the special use considerations
for .onion (RFC 7868) and .alt are.  onion has multiple MUST-level
requirements for not leaking queries into the global DNS.

IMO we should write requirements to describe the behavior we want.
Even though we know from experience that not all implementations
will adhere to the requirements it is appropriate to say that alt names
MUST NOT or (at least SHOULD NOT) not leak.

And even if we don't end up with strong anti-leaking requirements,
then we should at least openly acknowledge that leaked queries
will happen (i.e., to root name servers).

Lastly, I'd like to see the special use considerations for .alt
formatted more like the examples given in that RFC 6761 and the one
in RFC 7686.

I’d like to propose this new/updated text for the alt-tld draft:

==

   1.  Users: Human users might or might not recognize that names
   in the .alt pseudo-TLD are special.

   2.  Application Software: Applications that use alternative
   namespaces in .alt MUST have their own processing
   rules for their own names, probably in specialized resolver
   APIs, libraries, and/or application software.

   3.  Name Resolution APIs and Libraries: Resolvers MUST NOT resolve
   .alt names in a DNS context.  They MAY respond to
   queries for such names with NXDOMAIN.

   4.  Caching DNS Servers: Caching servers MUST [or SHOULD] NOT
   attempt to resolve .alt names in the global DNS root.  They
   MAY respond to queries for such names with NXDOMAIN [or
   REFUSED?].

   5.  Authoritative DNS Servers: Authoritative servers MUST respond to
   queries for .alt names with NXDOMAIN.

   6.  DNS Server Operators: Operators MUST NOT configure an
   authoritative DNS server to answer queries for .alt.

   7.  DNS Registries/Registrars: Registries and Registrars MUST
   NOT register .alt names because .alt will not exist in the
   global DNS root.  All such requests MUST be denied.

Note that despite the requirements given here, it is generally expected
that queries for .alt names will "leak" into the global DNS.  The root
name servers [RFC 7720?] will receive leaked queries and respond with
NXDOMAIN.  Techniques such as qname minimization, aggressive NSEC caching,
and root-on-loopback can reduce the amount of leaked queries received by
root name servers.

==

DW


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-01.txt

[Wessels, Duane]

This draft has been updated based on recent feedback.  The primary change is 
that the new version is less prescriptive about how the resolution failure 
negative cache should work.  e.g., rather than saying "Resolution failures MUST 
be cached against the specific query tuple…” it now says "Resolvers MUST 
implement a cache for resolution failures” but leaves the details to the 
implementation.

We welcome further discussion and input.

DW


> On Sep 12, 2022, at 3:18 PM, internet-dra...@ietf.org wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> 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   : Negative Caching of DNS Resolution Failures
>Authors : Duane Wessels
>  William Carroll
>  Matthew Thomas
>  Filename: draft-ietf-dnsop-caching-resolution-failures-01.txt
>  Pages   : 14
>  Date: 2022-09-12
> 
> Abstract:
>   In the DNS, resolvers employ caching to reduce both latency for end
>   users and load on authoritative name servers.  The process of
>   resolution may result in one of three types of responses: (1) a
>   response containing the requested data; (2) a response indicating the
>   requested data does not exist; or (3) a non-response due to a
>   resolution failure in which the resolver does not receive any useful
>   information regarding the data's existence.  This document concerns
>   itself only with the third type.
> 
>   RFC 2308 specifies requirements for DNS negative caching.  There,
>   caching of type (1) and (2) responses is mandatory and caching of
>   type (3) responses is optional.  This document updates RFC 2308 to
>   require negative caching for DNS resolution failures.
> 
> 
> The IETF datatracker status page for this draft is:
> https://secure-web.cisco.com/1Tj_cyWFGUKz4YiwF0fnptDrtAqXWa3M5rS8wHsuQCrQptkzDaKaH6AWjPBY_s16axtl7VLXOVEb9P7rzXsDwHI0XVUgdeHs4Ct1cy0BTwTxeEzdzZrg4b5QYSwl-PEJnI06bCFbF7ZW3h_f6SU5_8sabBLoC6dCbfXTMYy3fDB1Wf1XvMuNGSNCCW0OUt01APnljOZTthD1IKenynQ_JrDrP9WsvUZEu9iHS86Zd8xlRfuji57W7aD2ZZtO8lEUdCl9vWYoeCDNO_nCExB2YeQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-caching-resolution-failures%2F
> 
> There is also an htmlized version available at:
> https://secure-web.cisco.com/1WFFL6urpB2je9kE3AoDDEzwQHDjXZY3xOlZQ8KwFKQW2kmo0hq_-YOLhTYSmT8I5fBPbxkc_dtNIB4K9WSJ3DZ38qALxhUO_c_xgylCWK1yQ7LAo9Ew1SiV6GQQMPuAeVTOg3Llp6mR47e8pUh7QAL9WPWrkof5j46o03CsB0ZDUb4I33Y8Syn2e8Qx0KEKtm9_jTiWexL8PwOXWHV00DIYMSVpGMNqHpBpOHnNStnNNY4pEG5AZSX_PFn2gFMF4ngFZcy3KNiKWZwmmoa94EQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dnsop-caching-resolution-failures-01
> 
> A diff from the previous version is available at:
> https://secure-web.cisco.com/1dQmPkTAo638e9_FNBF4C67-9DmW45qKHp2-6yGP_nhj3X_dnrrbWNiovzA_BDmV64gDGpXGQddgbXrsaexx1NdzUiaeIlPNeap-nPa9cRss-1v4BQfvz9lHVqq07zwiWRV80tChWR0Zxwx50m9zjDFAzkOD02jbl7c9qcn0vIPZu9x0ydX9BTsgpEMfHEwG-TLSSFju-0Dn6laYvp02UdR96bEuQnTkfnUWKsQds3JwMigVgi8LwKXkIXdXszT8Mq7Bz42OcQHvsL0uCxfdHRg/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-dnsop-caching-resolution-failures-01
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/1X4Rarmsiq-SsH39XV8rmlSY-wlnMHFd1fOwVU5jcXa6xvDmH2MmdE98OFVMnL2joeah-AhvVvD_wpcjnY5tqBkoJar30JHIpdxfNHJHBT03ZELDpSnG8n6PCkacoLgsweCFBCswxLVE_AH-B0WlhKnf8_kpryc75wefklVPqYx-wXLq8qR4P9Zs1xMqhm5T03sAQzHHytcaDWQmwjxHocjR0Mqb1zrSURbXAsCEw34oEjiz_gowwgo4JpWZePQcnfMjCkuDnhyFTxdh8guTWXg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop
> 

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-00.txt

[Wessels, Duane]

Hi Petr, thank you for the feedback!


> On Jul 28, 2022, at 5:06 AM, Petr Špaček  wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> On 27. 07. 22 19:42, internet-dra...@ietf.org wrote:
>> 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   : Negative Caching of DNS Resolution Failures
>>Authors : Duane Wessels
>>  William Carroll
>>  Matthew Thomas
>>  Filename: draft-ietf-dnsop-caching-resolution-failures-00.txt
> 
> I think this is an important clarification to the protocol and we should 
> adopt it and work on it.
> 
> I like the document up until end of section 2.
> 
> After that I have reservations about the specific proposals put forth in the 
> section 3.
> 
> I hope this will kick off discussion, please don't take points personally. 
> I'm questioning the technical aspects.
> 
>> 3.  DNS Negative Caching Requirements
>> 3.1.  Retries and Timeouts
>>  A resolver MUST NOT retry more than twice (i.e., three queries in
>>  total) before considering a server unresponsive.
>>  This document does not place any requirements on timeout values,
>>  which may be implementation- or configuration-dependent.  It is
>>  generally expected that typical timeout values range from 3 to 30
>>  seconds.
> 
> I'm curious about reasoning about this.
> 
> My motivation:
> Random drop or temporarily saturated/malfunctioning link should not cause 
> resolver to fail for several seconds.

This section can certainly be improved and we are open to specific suggestions. 
 For example, I think we could say “MUST NOT retry a given query more than 
twice…” i.e., tie this to the concept of scope in section 3.3. 

> As an extreme case, think of validating resolver on a laptop forwarding 
> elsewhere. Should really two packet drops cause it to servfail for several 
> seconds?

It was not our intention to say that three timeouts marks a forwarder as 
unusable for a long period of time.  Maybe there are different rules for 
forwarders vs authoritative servers.  Or maybe scoping it to individual queries 
would be sufficient.


> 
> Related to this, I have a principal objection:
> IMHO we should NOT be inventing flow control from scratch ourselves. On the 
> contrary - we should be borrowing prior art from existing flow control 
> algorithms and adapt them if necessary.

Sure, I think we’re open to that if there is something appropriate we can 
reference.  Can you think of any relevant prior art?


> 
> 
>> 3.2.  TTLs
>>  Resolvers MUST cache resolution failures for at least 5 seconds.
>>  Resolvers SHOULD employ an exponential backoff algorithm to increase
>>  the amount of time for subsequent resolution failures.  For example,
>>  the initial TTL for negatively caching a resolution failure is set to
>>  5 seconds.  The TTL is doubled after each retry that results in
>>  another resolution failure.  Consistent with [RFC2308], resolution
>>  failures MUST NOT be cached for longer than 5 minutes.
> 
> My motivation: Rapid recovery.
> 
> Why 5 seconds? Why not 1? Or why not 0.5 s? ... I would like to see reasoning 
> behind specific numbers.

We put 5 seconds here simply because it feels like a reasonable amount of time 
that a person would be willing to wait for a retry, and as a starting point for 
a discussion (which we are now having — hooray!).  


> 
> IMHO most problems is caused by unlimited retries and as soon as _a_ limit is 
> in place the problem is alleviated,

But the limit needs to be bound by some amount of time, right?  

> and with exponential backoff we should be able to start small. I'm not sure 
> that a specific number should be mandated.

I agree that having exponential backoff would make a small initial TTL 
feasible.  Would you support a MUST requirement for exponential backoff?

> 
> 
>> 3.3.  Scope
>>  Resolution failures MUST be cached against the specific query tuple
>>  .
> 
> Why this tuple was selected? Why not  for, say, 
> timeouts? Or why not  for timeouts?

This was copied from RFC 2308 (section 7.1 and 7.2).  


> What about transport protocol and its parameters? (TCP, UDP, DoT...) etc.

Yes that is an aspect the draft hasn’t considered.   Would you like to see that 
included in the tuple?

> 
> My motivation:
> - Simplify cache management.
> - Imagine an attacker attempting to misuse this new cache. The cache has to 
> be bounded in size. It has to somehow manage overflow etc.
> 
> Generally I think this MUST is too prescriptive. It should allow for less 
> specific caching if an implementation decides it is fit for a given type of  
> failure and configuration, or depending on operational conditions.


This is similar to points raised by Mukund.  How would 

Re: [DNSOP] Call for Adoption: Survey of Domain Verification Techniques using DNS

[Wessels, Duane]

I support the adoption of this draft.

I think there is value in keeping the specific examples (with named companies, 
etc) but agree with John that placing them in an appendix would be better.

DW


> On Jul 12, 2022, at 6:29 AM, Tim Wicinski  wrote:
> 
> 
> 
> This starts a Call for Adoption for Survey of Domain Verification Techniques 
> using DNS
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-sahib-domain-verification-techniques/
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and send any comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 26 July 2022
> 
> Thanks,
> tim wicinski
> For DNSOP co-chairs
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/1j_nbcnzt4ZJGN4caxS93xsfX7iK9I57uV4Ng0wl1Y2FRmYzo6jKzWiUGQABMDr4XLJ2xSYU5KP3JULJn7iS9NTEbpiuUNFV7AJcJDFBVZxHi2s8XJQ8qBOplztk_HhdNOPN7-62ZNRHPb_QZ9FuZ0D_dCVV31gkasuLhhe54cuySQTfMjAljl7nMDPSgmrdizutF1YFQhTLIFtxtGPa04TvmSf9w47cMaEUtoqUD0Yj_-gxlA9b983ZtyzIYo95K/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop

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

Re: [DNSOP] Quick review of draft-dwmtwc-dnsop-caching-resolution-failures-00

[Wessels, Duane]

Hi Mukund,

> On Jul 12, 2022, at 8:24 AM, Mukund Sivaraman  wrote:
> 
> Some comments quickly browsing this draft, as we're handling a quirky
> issue around NS timeouts and it looked relevant.
> 
> Firstly, some resolver implementations do cache upstream NS timeouts in
> various non-standard ways. The resolver I work on has at least 3-4
> different mechanisms within the same codebase. Documentation on how
> timeouts should be handled seems good, so I support this draft.
> 
>> Internet Engineering Task Force   D. Wessels
>> Internet-DraftW. Carroll
>> Intended status: Standards Track   M. Thomas
>> Expires: 17 July 2022   Verisign
>> 13 January 2022
> 
> 
>>  Negative Caching of DNS Resolution Failures
>>   draft-dwmtwc-dnsop-caching-resolution-failures-00
> 
> [snip]
> 
>>   [RFC4697] is a Best Current Practice that documents observed
>>   resolution misbehaviors.  It describes a number of situations that
>>   can lead to excessive queries from recusrive resolvers. including:
> 
> There's a spelling mistake in "recusrive", and the period after
> "resolvers." should be removed.

Thanks, these will be fixed.


> 
> [snip]
> 
>> 3.2.  TTLs
> 
>>   Resolvers MUST cache resolution failures for at least 5 seconds.
>>   Resolvers SHOULD employ an exponential backoff algorithm to increase
>>   the amount of time for subsequent resolution failures.  For example,
>>   the initial negative cache TTL is set to 5 seconds.  The TTL is
> 
> I am guessing the authors meant to write "timeout cache TTL" here
> instead of negative cache TTL. In any case, the phrase "negative cache
> TTL" has a well-understood meaning per RFC 2308, and should not be
> overloaded/reused to indicate timeout cache TTL.

We didn’t really mean “timeout cache TTL” here.  Rather, the intention 
is specify requirements for caching all types of resolution failures.
That means SERVFAIL, REFUSED, timeouts, and the others listed in Section 2.

I think perhaps your point is that RFC 2308 talks about TTLs for negative
*answers* (NXDOMAIN, NODATA) and what we are proposing is different, often
in the absence of an answer.

Would this rewrite alleviate your concern?

   For example,
   the initial TTL for negatively caching a resolution failure is set to
   5 seconds.  The TTL is doubled after each retry that results in
   another resolution failure.  Consistent with [RFC2308], resolution
   failures MUST NOT be cached for longer than 5 minutes.


> 
> [snip]
> 
>> 3.3.  Scope
> 
>>   Resolution failures MUST be cached against the specific query tuple
>>   .
> 
> Have you considered the effect of caching the timeout against just an
> upstream server's IP address? I'm not saying you should, but wondering
> if any of the other tuple fields are relevant to have separate
> more-specific timeout cache entries.
> 
> In other words, is it necessary for there to be a distinction among
> timeouts for:
> 
> (1) example.org., A, IN, 10.0.0.1
> 
> (2) example.org., TYPE65, IN, 10.0.0.1
> 
> (3) example.com., A, IN, 10.0.0.1
> 
> Traditionally, a resolver's upstream RTTs and timeouts are tracked
> against the nameserver IP address. A failure to respond has been
> considered as a property of the NS (implementation) or path to that NS.
> 
> My colleagues are handling an issue where an authoritative nameserver
> does not respond to TYPE65 queries, but responds to queries for common
> query types such as address records. In this case, without mitigating
> with controls, the resolver is a little stumped and keeps attempting to
> contact the upstream NS because it receives some responses from it. The
> queries for which there are no responses eventually end up waiting for
> the maximum timeout limit because the resolver keeps trying to talk to
> it. On a busy resolver, these queries consume resources.
> 
> We could consider the upstream NS as "bad" if it appears to respond to
> some queries but doesn't respond to others with some response. But
> one-off or transient timeouts can occur sometimes due to network packet
> loss.
> 
> In our case, if the resolver were to block this zone's upstream NSs as
> bad, it wouldn't be able to respond to any queries within that zone
> (even address records). It appears to be a popular country-level zone,
> and it's unlikely the upstream operators will fix it to respond to
> TYPE65 queries in the short-term. In such cases, a heavy-handed approach
> may not be practical.

We have not really considered a recommendation to cache against a name
server’s IP address only.  The idea to cache against the 4-tuple comes
from 2308 (sections 7.1 and 7.2).

We feel that improved caching based on the 4-tuple would be a big win.
It sounds like perhaps you are suggesting a more aggressive approach might
encourage authoritative operators to 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-05.txt

[Wessels, Duane]

> On Apr 25, 2022, at 8:56 AM, Hugo Salgado  wrote:
> 
> Thank you very much Duane for the changes. For my part, the paragraph
> on the requirements on data in zones and registries seems perfect.
> 
> I also find the new way of mentioning glues for in-domain/sibling
> domain name servers clearer. However I see that the change was made
> only in chapters 2 and 3, but they remain in the Abstract and
> Introduction. I think it's better to leave them consistent in all
> places.
> 
> Hugo

Hi Hugo,

The lack of changes to the abstract and introduction was an oversight.  Thank 
you for pointing that out.  I’ve updated the document for its next revision.

DW

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-05.txt

[Wessels, Duane]

There are three noteworthy changes from the previous version of this draft:

1. We no longer use the term “referral glue”.

2. Instead of introducing new (and likely confusing) terms such as “sibling 
glue” and “in-domain glue” we now refer to these as “glue for sibling domain 
name servers” and “glue for in-domain name servers”.

3. Expanded the introduction paragraph that talks about not placing 
requirements on data in zones or registries (as suggested by Ralf).

DW


> On Apr 22, 2022, at 1:27 PM, internet-dra...@ietf.org wrote:
> 
> 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   : DNS Glue Requirements in Referral Responses
>Authors : M. Andrews
>  Shumon Huque
>  Paul Wouters
>  Duane Wessels
>   Filename: draft-ietf-dnsop-glue-is-not-optional-05.txt
>   Pages   : 12
>   Date: 2022-04-22
> 
> Abstract:
>   The DNS uses glue records to allow iterative clients to find the
>   addresses of name servers that are contained within a delegated zone.
>   Authoritative Servers are expected to return all available in-domain
>   glue records in a referral response.  If message size constraints
>   prevent the inclusion of all in-domain glue records, the server MUST
>   set the TC flag to inform the client that the response is incomplete,
>   and that the client SHOULD use another transport to retrieve the full
>   response.  This document updates RFC 1034 to clarify correct server
>   behavior.
> 

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-04.txt

[Wessels, Duane]

> On Mar 22, 2022, at 6:02 AM, Ralf Weber  wrote:
> 
> Moin!
> 
> So to follow up on my comment in the working group on registries not having 
> anything to do with it. I understand that this drafts is for authoritative 
> name server implementers, however I think that we should make clear that an 
> authoritative name server not answering correct by this draft might do so 
> because it does not have sufficient data.
> 
> So we currently have in the introduction:
> 
> Note that this document only clarifies requirements of name server
> software implementations.  It does not place any requirements on data
> placed in DNS zones or registries.
> 
> how about adding:
> 
> However missing data might make it impossible for a name server to answer 
> with the correct (referral) glue data.
> 
> And maybe add some encouragement or referral ;-) to work that has to be done 
> elsewhere.


Ralf (and others),

how does this look to you?

In other words, this document only makes requirements on "available
glue records" (i.e., those given in a zone), but does not make
requirements regarding thier presence in a zone.
If some glue records are absent from a given zone, an authoritative
name server may be unable to return a useful referral response for
the corresponding domain. The IETF may want to consider a separate
update to the requirements for including glue in zone data, beyond
those given in [@!RFC1034] and [@!RFC1035].

Also here: 
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-glue-is-not-optional/pull/35

DW

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

Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications

[Wessels, Duane]

Hi Eugène, I read through the draft and have a few suggestions for you to 
consider:

1) The CRS and CRC RDATA fields have a lot in common with TXT records.  On one 
hand you might find some benefits from making these new RR types have the same 
parsing, wire format, and presentation format as TXT records.  But on the other 
hand, that probably limits the ability to perform syntax checking by an 
authoritative name server.  Maybe get some advice from DNS implementors on this 
topic.

2) You should use documentation domains (and addresses).  i.e., example.com 
instead of foo.com.

3) Your example records should appear just like they would in a zone file.  
Maybe something like

   ftp.example.com. IN CRS R=A,21

4) Separation of components with underscore doesn’t seem right to me.  You give 
an example as “ftp.foo.com_21_bar.com”.  This creates an (invalid) second-level 
domain com_21_bar.com, unless I misunderstand?

5) Can you include an example of how the CRS record would be used?

DW





> On Apr 5, 2022, at 3:52 AM, Eugène Adell  wrote:
> 
> Hello,
> 
> I've been working on two new RRTypes described by a Draft, and as
> suggested by our magnificent, incredibly brilliant and handsome AD
> Warren "ACE" Kumari, I am posting here this idea and the material I
> have written so far (the draft itself, and RFC 6895 components).
> 
> Briefly, one RRType (CRC : Client Roaming Control) contains a
> whitelist of networks allowing a company employees to connect to a
> specific application. The second RRType (CRS : Client Roaming Support)
> is on the application side and informs what kind of restrictions are
> applied (by saying if CRC is mandatory, optional or ignored).
> This is not expected to be deployed broadly and everywhere as it is
> designed to secure Business-To-Business applications.
> 
> The material (text XML2RFC draft + RFC 6895 components) written is
> both incorporated below to this email and attached, for practical
> reasons.
> 
> 
> Regards
> E.A.
> 
> 
> 
> 
> 
> Internet Engineering Task Force E. Adell
> Internet-Draft  5 April 2022
> Intended status: Informational
> Expires: 7 October 2022
> 
> 
> Client Roaming Control
> draft-adell-client-roaming-00
> 
> Abstract
> 
>   This document specifies the Client Roaming Control (CRC) DNS Resource
>   Record allowing an organization to better control the access to
>   third-party applications over Internet.  The applications
>   implementing an authorization mechanism to honor the CRC, publish on
>   their side the Client Roaming Support (CRS) Resource Record to inform
>   of this support.
> 
> Status of This Memo
> 
>   This Internet-Draft is submitted in full conformance with the
>   provisions of BCP 78 and BCP 79.
> 
>   Internet-Drafts are working documents of the Internet Engineering
>   Task Force (IETF).  Note that other groups may also distribute
>   working documents as Internet-Drafts.  The list of current Internet-
>   Drafts is at 
> https://secure-web.cisco.com/1UBqNqOD0_avjtr-YY-q-eOgfcaadfGerG9mW2JKKCseQ6aQaNm9QI-n8SuZkYw5t3JNht-Q9J7Rm-gnPlrXziremyFm_V8D8YJFTTFXgbwuIBkM31ZDkVZ0ju3DB6jaSp9Gvl-zasI8yMM5-y_L6zcd3pZpl12yx-Ce3cvOa78uMtfsHXHfqwi14IFXFgM4ewkKVmTEh-fRKoYNtQgjF4mYpOeWa6f3_GjEGk8dFhJF8Qp5l6krpaXilrI5-xbaK/https%3A%2F%2Fdatatracker.ietf.org%2Fdrafts%2Fcurrent%2F
> 
>   Internet-Drafts are draft documents valid for a maximum of six months
>   and may be updated, replaced, or obsoleted by other documents at any
>   time.  It is inappropriate to use Internet-Drafts as reference
>   material or to cite them other than as "work in progress."
> 
>   This Internet-Draft will expire on 7 October 2022.
> 
> Copyright Notice
> 
>   Copyright (c) 2022 IETF Trust and the persons identified as the
>   document authors.  All rights reserved.
> 
>   This document is subject to BCP 78 and the IETF Trust's Legal
>   Provisions Relating to IETF Documents 
> (https://secure-web.cisco.com/1pg6-wEhXfN-MwhlJ8h7eo-dAl8QdPmldrdMCuN3mEiaCnFsh9HG5WhXZw-WEUmYPUG_F8vGvkIMWnnM80xdkIwd-AdtVO6TCmShu7Bo_OylP4MgMT0Ut4BSdIqUb5Xlol0HIRKB7BmOs5qtg9JJGujEqkzltu9NlRMKSI1ObJUrEPBcSPTgygo2upt2hUiCWfhjnT327rbhdg4D3k4C4L6J-i0c7KJmkeyW0tOOw3djsz6RiFYqqLcmtiOqhPBH1/https%3A%2F%2Ftrustee.ietf.org%2F
>   license-info) in effect on the date of publication of this document.
>   Please review these documents carefully, as they describe your rights
>   and restrictions with respect to this document.  Code Components
>   extracted from this document must include Revised BSD License text as
>   described in Section 4.e of the Trust Legal Provisions and are
>   provided without warranty as described in the Revised BSD License.
> 
> 
> 
> AdellExpires 7 October 2022 [Page 1]
> 
> Internet-Draft   Client Roaming Control   April 2022
> 
> 
> Table of Contents
> 
>   1.  Introduction  . . . . . . . . . . . . . . 

Re: [DNSOP] DNS RFC Collection web site somewhere.

[Wessels, Duane]

> On Mar 30, 2022, at 1:27 PM, Raymond Burkholder  wrote:
> 
> 
> Hello,
> 
> There once was a link posted to a web site which attempted to collect/collate 
> all the RFCs referencing DNS. Is this the one:  https://rfcs.io/dns  Or is 
> there another?
> 

Some others:

https://powerdns.org/dns-camel/

https://emaillab.jp/dns/dns-rfc/

DW

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

Re: [DNSOP] Call for Adoption: DNSSEC as BCP: draft-hoffman-dnssec

[Wessels, Duane]

> On Mar 24, 2022, at 4:07 PM, Tim Wicinski  wrote:
> 
>  
> All
> 
> If you attended the most recent DNSOP session, you've heard Warren speak 
> about creating a BCP for DNSSEC, including  all of the DNSSEC related RFCs, 
> in order to make life easier for implementers and DNS operators. 
> 
> We want to ask the working group if this is something DNSOP wants to work on. 
> If so, we can work with Warren to prioritize getting through the approval 
> process as efficiently as possible.
> 
> 
> This starts a Call for Adoption for: draft-hoffman-dnssec
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-hoffman-dnssec/
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and send any comments to the list, clearly stating your view.

I think it is suitable for adoption.


> Please also indicate if you are willing to contribute text, review, etc.
> 

A couple of things from my first read:

Should the abstract perhaps more directly state the goal of documenting DNSSEC 
as a best current practice?  I find the stated purpose “to introduce all of the 
RFCs in one place” somewhat unconvincing.

From section 4: "IANA already has two registries that relate to DNSSEC”.  
Shouldn’t the DS digest algorithm registry be considered a third?

DW

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

Re: [DNSOP] More private algorithms for DNSSEC

[Wessels, Duane]

Hi Paul,

I think this is good.

Is it in response to the DNS-OARC talk we saw about implementing PQC Falcon in 
PowerDNS, and they used the next unused algorithm number rather than a private 
algorithm? If the authors of that work are on this list I would be interested 
to hear from them about that decision. In particular, would just having more 
private algorithms change their thinking or is something else needed?

DW

 

> On Mar 20, 2022, at 3:21 PM, Paul Hoffman  wrote:
> 
> Greetings again. I have created a new, very short draft to add more private 
> use algorithms to DNSSEC.
>   https://datatracker.ietf.org/doc/draft-hoffman-more-private-algs/
> The abstract says:
>   RFC 4034 allocates one value in the IANA registry for DNSSEC
>   algorithm numbers for private algorithms.  That may be too few for
>   experimentation where multiple yet-to-be-assigned algorithms are
>   used.  This document assigns seven more values for this use case.
> 
> That's about it. This is quite low priority for now, but might become more 
> important as people start to experiment with multiple pre-standard 
> post-quantum algorithms at the same time.
> 
> --Paul Hoffman
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/1wTYBJPegvx-YY8FDLO4TQmd85aR-2DI2pH_1yIk3I-B-ciRbwVZA6lKWr8oR6DqFfDGQLetyrXiOoMYiaYP8Yq8Q4gcSU2Hc-8LodoRKdJJHe-HQVLmzoxZ5DA7ylHe7nq6YVxOdY7neqDUld-hghmdGrPdfphyHU-6A_hzotHSoBty51v7xZlLXMBELLIKZcFz2RHNnUuPZ8_PK4i1TyAjxPC0ToQwd56ffht4GgL8oeK95bNv7jZ43kpyp_yZj/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-04.txt

[Wessels, Duane]

Hello DNSOP,

Here is a short summary of the changes between -03 and -04 of this draft:

We use "referral glue" on the assumption that other types of glue may be 
defined in the future. Not all authors necessarily like this change but we are 
trying it on for size.

Added an Operational Considerations section.

Noted that many current implementations set TC=1 only when no glue RRs fit. New 
requirements may lead to more truncation and TCP.

Sibling glue can be optional (hence a title change). Only require TC=1 when all 
in-domain glue RRs don't fit.

Avoid talking about requirements for UDP/TCP specifically, and talk more 
generically about message size constraints regardless of transport. However, we 
added a paragraph describing the current behavior of most iterative clients to 
start with UDP and fall back to TCP when truncated.

DW


> On Feb 8, 2022, at 2:33 PM, internet-dra...@ietf.org wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> 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   : DNS Referral Glue Requirements
>Authors : M. Andrews
>  Shumon Huque
>  Paul Wouters
>  Duane Wessels
>   Filename: draft-ietf-dnsop-glue-is-not-optional-04.txt
>   Pages   : 10
>   Date: 2022-02-08
> 
> Abstract:
>   The DNS uses referral glue records to allow iterative clients to find
>   the addresses of nameservers that are contained within a delegated
>   zone.  Authoritative Servers are expected to return all available
>   referral glue records in a referral response.  If message size
>   constraints prevent the inclusion of all in-domain referral glue
>   records, the server MUST set the TC flag to inform the client that
>   the response is incomplete, and that the client SHOULD use another
>   transport to retrieve the full response.  This document updates RFC
>   1034 to clarify correct server behavior.
> 

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

Re: [DNSOP] Fwd: New Version Notification for draft-dwmtwc-dnsop-caching-resolution-failures-00.txt

[Wessels, Duane]

Hi Petr,

I would say one is a subset of the other, but not exactly the same topic.

draft-moura-dnsop-negative-cache-loop focuses relatively narrowly on one type 
of resolution failure: delegations in a loop / cyclic dependency as documented 
in their TusNAME work.

draft-dwmtwc-dnsop-caching-resolution-failures, on the other hand, is intended 
to cover resolution failures much more broadly. Based on our experience, we 
observe abnormal behavior in a number of different situations including 
outages, timeouts, server failures, validation failures, and delegation 
problems.

We plan to present our draft at the next meeting and I assume the other authors 
will as well, so that will be a good chance for the working group to give us 
all feedback.

DW



> On Feb 8, 2022, at 5:28 AM, Petr Špaček  wrote:
> 
> Hello everyone,
> 
> it seems that we now have two drafts about the same topic - this new one and 
> draft-moura-dnsop-negative-cache-loop.
> 
> Perhaps authors could discuss if they are in agreement and could pick one?
> 
> Petr Špaček  @  Internet Systems Consortium
> 
> 
> 
> On 14. 01. 22 19:14, Wessels, Duane wrote:
>> Dear DNSOP,
>> In light of some recent events and research, we feel that it could be 
>> beneficial to strengthen the requirements around negative caching of DNS 
>> resolution failures. Please see the recently submitted Internet Draft 
>> referenced below and let us know if you have any feedback.
>> DW
>>> Begin forwarded message:
>>> 
>>> *From: *mailto:internet-dra...@ietf.org>>
>>> *Subject: **[EXTERNAL] New Version Notification for 
>>> draft-dwmtwc-dnsop-caching-resolution-failures-00.txt*
>>> *Date: *January 13, 2022 at 1:28:00 PM PST
>>> *To: *Duane Wessels mailto:dwess...@verisign.com>>, 
>>> Matthew Thomas mailto:mtho...@verisign.com>>, 
>>> William Carroll mailto:wicarr...@verisign.com>>
>>> 
>>> A new version of I-D, draft-dwmtwc-dnsop-caching-resolution-failures-00.txt
>>> has been successfully submitted by William Carroll and posted to the
>>> IETF repository.
>>> 
>>> Name:draft-dwmtwc-dnsop-caching-resolution-failures
>>> Revision:00
>>> Title:Negative Caching of DNS Resolution Failures
>>> Document date:2022-01-13
>>> Group:Individual Submission
>>> Pages:13
>>> URL: 
>>> https://secure-web.cisco.com/1-PFLv-gJPKY7IUv53FHemsD97LSSdToCXsQHAguzJmIyVR8DlgbIUfK3NQBXH-5zgoS4DQIIvAT9SMf0y632bk-kgt0veCCWPt9eqKvdmUM_8bz-jZwYAtW9vzG8Yle7Gp7sv_jeafkAwZw5L2kCkJgy4hfNVxUERJJyCxnWI88uVj_yjKi5NiJgO5ANYPWUfYKdg_SnWCnWUDLuwAgLHaD476ZKPPsK82E0W_s8SJOQoH4OGG9glsNw5_92tWYg/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-dwmtwc-dnsop-caching-resolution-failures-00.txt
>>>  
>>> <https://secure-web.cisco.com/1-PFLv-gJPKY7IUv53FHemsD97LSSdToCXsQHAguzJmIyVR8DlgbIUfK3NQBXH-5zgoS4DQIIvAT9SMf0y632bk-kgt0veCCWPt9eqKvdmUM_8bz-jZwYAtW9vzG8Yle7Gp7sv_jeafkAwZw5L2kCkJgy4hfNVxUERJJyCxnWI88uVj_yjKi5NiJgO5ANYPWUfYKdg_SnWCnWUDLuwAgLHaD476ZKPPsK82E0W_s8SJOQoH4OGG9glsNw5_92tWYg/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-dwmtwc-dnsop-caching-resolution-failures-00.txt>
>>> Status: 
>>> https://secure-web.cisco.com/1DyTvZbisHjKnPovlyhjAOtHxDAwKAqB2zXhGz5eE0Ca-1XPZAqQhDEyq-XNf1nKXr9SySf_nEWu5XQkh450f2xF3gmfQKMuLIyBqZqbYTfqZyyMbWrcyG3KqVYjmGV6dL3NSnwTn0iXcgzWvT7mLCzivYnGbpRH23V8z4fqw3ikCCp6NwxyuP8O_ak1u03fM9kH0QYTu_C1vGE3rGAn7dFkT0A4Vk3mRhgnZSlh3vhaJmDWMO1xylYlPvJBQ40Af/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dwmtwc-dnsop-caching-resolution-failures%2F
>>>  
>>> <https://secure-web.cisco.com/1DyTvZbisHjKnPovlyhjAOtHxDAwKAqB2zXhGz5eE0Ca-1XPZAqQhDEyq-XNf1nKXr9SySf_nEWu5XQkh450f2xF3gmfQKMuLIyBqZqbYTfqZyyMbWrcyG3KqVYjmGV6dL3NSnwTn0iXcgzWvT7mLCzivYnGbpRH23V8z4fqw3ikCCp6NwxyuP8O_ak1u03fM9kH0QYTu_C1vGE3rGAn7dFkT0A4Vk3mRhgnZSlh3vhaJmDWMO1xylYlPvJBQ40Af/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dwmtwc-dnsop-caching-resolution-failures%2F>
>>> Htmlized: 
>>> https://secure-web.cisco.com/1MtdsiBy0XYrTWaww2jsyGmhpR1_l4cfsY2lzwq4M4gkF3VU-omPqy4e66hhbK7hfsy_x0cC1ZTi4VBXdrxpcOJPQgL-NdJ6b_iqYKCiDtAXs-6A60hPQqq4UZ7C7A1iyL29ghpvCZWMAvER26fj-YW4tmLvr5avpsjTGdZZTCIzvskQ9Nn-Degm8WJ03ldm01hMS6gB7ditarcN0g-dAl6zKyLmHKLy-txj3g8mNMsKTuTmkkE7vXFX-YxgBfJel/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dwmtwc-dnsop-caching-resolution-failures
>>>  
>>> <https://secure-web.cisco.com/1MtdsiBy0XYrTWaww2jsyGmhpR1_l4cfsY2lzwq4M4gkF3VU-omPqy4e66hhbK7hfsy_x0cC1ZTi4VBXdrxpcOJPQgL-NdJ6b_iqYKCiDtAXs-6A60hPQqq4UZ7C7A1iyL29ghpvCZWMAvER26fj-YW4tmLvr5avpsjTGdZZTCIzvskQ9Nn-Degm8WJ03ldm01hMS6gB7ditarcN0g-dAl6zKyLmHKLy-txj3g8mNMsKTuTmkkE7vXFX-YxgBfJel/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dwmtwc-dnso

[DNSOP] Fwd: New Version Notification for draft-dwmtwc-dnsop-caching-resolution-failures-00.txt

[Wessels, Duane]

Dear DNSOP,

In light of some recent events and research, we feel that it could be 
beneficial to strengthen the requirements around negative caching of DNS 
resolution failures. Please see the recently submitted Internet Draft 
referenced below and let us know if you have any feedback.

DW


Begin forwarded message:

From: mailto:internet-dra...@ietf.org>>
Subject: [EXTERNAL] New Version Notification for 
draft-dwmtwc-dnsop-caching-resolution-failures-00.txt
Date: January 13, 2022 at 1:28:00 PM PST
To: Duane Wessels mailto:dwess...@verisign.com>>, 
Matthew Thomas mailto:mtho...@verisign.com>>, William 
Carroll mailto:wicarr...@verisign.com>>

A new version of I-D, draft-dwmtwc-dnsop-caching-resolution-failures-00.txt
has been successfully submitted by William Carroll and posted to the
IETF repository.

Name: draft-dwmtwc-dnsop-caching-resolution-failures
Revision: 00
Title: Negative Caching of DNS Resolution Failures
Document date: 2022-01-13
Group: Individual Submission
Pages: 13
URL:
https://www.ietf.org/archive/id/draft-dwmtwc-dnsop-caching-resolution-failures-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-dwmtwc-dnsop-caching-resolution-failures/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-dwmtwc-dnsop-caching-resolution-failures


Abstract:
  In the DNS, resolvers employ caching to reduce both latency for end
  users and load on authoritative name servers.  The process of
  resolution may result in one of three types of responses: (1) a
  response containing the requested data; (2) a response indicating the
  requested data does not exist; or (3) a non-response due to a
  resolution failure in which the resolver does not receive any useful
  information regarding the data's existence.  This document concerns
  itself only with the third type.

  RFC 2308 specifies requirements for DNS negative caching.  There,
  caching of type (1) and (2) responses is mandatory and caching of
  type (3) responses is optional.  This document updates RFC 2308 to
  require negative caching for DNS resolution failures.




The IETF Secretariat



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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-03.txt

[Wessels, Duane]

In order to make progress on the glue-is-not-optional draft, we need the 
working group to reach consensus on the requirement level for sibling glue 
(MUST, SHOULD, or MAY).

The only situation in which a failure to include sibling glue leads to a 
resolution failure is when there is a sibling glue cyclic dependency.  e.g.:

  bar.test.  86400   IN NS  ns1.foo.test.
  bar.test.  86400   IN NS  ns2.foo.test.

  foo.test.  86400   IN NS  ns1.bar.test.
  foo.test.  86400   IN NS  ns2.bar.test.

A few months back I analyzed the zone files available to me via CZDS for 
sibling glue.  Out of some 209,000,000 total delegations, 222 of them had only 
sibling NS records in a cyclic dependency as above.  The domains ADOBE.NET and 
OMTRDC.NET is one real-world example.

The arguments for making sibling glue a MUST are:

1. accommodates (the 0.0001% of) domains with cyclic sibling glue.

2. simpler to specify, don’t need differing requirements for in-domain and 
sibling glue.

The arguments against are:

1. domains with cyclic sibling delegations should be considered “broken” and 
not expected to work, perhaps similar to TsuNAME-style external delegation 
cycles.

2. increases response sizes, truncation probability, and amount of TCP.


DW




> On Oct 11, 2021, at 4:51 PM, Wessels, Duane  wrote:
> 
> Dear DNSOP,
> 
> Changes to this draft from the previous version are as follows:
> 
>   *  Clarified scope to focus only on name server responses, and not
>  zone/registry data.
>   *  Reorganized with section 2 as Types of Glue and section 3 as
>  Requirements.
>   *  Removed any discussion of promoted / orphan glue.
>   *  Use appropriate documentation addresses and domain names.
>   *  Added Sibling Cyclic Glue example.
> 
> I'd say we still do not have consensus on treatment of sibling glue.  Section 
> 3.2 currently has the strict requirements with optional more lenient 
> requirements in [square brackets]:
> 
> 3.2.  Sibling Glue
> 
>   This document clarifies that when a name server generates a referral
>   response, it MUST [SHOULD] include available sibling glue records in
>   the additional section.  If all sibling glue records do not fit in a
>   UDP response, the name server MUST [is NOT REQUIRED to] set TC=1.
> 
> 
> DW
> 
> 
>> On Oct 11, 2021, at 4:30 PM, internet-dra...@ietf.org wrote:
>> 
>> Caution: This email originated from outside the organization. Do not click 
>> links or open attachments unless you recognize the sender and know the 
>> content is safe. 
>> 
>> 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   : Glue In DNS Referral Responses Is Not Optional
>>   Authors : M. Andrews
>> Shumon Huque
>> Paul Wouters
>> Duane Wessels
>>  Filename: draft-ietf-dnsop-glue-is-not-optional-03.txt
>>  Pages   : 9
>>  Date: 2021-10-11
>> 
>> Abstract:
>>  The DNS uses glue records to allow iterative clients to find the
>>  addresses of nameservers that are contained within a delegated zone.
>>  Authoritative Servers are expected to return all available glue
>>  records in referrals.  If message size constraints prevent the
>>  inclusion of all glue records in a UDP response, the server MUST set
>>  the TC flag to inform the client that the response is incomplete, and
>>  that the client SHOULD use TCP to retrieve the full response.  This
>>  document updates RFC 1034 to clarify correct server behavior.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/
>> 
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-dnsop-glue-is-not-optional-03.html
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-glue-is-not-optional-03
>> 
>> 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

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

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Wessels, Duane]

> On Dec 24, 2021, at 11:27 AM, Benjamin Kaduk  wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> Hi Duane,
> 
> Sorry for the very delayed response.
> I will go update my ballot position shortly, but please see
> https://secure-web.cisco.com/1NC-Sp-k6c9fQvvh8KF_51aDQMeCoXJOhd8ivZXqXshCS_zHlPK9gm5KW3WpwesqBhQZy2tr0vvxGjusWah0AD2lYdmmloT1EBJRUpjjPXs1V0NjYwNf3CzNPxn66JGiamjcl3YxFfhCFF99bFT9_oUKN8EogHEJZysGMZyiVkG-AK2oOzI9kNaghHqRWls10qqte96vadcqFsjLZtvYgr9IPUB4UMR8QrUvCZNrS4oGYTUmwWdPB1_hRkrOg5Hu6/https%3A%2F%2Fgithub.com%2Fjtkristoff%2Fdraft-ietf-dnsop-dns-tcp-requirements%2Fpull%2F11
> for some further edits to the text for discuss point (1).
> 
> On Mon, Nov 08, 2021 at 10:35:21PM +, Wessels, Duane wrote:
>> Hi Ben, thank you for the detailed review.  It has taken me a while to work 
>> through
>> all of your comments and suggestions, but hopefully this addresses them 
>> sufficiently.
>> 
>> 
>> 
>>> On Oct 25, 2021, at 3:51 PM, Benjamin Kaduk via Datatracker 
>>>  wrote:
>>> 
>>> 
>>> --
>>> DISCUSS:
>>> --
>>> 
>>> (1) This should be pretty easy to resolve, but this text from §4.4
>>> does not seem to match up with the referenced document:
>>> 
>>>  The use of TLS places even stronger operational burdens on DNS
>>>  clients and servers.  Cryptographic functions for authentication and
>>>  encryption requires additional processing.  Unoptimized connection
>>>  setup takes two additional round-trips compared to TCP, but can be
>>>  reduced with TCP Fast Open, TLS session resumption [RFC8446] and TLS
>>>  False Start [RFC7918].
>>> 
>>> Two additional round trips was true of TLS 1.2 and prior versions, but
>>> as of TLS 1.3 the application data from the client can be sent after
>>> only 1 round trip, accompanying the client Finished (and authentication
>>> messages, if in use).  Given the nature of the rest of the sentence, we
>>> might want to specifically mention TLS 1.3 as an improvement over TLS
>>> 1.2, but there are probably a number of ways that we could fix it.  Note
>>> additionally that for TLS 1.3, session resumption is not a reduction in
>>> the number of round trips unless 0-RTT data is used (but AFAIK there is
>>> not a published application profile specifying acceptable DNS content
>>> for TLS 0-RTT data, so use of TLS 0-RTT data for DNS is forbidden), but
>>> is still an efficiency gain due to the reduced number of cryptographic
>>> operations (including certificate validation).
>> 
>> Is this better?
>> 
>>   The use of TLS places even stronger operational burdens on DNS
>>   clients and servers.  Cryptographic functions for authentication and
>>   encryption requires additional processing.  Unoptimized connection
>>   setup with TLS 1.3 [RFC8446] takes one additional round-trip compared
>>   to TCP.  Connection setup times can be reduced with TCP Fast Open,
>>   and TLS False Start [RFC7918].  TLS session resumption does not
>>   reduce round-trip latency becase no application profile for use of
>>   TLS 0-RTT data with DNS has been published at the time of this
>>   writing.  However, TLS session resumption can reduce the number of
>>   cryptographic operations.
> 
> As mentioned above,
> https://secure-web.cisco.com/1NC-Sp-k6c9fQvvh8KF_51aDQMeCoXJOhd8ivZXqXshCS_zHlPK9gm5KW3WpwesqBhQZy2tr0vvxGjusWah0AD2lYdmmloT1EBJRUpjjPXs1V0NjYwNf3CzNPxn66JGiamjcl3YxFfhCFF99bFT9_oUKN8EogHEJZysGMZyiVkG-AK2oOzI9kNaghHqRWls10qqte96vadcqFsjLZtvYgr9IPUB4UMR8QrUvCZNrS4oGYTUmwWdPB1_hRkrOg5Hu6/https%3A%2F%2Fgithub.com%2Fjtkristoff%2Fdraft-ietf-dnsop-dns-tcp-requirements%2Fpull%2F11
> has a few tweaks to this to account for the differences between TLS 1.2 and
> TLS 1.3, and the skew in feature availability between the TLS versions.
> (Highlights: RFC 7918 is 1.2-only, and TLS 1.2 session resumption does save
> a round-trip (the current text implicitly assumes 1.3).)

This pull request was accepted and merged.

>> 
>> 
>>> 
>>> Section 8
>>> 
>>> There's a lot of good advice interspersed in the main body text already;
>>> thank you for that!
>>> 
>>> The discussion in §4.1 suggests ("SHOULD") to share a TFO server key
>>> amongst servers in a server farm, but this introduces the usual security
>&

Re: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Wessels, Duane]

> On Dec 23, 2021, at 10:28 AM, Benjamin Kaduk  wrote:
> 
> 
> Hi Duane,
> 
> On Mon, Nov 29, 2021 at 11:53:48PM +0000, Wessels, Duane wrote:
>> 
>> 
>>> On Oct 26, 2021, at 4:35 AM, Lars Eggert via Datatracker  
>>> wrote:
> [...]
>>> Section 4.2. , paragraph 3, comment:
>>>>  DNS server software MAY provide a configurable limit on the number of
>>>>  transactions per TCP connection.
>>> 
>>> What does that limit protect against?
>> 
>> proposed new text:
>> 
>>   DNS server software MAY provide a configurable limit on the number of
>>   transactions per TCP connection.  This can help protect against
>>   unfair connection use (e.g., not releasing connection slots to other
>>   clients) and network evasion attacks.
>> 
>> 
>>> 
>>> Section 4.2. , paragraph 2, comment:
>>>>  Similarly, DNS server software MAY provide a configurable limit on
>>>>  the total duration of a TCP connection.
>>> 
>>> What does that limit protect against?
>> 
>> Proposed new text:
>> 
>>   Similarly, DNS server software MAY provide a configurable limit on
>>   the total duration of a TCP connection.  This can help protect
>>   against unfair connection use, slow read attacks, and network evasion
>>   attacks.
> 
> Maybe I'm just being dense today, or lost too much state in the intervening
> weeks, but how do these limits protect against network evasion attacks?
> What are "network evasion attacks" in this context, anyway?  The draft
> references [phrack] in a different location surrounding use of that term,
> in the context of applications doing TCP stream reassembly from packet
> captures.  In that location it seems that the TCP segmentation could cause
> the reassembling application to miss actual DNS protocol messages, but I'm
> not sure how transaction or time limits on a connection would protect
> against a similar loss of processing of DNS protocol messages by the
> reassembling application.
> 
> Thanks,
> 
> Ben
> 

Hi Ben,


Yes, network evasion attack has the same meaning here: An application that
does packet capture can miss some DNS messages if it doesnt implement TCP
stream reassembly, or implements it imperfectly.

I will say that I'm not adamant about including evasion attacks here.  It
may be a bit of a stretch.  I guess I tend to think of packet stream
reassembly somewhat probabilistically, in that unless the implementation
and conditions are perfect, the longer that a TCP session lasts then the
more likely it is to miss data.

If the DNS operator knows that their capture-based monitoring is not
perfect, then they may want to limit TCP sessions either by transaction
count or by time.  Similarly, they might know that packet capture drops/loss
in the system could affect stream reassembly.

Maybe this isn't really a network evasion attack, but rather just a workaround
for a poor implementation, and really argues against capture based monitoring.
I'm happy to remove it if it doesnt make sense.

DW


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

Re: [DNSOP] Another attempt at consensus on the bailiwick discussion

[Wessels, Duane]

> On Dec 15, 2021, at 5:31 PM, Paul Wouters  wrote:
> 
> On Dec 15, 2021, at 18:56, Wessels, Duane 
>  wrote:
>> 
>> For me “necessary” is an important distinction and “might be useful” is too 
>> broad or ambiguous.  I have a hard time reconciling the idea that glue is 
>> not optional with the idea that it might be useful
> 
> Necessary for resolving, securely resolving and/or resolving with privacy ?
> 
> In other words, would a TLSA or SVCB be “necessary” or not ?
> 
> Paul

Well, that is why I feel that we’re heading in a direction where the IETF will 
have to say which RR types must be considered as glue (aka necessary).  Today 
it's just A and , but if some of the proposals in DPRIVE achieve consensus 
then maybe those other types become designated as glue.

DW


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

Re: [DNSOP] Another attempt at consensus on the bailiwick discussion

[Wessels, Duane]

For me “necessary” is an important distinction and “might be useful” is too 
broad or ambiguous.  I have a hard time reconciling the idea that glue is not 
optional with the idea that it might be useful.

DW


> On Dec 15, 2021, at 3:18 PM, Ben Schwartz 
>  wrote:
> 
> 
> 
> I like this definition.  However, I think it would be clearer to say "useful" 
> instead of "necessary".
> 
> On Wed, Dec 15, 2021 at 1:18 PM Wessels, Duane 
>  wrote:
> Despite what the subject line says, I’d like to follow up on the discussion 
> about glue from today’s interim meeting.
> 
> First, I think the definition of glue given in RFC 2181 is problematic in a 
> number of ways.  It is overly broad (e.g., "any record ... that is not 
> properly part of that zone” and "any other stray data that might appear”).  
> It essentially says that all non-authoritative data is glue, including NS, 
> which is wrong IMO.
> 
> If we can ignore what 2181 says, then the question is whether or not glue is 
> limited only to addresses.  Historically it has only meant addresses, since 
> those address RRs were required for zones with in-domain name servers.  There 
> are some new proposals in DPRIVE to publish more record types in parent zones 
> and have them considered as glue.  This has obvious implications server 
> behavior given the glue-is-not-optional draft.
> 
> On one hand I think it would be a lot simpler to just say that only address 
> records can be glue.  But I’m not sure that is defendable given the 
> directions things are going.  Here’s a definition of glue that I came up with:
> 
> Glue is non-authoritative data in a zone that is transmitted in the 
> additional section of a referral response on the basis that the data might be 
> necessary for resolution to proceed at the referred name servers.
> 
> I also feel like we might be heading in a direction where there would need to 
> be a registry or some standardization of which RR types can be treated as 
> glue.
> 
> DW
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] Another attempt at consensus on the bailiwick discussion

[Wessels, Duane]

Despite what the subject line says, I’d like to follow up on the discussion 
about glue from today’s interim meeting.

First, I think the definition of glue given in RFC 2181 is problematic in a 
number of ways.  It is overly broad (e.g., "any record ... that is not properly 
part of that zone” and "any other stray data that might appear”).  It 
essentially says that all non-authoritative data is glue, including NS, which 
is wrong IMO.

If we can ignore what 2181 says, then the question is whether or not glue is 
limited only to addresses.  Historically it has only meant addresses, since 
those address RRs were required for zones with in-domain name servers.  There 
are some new proposals in DPRIVE to publish more record types in parent zones 
and have them considered as glue.  This has obvious implications server 
behavior given the glue-is-not-optional draft.

On one hand I think it would be a lot simpler to just say that only address 
records can be glue.  But I’m not sure that is defendable given the directions 
things are going.  Here’s a definition of glue that I came up with:

Glue is non-authoritative data in a zone that is transmitted in the additional 
section of a referral response on the basis that the data might be necessary 
for resolution to proceed at the referred name servers.

I also feel like we might be heading in a direction where there would need to 
be a registry or some standardization of which RR types can be treated as glue.

DW


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

Re: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Wessels, Duane]

> On Nov 29, 2021, at 11:51 PM, Lars Eggert  wrote:
> 
> 
>> I dont necessarily agree that operating systems alone do a very good job
>> of preventing DOS conditions.  It is possible that Im not up-to-date on
>> the latest and greatest in terms of operating system features, but I think
>> historically applications have fared better when they manage their own
>> connections.  For example, can we realistically expect the OS to know which
>> idle connections should be closed?
> 
> The OS will certainly try to close sufficient connections under DDoS to 
> remain operational. But if an application wants to see connections closed 
> according to a certain policy - and DNS servers probably would - they need to 
> actively engage. Maybe that's the rationale here?
> 

Yes, that is the rationale.  I’ve added a new sentence to the end
of this paragraph along those lines:

   Operators of DNS server software SHOULD be aware that operating
   system and application vendors MAY impose a limit on the total number
   of established connections.  These limits may be designed to protect
   against DDoS attacks or performance degradation.  Operators SHOULD
   understand how to increase these limits if necessary, and the
   consequences of doing so.  Limits imposed by the application SHOULD
   be lower than limits imposed by the operating system, so that the
   application can apply its own policy to connection management, such
   as closing the oldest idle connections first.


>> 
>>> Section 4.2. , paragraph 3, comment:
 DNS server software SHOULD provide a configurable timeout for idle
 TCP connections.  For very busy name servers this might be set to a
 low value, such as a few seconds.  For less busy servers it might be
 set to a higher value, such as tens of seconds.
>>> 
>>> Ditto.
>> 
>> In this case all of the open source implementations I surveyed have this
>> limit enabled by default.
> 
> It might be useful to add a brief note similar to the one above here as well.

Okay, I’ve done so in this paragraph. Second and third sentences are new:

   DNS server software SHOULD provide a configurable timeout for idle
   TCP connections.  This can be used to free up resources for new
   connections and to ensure that idle connections are eventually
   closed.  At the same time, it possibly limits client performance
   while leaving some TCP resources untilizied.  For very busy name
   servers this might be set to a low value, such as a few seconds.  For
   less busy servers it might be set to a higher value, such as tens of
   seconds.  DNS clients and servers SHOULD signal their timeout values
   using the edns-tcp-keepalive option [RFC7828].


> 
> Thanks,
> Lars
> 

Thank you!

DW

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

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Wessels, Duane]

> On Nov 8, 2021, at 4:24 PM, Joe Abley  wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> On Nov 8, 2021, at 17:35, Wessels, Duane 
>  wrote:
> 
>> Is this better?
>> 
>>  The use of TLS places even stronger operational burdens on DNS
>>  clients and servers.  Cryptographic functions for authentication and
>>  encryption requires additional processing.
> 
> Require, not requires. I know, I know.

Fixed!


> 
>> Unoptimized connection
>>  setup with TLS 1.3 [RFC8446] takes one additional round-trip compared
>>  to TCP.  Connection setup times can be reduced with TCP Fast Open,
>>  and TLS False Start [RFC7918].  TLS session resumption does not
>>  reduce round-trip latency becase no application profile for use of
>>  TLS 0-RTT data with DNS has been published at the time of this
>>  writing.  However, TLS session resumption can reduce the number of
>>  cryptographic operations.
> 
> [...]
> 
>> Agreed, hopefully this is better:
>> 
>>  o  Authoritative servers MUST support and service TCP for receiving
>> queries, so that resolvers can reliably receive responses that are
>> larger than what fits in a single UDP packet.
> 
> RFC 6891 anticipates reassembly and doesn't advise against setting a UDP 
> payload size that would cause fragmentation (although it mentions that people 
> should be careful). So "single UDP packet" seems a bit awkward, especially 
> since in principle the size limit is 0x octets in both the UDP header and 
> the corresponding EDNS(0) pseudo-header.
> 
> This paragraph (and the ones that follow) seem like they are implying that 
> large responses are the only reason to use TCP (which is surely just a 
> side-effect of wording; I'm not suggesting the authors are unaware of other 
> reasons). Using truncated responses as an example seems fine though.
> 
> I don't think the taxonomy of "authoritative servers", "recursive servers" 
> and "forwarders" is necessarily complete. The terminology in common usage is 
> not tightly bound by common sense, and there is an apparently unlimited 
> supply of words and phrases that people use to mean "a DNS thing attached to 
> a network".
> 
> This seems like it could be a job for "initiators" and "responders", except 
> that in this case I think we're really talking about all DNS implementations, 
> regardless of function. Hooray! Bullet dodged, maybe.
> 
> How about something like:
> 
> o All DNS implementations, regardless of function, MUST support and service 
> TCP for sending and receiving queries, e.g. to accommodate the sending and 
> receiving of DNS messages that are too large to handle using UDP without 
> truncation.

Thanks for pointing this out.  I agree that “single UDP packet” is problematic 
and we missed this detail before.


Here’s how this text appeared in version 13:

   o  Authoritative servers MUST support and service all TCP queries so
  that they do not limit the size of responses to what fits in a
  single UDP packet.

   o  Recursive servers (or forwarders) MUST support and service all TCP
  queries so that they do not prevent large responses from a TCP-
  capable server from reaching its TCP-capable clients.

Based on Ben’s comments, I then proposed this:

  o  Authoritative servers MUST support and service TCP for receiving
 queries, so that resolvers can reliably receive responses that are
 larger than what fits in a single UDP packet.

  o  Recursive servers (and forwarders) MUST support and service TCP
 for receiving queries, so their TCP-capable clients can reliably
 receive responses that are larger than what fits in a single UDP
 packet.

  o  Recursive servers (and forwarders) MUST support TCP for sending
 queries, so that they can retry truncated UDP responses as
 necessary.


And based on your further suggestions I think it makes sense to combine
authoritative and recursive together, but keep clients as a separate bullet:

   o  DNS servers (including forwarders) MUST support and service TCP
  for receiving queries, so that clients can reliably receive
  responses that are larger than what either side considers too
  large for UDP.

   o  DNS clients MUST support TCP for sending queries, so that they can
  retry truncated UDP responses as necessary.

“what either side considers too large for UDP” is an oblique reference to
EDNS(0) UDP buffer size parameters.

How does that strike you?

DW


> 
> 
> Joe

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

Re: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Wessels, Duane]

> On Oct 26, 2021, at 4:35 AM, Lars Eggert via Datatracker  
> wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> Lars Eggert has entered the following ballot position for
> draft-ietf-dnsop-dns-tcp-requirements-13: Discuss
> 
> 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://secure-web.cisco.com/1kXvipN4VaKHO3AYxNHSk3_n8uHuI5gukOoaWs_9cG3yENUfEij_EahsVifsuqDvJ87tOMzqfsQvSNVDrlS_-uD93gYFrH-W0nErz-3dDIJpel5Zl7MmuWBdfniJzujsocAV1lsSsYtX8awWBkQ8eb_GhRen4BPENNuz1f9DU8scOGmh_6XvDTl2h2Ut3BN2YuNmDbmfWLYWKn2ljBjy70M3-N-vnFroRv7U3a3Kq-iNDmhKR53kaMlSwzI1NM_rK/https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2F
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://secure-web.cisco.com/1V7ehlyVXKiQcvhjjSAc0dm4x7jce6oRNiVmeJVwrJmYfNJTQCXozSCiVsTTDTMA31OsPaLi5ktIBX_1SJTMwPOMjHkyejN20CFahmTm4V-mFwr3n3zhznbcttOwt49mZNQ24MwFa4SFXIhHivGRuI65YKsZUQDdEJj2ORiTP9kCyMMSw6uGu5eE_JQtlH1M3Q7rqSm33c6SaE0h2NlmjlKGPa6zzXngPE8McI90Hbd47Q3rc4CuANJZLqNdhgNwu/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-tcp-requirements%2F
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Section 4.2. , paragraph 3, discuss:
>>   Since host memory for TCP state is a finite resource, DNS clients and
>>   servers MUST actively manage their connections.  Applications that do
>>   not actively manage their connections can encounter resource
>>   exhaustion leading to denial of service.  For DNS, as in other
>>   protocols, there is a tradeoff between keeping connections open for
>>   potential future use and the need to free up resources for new
>>   connections that will arrive.
> 
> For it to contain a MUST-level requirement, this section needs to give a lot
> more concrete guidance on what it means to "actively" manage connections. Most
> operating systems by default impose some application limits that usually
> effectively prevent DOS or other resource exhaustion issues. Is the intent 
> here
> that DNS implementations need to do more? If so, what?

I can easily be convinced that SHOULD is more appropriate than MUST here.  

I dont necessarily agree that operating systems alone do a very good job
of preventing DOS conditions.  It is possible that Im not up-to-date on
the latest and greatest in terms of operating system features, but I think
historically applications have fared better when they manage their own
connections.  For example, can we realistically expect the OS to know which
idle connections should be closed?

> 
> 
> --
> COMMENT:
> --
> 
> Section 2.4. , paragraph 1, comment:
>> 2.4.  Fragmentation and Truncation
> 
> Fragmentation and IP fragments getting dropped is one reason for needing more
> retries with EDNS(0). But IIRC, a larger contributing factor is that EDNS(0)
> doesn't detect or recover from loss of any UDP packets making up the overall
> message. That means that a normal packet loss (due to congestion or other
> reasons) amplifies into loss of the entire DNS message.

This new paragraph has been added:

   Note that a receiver is unable to differentiate between packets lost
   due to congestion and packets (fragments) intentionally dropped by
   firewalls or middleboxes.  Over network paths with non-trival amounts
   of packet loss, larger, fragmented DNS responses are more likely to
   never arrive and time out compared to smaller, unfragmented
   responses.  Clients might be misled into retrying queries with
   different EDNS(0) UDP packet size values for the wrong reason.

> 
> Section 3. , paragraph 1, comment:
>> 3.  DNS over TCP Requirements
> 
> While the history preceding this section is interesting for context, I think
> moving this section up would increase readability significantly.

Okay with me.  I would like to hear from the Chairs.

> 
> Section 4.2. , paragraph 3, comment:
>>   DNS server software SHOULD provide a configurable limit on the total
>>   number of established TCP connections.  If the limit is reached, the
>>   application is expected to either close existing (idle) connections
>>   or refuse new connections.  Operators SHOULD ensure the limit is
>>   configured appropriately for their particular situation.
> 
> Again, the OS generally already imposes limits. Why recommend that DNS
> implementations self-impose other (lower?) limits?
Perhaps the below text is better?  It is directed more to operators (the

Re: [DNSOP] John Scudder's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

[Wessels, Duane]

John, thanks for the review.


> On Oct 28, 2021, at 6:42 AM, John Scudder via Datatracker  
> wrote:
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for the well-written document!
> 
> A few comments --
> 
> 1. I have similar concerns to Ben's regarding the use of BCP as a vehicle to
> update the Standards Track documents in question. If I had a better option to
> offer at this stage in the document's history, I would, but under the
> circumstances I don't. If we had it to do over again, my preference would have
> been to progress a small PS to update the Standards Track documents, and a BCP
> to provide all the rest of the content. In addition to the points Ben made, my
> discomfort also stems from the fact that the advice regarding implementations
> has inherently short shelf life (relatively speaking) whereas the updates are
> forever (or at least until the updated documents are bis'd).
>   I'm not requesting any change with this observation, just putting it out
>   there for discussion (without making it a DISCUSS...).
> 
> 2. In Section 3, another +1 to Ben's comment. In particular the "lastly" part
> seemed especially loosy-goosy to me as written, as to what precisely is 
> updated
> in RFC 1536. The flow of the prose is nice, but the conclusion is less than
> clear. I do think some rewrite of this section would be helpful.

Here’s how this part reads now:

   Lastly, Section 1 of [RFC1536] is updated to eliminate the
   misconception that TCP is only useful for zone transfers:

   OLD:

  DNS implements the classic request-response scheme of client-
  server interaction.  UDP is, therefore, the chosen protocol for
  communication though TCP is used for zone transfers.

   NEW:

  DNS implements the classic request-response scheme of client-
  server interaction.


> 3. Section 6 says applications should perform “full TCP segment reassembly”.
> What does that mean? A quick google search doesn’t suggest it’s a well-known
> term of art. I'm guessing that what you mean is that the applications should
> capture (and log, etc) the bytestream that was segmented and transmitted by 
> TCP?

This has been updated as follows:

   Applications
   that capture network packets (e.g., with libpcap [libpcap]) SHOULD
   implement and perform full TCP stream reassembly and analyze the
   reassembled stream instead of the individual packets.  Otherwise,
   they are vulnerable to network evasion attacks [phrack].


DW


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

Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

[Wessels, Duane]

Hi Éric, thank you for the review!



> On Oct 28, 2021, at 5:33 AM, Éric Vyncke via Datatracker  
> wrote:
> 
> --
> COMMENT:
> --
> 
> Thank you for the work put into this document.
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and some nits.
> 
> Special thanks to Suzanne Woolf for the shepherd's write-up about the WG
> consensus.
> 
> Thank you also to Ron Bonica for the shortest (1 line) but positive review for
> the Internet directorate:
> https://secure-web.cisco.com/1jbJkhQyobZfJSmvsaMZeoGFdhMnstIYcTFajo1Q4Vr-CbsR5S5e8mFYoGc-Ne9ghqsEhgK0G36DyJQe-ZnMVNwjxMjwV2g6LrwwY3sO9ts9qb1jzShVafaFTeaFWakKikXfnicx4aEdtORvqF6TNyIcc8g4cNlNvptkD3jJ61pxlER2WobXcqR7pcPaFTKdUQ7vKOcrRa9jHgDA4i7G3dkRcQlA2JVoyMrj9Z9XtWB0ij4N4jL3a_wVh5-P4-gkJ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Freview-ietf-dnsop-dns-tcp-requirements-13-intdir-telechat-bonica-2021-10-26%2F
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> I would have expected a little more about anycast DNS servers as TCP is
> probably a no-go for those servers. I see only one mention of anycast in the
> whole document.

RFC 7766 (which is the implementation requirements companion to this one)
already says this about anycast:

   Long-lived TCP connections to anycast servers might be disrupted due
   to routing changes.  Clients utilizing TCP for DNS need to always be
   prepared to re-establish connections or otherwise retry outstanding
   queries.  It might also be possible for Multipath TCP [RFC6824] to
   allow a server to hand a connection over from the anycast address to
   a unicast address.

IMO it doesn’t necessarily need to be repeated but there is probably no harm
in doing so if there is consensus it is a good idea.

> 
> -- Section 2.3 --
> To be honest, I smiled when reading "For example, as of 2014, DNS over TCP" in
> 2021 ;-)
> 
> -- Section 2.4 --
> The qualitative approach about IPv6 fragmentation makes me wonder about the
> sources of this paragraph.
> 
> Still about IPv6 fragmentation, while "hence is unable to fragment and re-send
> anyway" is most probably correct, the originating host should populate its 
> Path
> MTU cache for the destination. So, it is not that bad.

This section has been rewritten based on feedback from others and your
comment here.  Does this look better now?


   For IPv6, the situation is a little more complicated.  First, IPv6
   headers are 40 bytes (versus 20 without options in IPv4).  Second,
   approximately one third of DNS recursive resolvers use the minimum
   MTU of 1280 bytes [APNIC].  Third, fragmentation in IPv6 can only be
   done by the host originating the datagram.  The need to fragment is
   conveyed in an ICMPv6 "packet too big" message.  The originating host
   indicates a fragmented datagram with IPv6 extension headers.

   Unfortunately, it is quite common for both ICMPv6 and IPv6 extension
   headers to be blocked by middleboxes.  According to [HUSTON] some 35%
   of IPv6-capable recursive resolvers were unable to receive a
   fragmented IPv6 packet.  When the originating host receives a signal
   that fragmentation is required, it is expected to populate its Path
   MTU cache for that destination.  The application, then, will retry
   the query after a timeout since the host does not generally retain
   copies of messages sent over UDP for potential retransmission.

> 
> == NITS ==
> 
> -- Section 3 --
> While I appreciate 2nd degree, I wonder whether "serious" should really be 
> part
> of "Furthermore, there has been serious research"

Agreed. I’ve removed “serious”

> 
> -- Section 4.4 --
> Should the DoT acronym be used ?

My slight preference is to spell it out but I would defer to the working
group and the RFC editor.


DW

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

Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

[Wessels, Duane]

> On Nov 1, 2021, at 3:29 PM, Erik Kline  wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
>>> [S4.1, comment]
>>> 
>>> * "Resolvers and other DNS clients should be aware that some servers
>>>  might not be reachable over TCP.  For this reason, clients MAY want
>>>  to track and limit the number of TCP connections and connection
>>>  attempts to a single server."
>>> 
>>> I think the same comment could be made about paths to a server from
>>> a given network, e.g., in the case of one network filtering TCP/53 for
>>> some reason.
>>> 
>>> I'm not sure how to best reword this to add a per-network notion to
>>> TCP connection success tracking, but I did want to note that a mobile
>>> client's measure of TCP connection success to a single server might
>>> vary from network to network.  (for your consideration)
>> 
>> Is this because mobile devices are more likely to have multiple network 
>> choices (say wifi and cellular data) and so the device should include the 
>> local network when remembering which works and which doesn’t?
> 
> Yes, they have multiple networks simultaneously and also through time.
> What's reachable/unreachable on one network might not be
> reachable/unreachable on another.  Just moving from one Wi-Fi SSID to
> another can make a difference, e.g.:
> 
>* imagine two SSIDs that each hand out 8.8.8.8 but have different
> TCP 53 filtering policies, and
> 
>* (more concretely) I have DNS-over-TLS active on my phone and on
> one nearby coffee shop SSID TCP 853 is blocked while on another
> everything works just fine
> 
> (Hopefully I'm making some kind of sense.)

Thanks Erik, how does this look to you?

   Resolvers and other DNS clients should be aware that some
   servers might not be reachable over TCP.  For this reason, clients
   MAY track and limit the number of TCP connections and
   connection attempts to a single server.  Reachability problems
   can be caused by network elements close to the server, close
   to the client, or anywhere along the path between them.  Mobile
   clients that cache connection failures MAY do so on a per-network
   basis, or MAY clear such a cache upon change of network.

DW

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

Re: [DNSOP] Francesca Palombini's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

[Wessels, Duane]

Francesca, thank you for the review.

> On Oct 28, 2021, at 2:43 AM, Francesca Palombini via Datatracker 
>  wrote:
> 
> 
> 
> I only have one very minor comments, to take or leave as you please:
> 
>   headers are 40 bytes (versus 20 without options in IPv4).  Second, it
>   seems as though some people have misinterpreted IPv6's required
>   minimum MTU of 1280 as a required maximum.  Third, fragmentation in
> 
> FP: The "some people" is quite cryptic, in my opinion. What people? Does this
> come from analyzing implementations? Then it would probably be good to state 
> so
> instead.

Perhaps this is better?

   Second, it is common
   for IPv6-connected hosts to use the minimum MTU of 1280 bytes https://doi.org/10.23919/TMA.2018.8506538)

DW

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

Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

[Wessels, Duane]

Erik, thanks for the review

> On Oct 26, 2021, at 1:09 PM, Erik Kline via Datatracker  
> wrote:
> 
> 
> 
> --
> COMMENT:
> --
> 
> [abstract vs. S1/S3, question]
> 
> * The abstract says:
> 
>   "...strongly
>   encourages the operational practice of permitting DNS messages to be
>   carried over TCP"
> 
>  while section 1 says:
> 
>   "...all DNS resolvers and recursive
>   servers MUST support and service both TCP and UDP queries"
> 
>  and section 3 also some MUST text.
> 
>  Should the abstract be updated to say MUST rather than just
>  "strongly encourages", or is there a subtly in here I'm missing?

Based on the suggestion from Ben, we’ve updated the text:

  This document updates RFC 1123 and RFC 1536.  This
  document requires the operational practice of permitting
  DNS messages to be carried over TCP on the Internet as a Best
  Current Practice.  This operational requirement is aligned with the
  implementation requirements in RFC 7766.  The use of TCP includes



> [S4.1, comment]
> 
> * "Resolvers and other DNS clients should be aware that some servers
>   might not be reachable over TCP.  For this reason, clients MAY want
>   to track and limit the number of TCP connections and connection
>   attempts to a single server."
> 
>  I think the same comment could be made about paths to a server from
>  a given network, e.g., in the case of one network filtering TCP/53 for
>  some reason.
> 
>  I'm not sure how to best reword this to add a per-network notion to
>  TCP connection success tracking, but I did want to note that a mobile
>  client's measure of TCP connection success to a single server might
>  vary from network to network.  (for your consideration)

Is this because mobile devices are more likely to have multiple network choices 
(say wifi and cellular data) and so the device should include the local network 
when remembering which works and which doesn’t?

DW

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

Re: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Wessels, Duane]

Lars, thank you for the review.  

Some of your easier comments and suggestions have been addressed, but for some 
of them will require more thought and attention.  I am waiting to coordinate 
with my coauthor, and possibly the WG chairs.

> On Oct 26, 2021, at 4:35 AM, Lars Eggert via Datatracker  
> wrote:
> 
> 
> --
> COMMENT:
> --
> 
> Section 2.4. , paragraph 1, comment:
>> 2.4.  Fragmentation and Truncation
> 
> Fragmentation and IP fragments getting dropped is one reason for needing more
> retries with EDNS(0). But IIRC, a larger contributing factor is that EDNS(0)
> doesn't detect or recover from loss of any UDP packets making up the overall
> message. That means that a normal packet loss (due to congestion or other
> reasons) amplifies into loss of the entire DNS message.

How does this new paragraph look to you?

   Note that a receiver is unable to differentiate between packets
   lost due to congestion and packets (fragments) intentionally
   dropped by firewalls or middleboxes.  Over network paths with
   non-trival amounts of packet loss, larger, fragmented DNS responses
   are more likely to never arrive and time out compared to smaller,
   unfragmented responses.  Clients might be misled into retrying
   queries with different EDNS(0) UDP packet size values for the
   wrong reason.


> 
> 
> Found terminology that should be reviewed for inclusivity; see

Thanks, changed to primary and secondary.

> ---
> All comments below are about very minor potential issues that you may choose 
> to
> address in some way - or ignore - as you see fit.

These have all been accepted, except for the cases where we do intentionally 
refer to obsoleted RFCs.

DW


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

Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Wessels, Duane]

Hi Roman, thanks for the review.  My responses are inline.

> On Oct 25, 2021, at 3:02 PM, Roman Danyliw via Datatracker  
> wrote:
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This document has a dedicated section for DNS over TLS, makes a number of
> configuration recommendations for DoT, and notes it in the Privacy
> Considerations.  However, there is no mention of DNS over HTTPS (DoH).  It
> seems like DoH should get similar treatment.

Speaking only for myself, I am reluctant to include DoH in this draft.  I
feel that TCP and TLS are similar enough that it makes sense to cover both,
but DoH is quite a bit different.

If there is a concern that mentioning DoT is unfair and DoH should get
equal time then I would be in favor of discussing encrypted DNS transports
more generally, or perhaps even cutting back on encrypted transport
references.

But if Im in the minority here and the working group and IESG would like
to see DoH included then we can figure out what to say.

> 
> 
> --
> COMMENT:
> --
> 
> Thank you to Alan DeKok for the SECDIR review.
> 
> ** Section 2.2.
>   Yet, defying some expectations, DNS over TCP remained little-used in
>   real traffic across the Internet around this time.
> 
> This section doesn’t define a time period to associate with “… around this
> time”.

Does “…in the late 1990s” work for you?

> 
> ** Section 2.2.
>   Around the time
>   DNSSEC was first defined, another new feature helped solidify UDP
>   transport dominance for message transactions.
> 
> Is that “new feature” EDNS(0) per Section 2.3?

Yes, its a lead-in to the next section.  Do you think the text needs to be 
different here?


> 
> ** Section 2.5
>   Today, the majority of the DNS community expects, or at least has a
>   desire, to see DNS over TCP transactions occur without interference.
> 
> Is there a citation for this assertion?

How about the 2020 DNS flag day?  Https://dnsflagday.net/2020/


> 
> ** Section 2.5.  Per the use of [CHES94] and [DJBDNS] to motivate the position
> that DNS over TCP is not needed, are there more modern references?  The former
> is from 1994, and the latter appears to be last updated in 2002.

I’m not aware of any newer, better references.  It does show how long held 
these beliefs are.

> 
> ** Section 3.
>   Lastly, Section 1 of [RFC1536] is updated to eliminate the
>   misconception that TCP is only useful for zone transfers.
> 
> With what text is Section 1 of [RFC1536] updated?

I suppose my suggestion would be to strike this sentence:

   UDP is, therefore, the chosen protocol for communication
   though TCP is used for zone transfers.

Later in section 1 there is a "Since UDP is used," which could be changed
to "When UDP is used," if necessary.


> 
> ** Section 4.1.  Consider adding a reference of SYN cookies.

I added a reference to https://en.wikipedia.org/wiki/SYN_cookies

> 
> ** Section 5.1.  Does the term “DNS Wedgie” have to be used here given its use
> in American English as the name for a bullying practice?  Judging from a 
> google
> search (https://www.google.com/search?q="dns+wedgie;), this document appears 
> to
> be inventing the term in the context of DNS.

I’d like my coauthor John to chime in on this.

> 
> ** Section 6.  Per “Furthermore, as with real TCP, …”, what is “real TCP”?

Removed “as with real TCP”


> 
> ** Section 9.
>   Because TCP is somewhat more complex than UDP, some characteristics
>   of a TCP conversation may enable fingerprinting and tracking that is
>   not possible with UDP.
> 
> Recommend being clearer on who is being fingerprinted – s/fingerprinting/DNS
> client fingerprinting/

Done.


> 
> ** Section 9.  The text “DNS over TLS or DTLS is the recommended way to 
> achieve
> DNS privacy” seems rather soft on recommending encrypted DNS of any flavor. 
> Was there any WG conversation to same something stronger?

I do not recall any discussions like that, especially that werent incorporated
into the draft.

IMO making (stronger) recommendations about DNS privacy is starting to
stray from the purpose of this draft.



> 
> ** Section 9.  The text mentions that TCP is more susceptible to
> fingerprinting.  It would be also be worth mentioned that using DoH reduces
> susceptibility to traffic analysis.


This is tied to your DISCUSS point above.

DW


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

Re: [DNSOP] John Scudder's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

[Wessels, Duane]

> On Oct 28, 2021, at 7:16 AM, Roman Danyliw  wrote:
> 
> 
> [snip]
> 
>> 3. Section 6 says applications should perform “full TCP segment reassembly”.
>> What does that mean? A quick google search doesn’t suggest it’s a well-known
>> term of art. I'm guessing that what you mean is that the applications should
>> capture (and log, etc) the bytestream that was segmented and transmitted by
>> TCP?
> 
> I'll let the authors speak to this, but I think this means full TCP stream 
> reassembly -- that is analyze, the reassembled stream, not the individual 
> packets.  There is a long history of evasion attacks in network security 
> analysis tools when individual fragments/packets are analyzed instead of the 
> reassembled streams.
> 
> Roman


Thanks Roman, yes that is the intention.  “Segment reassembly” is poor phrasing.

I’ve seen (and probably even written) packet capture applications that only 
look at the first packet of a DNS over TCP conversation, or assumed that each 
TCP packet contains a separate DNS message.  This statement is directed at 
those types of shortcuts.

DW

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-13.txt

[Wessels, Duane]

This version of draft-ietf-dnsop-dns-tcp-requirements includes a number of 
changes made in response to GENART, SECDIR, ARTART, and TSVART reviews.  The 
notable changes are:

- added RFC 1536 as a document that this one updates

- new section 2.6. Reuse, Pipelining, and Out-of-Order Processing

- paragraph about tweaking parameters to deal with TIME_WAIT state is now much 
more conservative.  i.e. for experts only.

- new section 4.5. Defaults and Recommended Limits talks about recommended 
values for connection limits, timeouts, etc.

DW


> On Oct 13, 2021, at 4:21 PM, internet-dra...@ietf.org wrote:
> 
> 
> 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   : DNS Transport over TCP - Operational Requirements
>Authors : John Kristoff
>  Duane Wessels
>   Filename: draft-ietf-dnsop-dns-tcp-requirements-13.txt
>   Pages   : 33
>   Date: 2021-10-13
> 
> Abstract:
>   This document updates RFC 1123 and RFC 1536.  This document strongly
>   encourages the operational practice of permitting DNS messages to be
>   carried over TCP on the Internet as a Best Current Practice.  Such
>   encouragement is aligned with the implementation requirements in RFC
>   7766.  The use of TCP includes both DNS over unencrypted TCP, as well
>   as over an encrypted TLS session.  The document also considers the
>   consequences with this form of DNS communication and the potential
>   operational issues that can arise when this Best Current Practice is
>   not upheld.
> 



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-03.txt

[Wessels, Duane]

Dear DNSOP,

Changes to this draft from the previous version are as follows:
 
   *  Clarified scope to focus only on name server responses, and not
  zone/registry data.
   *  Reorganized with section 2 as Types of Glue and section 3 as
  Requirements.
   *  Removed any discussion of promoted / orphan glue.
   *  Use appropriate documentation addresses and domain names.
   *  Added Sibling Cyclic Glue example.

I'd say we still do not have consensus on treatment of sibling glue.  Section 
3.2 currently has the strict requirements with optional more lenient 
requirements in [square brackets]:

3.2.  Sibling Glue

   This document clarifies that when a name server generates a referral
   response, it MUST [SHOULD] include available sibling glue records in
   the additional section.  If all sibling glue records do not fit in a
   UDP response, the name server MUST [is NOT REQUIRED to] set TC=1.


DW


> On Oct 11, 2021, at 4:30 PM, internet-dra...@ietf.org wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> 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   : Glue In DNS Referral Responses Is Not Optional
>Authors : M. Andrews
>  Shumon Huque
>  Paul Wouters
>  Duane Wessels
>   Filename: draft-ietf-dnsop-glue-is-not-optional-03.txt
>   Pages   : 9
>   Date: 2021-10-11
> 
> Abstract:
>   The DNS uses glue records to allow iterative clients to find the
>   addresses of nameservers that are contained within a delegated zone.
>   Authoritative Servers are expected to return all available glue
>   records in referrals.  If message size constraints prevent the
>   inclusion of all glue records in a UDP response, the server MUST set
>   the TC flag to inform the client that the response is incomplete, and
>   that the client SHOULD use TCP to retrieve the full response.  This
>   document updates RFC 1034 to clarify correct server behavior.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-glue-is-not-optional-03.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-glue-is-not-optional-03
> 
> 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


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Tsvart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

[Wessels, Duane]

> On Sep 7, 2021, at 9:42 AM, Mirja Kuehlewind  wrote:
> 
> Thanks for the updates! One quick comment below.
> 
>> On 7. Sep 2021, at 18:23, Wessels, Duane  wrote:
>> 
>>> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker 
>>>  wrote:
>>> 
>>> And a more general comment on section 4.2: this section takes about various
>>> limits but doesn't recommend any values. I understand that there is not a
>>> one-fits-all solution here but not knowing how to set these values correctly
>>> might scared people aways from supporting TCP. So I think having a 
>>> discussion
>>> either of default values or how to derives these values based on a certain
>>> configuration would be a very valuable contribution in this document.
>> 
>> I've added some recommendations to the paragraphs in section 4.2.
>> 
>> For the limit on total number of connections: "Absent any other information,
>> 150 is a reasonable value for this limit in most cases."
>> 
>> For the limit on connections per source address: "Absent any other
>> information, 25 is a reasonable value for this limit in most cases."
>> 
>> For the timeout on idle connections: "Absent any other information, 10
>> seconds is a reasonable value for this timeout in most cases."
> 
> I think it would also make sense to explain a bit more why these values were 
> taken and what considerations/“other information" can be used to make a 
> different decisions. I know that might not be fully straight-forward but just 
> providing “random” numbers might also only provide limited value.
> 
> Mirja


Mirja,

I have gathered some information from the open source implementations and 
written a new section to talk about defaults and recommended values (below).  
The full document and diff from previous can be found in our github repo 
https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/tree/master/Versions

DW


4.5.  Defaults and Recommended Limits

   A survey of features and defults was conducted for popular open
   source DNS server implementations at the time of writing.  This
   section documents those defaults and makes recommendations for
   configurable limits that can be used in the absence of any other
   information.  Any recommended values in this document are only
   intended as a starting point for administrators that are unsure what
   sorts of limits might be reasonable.  Operators SHOULD use
   application-specific monitoring, system logs, and system monitoring
   tools to gauge whether their service is operating within or exceeding
   these limits, and adjust accordingly.

   Most open sorcue DNS server implementations provide a configurable
   limit on the total number of established connections.  Default values
   range from 20 to 150.  In most cases, where the majority of queries
   take place over UDP, 150 is a reasonable limit.  For services or
   enviroments where most queries take place over TCP or TLS, 5000 is a
   more appropriate limit.

   Only some open source implementations provide a way to limit the
   number of connections per source IP address or subnet, but the
   default is to have no limit.  For environments or situations where it
   may be neccessary to enable this limit, 25 connections per source IP
   address is a reasonable starting point.  The limit should be
   increased when aggregated by subnet, or for services where most
   queries take place over TCP or TLS.

   Most open source implementations provide a configurable idle timeout
   on connections.  Default values range from 2 to 30 seconds.  In most
   cases, 10 seconds is a reasonable default for this limit.  Longer
   timeouts improve connection reuse, but busy servers may need to use a
   lower limit.

   Only some open source implementations provide a way to limit the
   number of transactions per connection, but the default is to have no
   limit.  This document does not offer advice on particular values for
   such a limit.

   Only some open source implementations provide a way to limit the
   duration of connection, but the default is to have no limit.  This
   document does not offer advice on particular values for such a limit.



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Artart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

[Wessels, Duane]

> On Sep 3, 2021, at 5:29 PM, Jean Mahoney via Datatracker  
> wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> Reviewer: Jean Mahoney
> Review result: Ready with Nits
> 
> Reviewer: Jean Mahoney
> Review result: Ready with nits
> 
> A well-written, easy-to-read document.  Love Appendix A!

Jean,

Thank you for the review and kind words.

> 
> Question about Appendix A.2 and Updates - Should this document also update RFC
> 1536?
> 
> Current text in A.2:
>   The informational document [RFC1536] states UDP is the "chosen
>   protocol for communication though TCP is used for zone transfers."
>   That statement should now be considered in its historical context and
>   is no longer a proper reflection of modern expectations.

Seems reasonable to consider, assuming a BCP can update an Informational RFC?



> 
> Nits:
> 
> General - Document status (Informational, Standards Track, etc.) should be
> capitalized, and Standards Track is not hyphenated (There's just one instance
> of hyphenation).
> 
> Section 2.4 - 35%of / 35% of

There is an embedded XML comment in the source and apparently it renders 
inconsistently.
I've added more whitespace so it should be fixed regardless.

> 
> Section 3 - transport.[TDNS] / transport [TDNS].

Fixed.

> 
> Section 5.1
>   Current: "the steady-state of lost resources as a result is a 'DNS wedgie'."
>   Perhaps: "the steady state of the resulting lost resources is a 'DNS
>   wedgie'."

Yes, thank you.

> 
> Section 5.2 - Expand the acronym KSK.

Done.


> 
> Section 7 - The Acknowledgments section should be located just above the
> Authors' Addresses section. It looks like the names are supposed to be in
> alphabetical order, but they aren't quite.

I moved it to the end of  in the XML source.


> 
> Section 9 - fragmenetation / fragmentation

Fixed.


> 
> Section 10 -  Since DNS over UDP and TCP use  / Since DNS over UDP and TCP 
> uses

Fixed.


> 
> Section 11.2 - [ROLL_YOU_ROOT] has a mangled author name and a TBD.

The TBD is fixed.  The author names look fine to me, but maybe "Mller" 
isn't
rendering properly for everyone?  If thats not it then I'll need you to be more
specific.




> 
> Appendix A - The construction "The [RFC] document..." (in A.3, A.4, A.5,
> A.7, and A.13) reads oddly to me. Perhaps "This document [RFC] ".

Agreed.  These have been changed.

> 
> Appendix A.8 - The verb tenses are mixed in this section.

Fixed.


> 
> Appendix A.32 - as a a / as a

Fixed.


> 
> There are other nits I could pick more easily if this doc was in a GitHub 
> repo.
> They can be left to the RPC to clean up. :-)


FYI it is in github and I have a pull request for your review at 
https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/pull/8

DW



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

[Wessels, Duane]

Dan, thanks for the review.  Responses are inline.



> On Sep 1, 2021, at 3:12 AM, Dan Romascanu via Datatracker  
> wrote:
> 
> 
> Minor issues:
> 
> 1. In Section 4.1:
> 
>> DNS clients MAY also enable TFO when possible.
> 
> Maybe I do not fully understand the intent here, but 'MAY ... when possible'
> sounds like a SHOULD to me.


Originally this was "SHOULD ...  when possible" (meaning when
implemented/supported) but after conversations with tcpm this was changed
to MAY.  To avoid confusion with "when possible" I suggest we just drop
it so it will just say "DNS clients MAY also enable TFO."



> 
> 2.In Section 4.2
> 
>>  DNS server software SHOULD provide a configurable limit on the total
>   number of established TCP connections.  If the limit is reached, the
>   application is expected to either close existing (idle) connections
>   or refuse new connections.  Operators SHOULD ensure the limit is
>   configured appropriately for their particular situation.
> 
>   DNS server software MAY provide a configurable limit on the number of
>   established connections per source IP address or subnet.  This can be
>   used to ensure that a single or small set of users cannot consume all
>   TCP resources and deny service to other users.  Operators SHOULD
>   ensure this limit is configured appropriately, based on their number
>   of diversity of users.
> 
> The lack of recommendations about how these limits should be set would leave
> less experienced operators in the dark. There is not even a sentence like 
> 'This
> document does not offer advice on particular values for such a limit' as for
> other parameters in the same section. From an operators point of view I would
> prefer a recommendation or one or more examples of how these limits can be set
> in real life cases.

Other reviewers called this out as well so I have added some recommended values.

For the limit on total number of connections: "Absent any other information,
150 is a reasonable value for this limit in most cases."

For the limit on connections per source address: "Absent any other
information, 25 is a reasonable value for this limit in most cases."

For the timeout on idle connections: "Absent any other information, 10
seconds is a reasonable value for this timeout in most cases."


> 
> Nits/editorial comments:
> 
> 1. Sections in the document that are obviously for informational pursposes
> should be clearly marked so (like 'This section is included for informational
> purposes only'). For example Section 2.

Done.


> 
> 2. In Section 3:
> 
> Regarding the choice of limiting the resources a server devotes to
>   queries, Section 6.1.3.2 in [RFC1123] also says:
> 
>  "A name server MAY limit the resources it devotes to TCP queries,
>  but it SHOULD NOT refuse to service a TCP query just because it
>  would have succeeded with UDP."
> 
>   This requirement is hereby updated: A name server MAY limit the
>   resources it devotes to queries, but it MUST NOT refuse to service a
>   query just because it would have succeeded with another transport
>   protocol.
> 
> Similar alignment of the old and new text is desirable. Even using the OLD /
> NEW format.

Good point.  Section 3 now looks like this:

   Section 6.1.3.2 in [RFC1123] is updated: All DNS resolvers and
   servers MUST support and service both UDP and TCP queries.

   o  Authoritative servers MUST support and service all TCP queries so
  that they do not limit the size of responses to what fits in a
  single UDP packet.

   o  Recursive servers (or forwarders) MUST support and service all TCP
  queries so that they do not prevent large responses from a TCP-
  capable server from reaching its TCP-capable clients.

   Furthermore, the requirement in Section 6.1.3.2 of [RFC1123] around
   limiting the resources a server devotes to queries is hereby updated:

   OLD:

  A name server MAY limit the resources it devotes to TCP queries,
  but it SHOULD NOT refuse to service a TCP query just because it
  would have succeeded with UDP.

   NEW:

  A name server MAY limit the resources it devotes to queries, but
  it MUST NOT refuse to service a query just because it would have
  succeeded with another transport protocol.



FYI we are tracking this in github at 
https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/pull/4/files
 if that is helpful.

DW



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Tsvart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

[Wessels, Duane]

> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker 
>  wrote:
> 
> 
> 
> First a minor comment here:
> "TCP connection timeout, which is often around 60-120 seconds."
> I guess this value relates to an RTO of 1s and 6 SYN retries which is the
> default in Linux. Maybe say that...? I also recommend to add a link to 
> RFC6298.

I've made this addition to the paragraph in section 4.1:

   ... rather than
   rely on the host operating system's TCP connection timeout, which is
   often around 60-120 seconds (i.e., due to an initial retransmission
   timeout of 1 second, the exponential back off rules of [RFC6298], and
   a limit of six retries as is the default in Linux).


> 
> And a more general comment on section 4.2: this section takes about various
> limits but doesn't recommend any values. I understand that there is not a
> one-fits-all solution here but not knowing how to set these values correctly
> might scared people aways from supporting TCP. So I think having a discussion
> either of default values or how to derives these values based on a certain
> configuration would be a very valuable contribution in this document.

I've added some recommendations to the paragraphs in section 4.2.

For the limit on total number of connections: "Absent any other information,
150 is a reasonable value for this limit in most cases."

For the limit on connections per source address: "Absent any other
information, 25 is a reasonable value for this limit in most cases."

For the timeout on idle connections: "Absent any other information, 10
seconds is a reasonable value for this timeout in most cases."


> 
> Similarly section 4.3 talks about tuning net.ipv4.tcp_fin_timeout, however, it
> doesn't provide any guidance on how to tune it; Linux recommend a value of
> 15-30 seconds. Also setting net.ipv4.tcp_fin_timeout to a too low value and
> net.ipv4.tcp_tw_reuse to 1 can cause trouble and should not be done for the
> general case. So I don't think that guidance is appropriate without further
> discussion of the risks. Please reconsider this part of the document!

This paragraph in section 4.3 has been rewritten:

   On systems where large numbers of sockets in TIME_WAIT are observed
   (either as client or server), and are affecting an application's
   performance, it may be tempting to tune local TCP parameters.  For
   example, the Linux kernel has a "sysctl" parameter named
   net.ipv4.tcp_tw_reuse which allows connections in the TIME_WAIT state
   to be reused in specific circumstances.  Note, however, this affects
   only outgoing (client) connections and has no impact on servers.  In
   most cases it is NOT RECOMMENDED to change parameters related to the
   TIME_WAIT state.  It should only be done by those with detailed
   knowledge of both TCP and the affected application.



> On section 4.4, maybe mention TCP fast open here again as well?
> 

It now reads:

   Unoptimized connection
   setup takes two additional round-trips compared to TCP, but can be
   reduced with TCP Fast Open, TLS session resumption [RFC8446] and TLS
   False Start [RFC7918].



FYI We're tracking these changes in github at 
https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/pull/5 if 
that is helpful.

DW



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Tsvart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

[Wessels, Duane]

> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker 
>  wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> Reviewer: Mirja Kühlewind
> Review result: Ready with Issues

Hello Mirja,

Thanks for the review.  I haven't had a chance yet to discuss with my
coauthor, John, so these are just my own thoughts at this point.


> 
> 
> First a minor comment here:
> "TCP connection timeout, which is often around 60-120 seconds."
> I guess this value relates to an RTO of 1s and 6 SYN retries which is the
> default in Linux. Maybe say that...? I also recommend to add a link to 
> RFC6298.

Yes suppose it does relate to RTO and SYN retry values, although I'm not
too sure how much those details matter to the intended audience of this
document (DNS software operators).  It says "60-120 seconds" just based
on general experience of how long connection timeouts usually take, without
understanding the inner workings of TCP.

I searched a little for something we could cite to support the 60-120 seconds
statement, but didn't really find anything.  If you think we should use RFC 6298
and the values from Linux to support that, then I guess its fine.

> 
> And a more general comment on section 4.2: this section takes about various
> limits but doesn't recommend any values. I understand that there is not a
> one-fits-all solution here but not knowing how to set these values correctly
> might scared people aways from supporting TCP. So I think having a discussion
> either of default values or how to derives these values based on a certain
> configuration would be a very valuable contribution in this document.

Do you think it would suffice to provide a range of recommended values?
I think we'd have to go back to the working group to get consensus.

Alternatively, are you suggesting to document what defaults are in current
implementations?


> 
> Similarly section 4.3 talks about tuning net.ipv4.tcp_fin_timeout, however, it
> doesn't provide any guidance on how to tune it; Linux recommend a value of
> 15-30 seconds. Also setting net.ipv4.tcp_fin_timeout to a too low value and
> net.ipv4.tcp_tw_reuse to 1 can cause trouble and should not be done for the
> general case. So I don't think that guidance is appropriate without further
> discussion of the risks. Please reconsider this part of the document!


I see your concern.  Would it be okay if we say here that these are for
experts only?  e.g. the sysctl values should only be changed by someone
that has detailed understanding of how TCP works and really understands
the consequences of tweaking them?


> 
> On section 4.4, maybe mention TCP fast open here again as well?
> 

Ack, will do.

DW




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] AD review: draft-ietf-dnsop-dns-tcp-requirements

[Wessels, Duane]

Thanks Warren, I made all of your proposed changes.  Here's a rewrite of the 
DNS wedgie paragraph:

   Networks that filter DNS over TCP may inadvertently cause problems
   for third-party resolvers as experienced by [TOYAMA].  For example, a
   resolver receives queries for a moderately popular domain.  The
   resolver forwards the queries to the domain's authoritative name
   servers, but those servers respond with the TC bit set.  The resolver
   retries over TCP, but the authoritative server blocks DNS over TCP.
   The pending connections consume resources on the resolver until they
   time out.  If the number and frequency of these truncated-and-then-
   blocked queries is sufficiently high, the steady-state of lost
   resources as a result is a "DNS wedgie."  A DNS wedgie is generally
   not easily or completely mitigated by the affected DNS resolver
   operator.


DW


> On Jul 14, 2021, at 2:36 PM, Warren Kumari  wrote:
> 
> 
> Hi there authors (and WG),
> 
> Firstly, thank you very much for this document -- I think that it's a
> useful document, although I'm a bit sad that it's needed :-)
> 
> I do have a number of editorial comments/ nits. Addressing these
> before IETF LC and IESG review should make progressing the document
> easier and smoother...
> 
> 
> 2.  History of DNS over TCP
> 
>   The curious state of disagreement in operational best practices and
> [O] disagreement in operational best practices
> [P] disagreement between operational best practices
> [R] clarity — I *think* this is what’s meant?
> 
>   guidance for DNS transport protocols derives from conflicting
>   messages operators have gotten from other operators, implementors,
>   and even the IETF.  Sometimes these mixed signals have been explicit,
>   on other occasions they have been suspiciously implicit.  This
> [O] explicit,
>   on other occasions they have been suspiciously implicit.
> [P] explicit; on other occasions, conflicting messages have been implicit.
> [R] semicolon for grammar (otherwise it’s a run on sentence). Consider
> dropping “suspiciously” — feels odd/awkward in this context.
> 
> Section 2.2
> "[...] it is also clear that some new DNS record types defined in
>  the future will contain information exceeding the 512 byte limit
>  that applies to UDP, and hence will require TCP.
> [R]: Nit - please add closing quote...
> 
> 
> 
> Section 2.3.
> EDNS(0) became widely deployed over the next
>   several years and numerous surveys ([CASTRO2010], [NETALYZR]) have
> [O] several years and numerous surveys
> [P] several years, and numerous surveys
> [R] grammar
> 
> While a non-negligible population of DNS systems lacked
>   EDNS(0) or fell back to TCP when necessary, DNS clients still
>   strongly prefer UDP to TCP.  For example, as of 2014 DNS over TCP
> 
> [O] For example, as of 2014 DNS
> [P] For example, as of 2014, DNS
> [R] clarity
> 
> 
> Section 2.4. Fragmentation and Truncation
> 
>   For IPv6, the situation is a little more complicated.  First, IPv6
>   headers are 40 bytes (versus 20 without options in IPv4).  Second, it
>   seems as though some people have mis-interpreted IPv6's required
> 
> [O] mis-interpreted
> [P] misinterpreted
> 
> 
> 2.5.  "Only Zone Transfers Use TCP"
> 
> "A popular meme has also held the imagination of some: that
> DNS over TCP is only ever used for zone transfers and is generally
>   unnecessary otherwise, with filtering all DNS over TCP traffic even
>   described as a best practice."
> [R]: I find the phrasing of this odd -- do memes hold people's
> imagination? Perhaps just "A popular meme is..."? Or even "Many people
> erroneously believe ..." ?
> 
> 
> However modern
>   standards and implementations are nearing parity with the more
> 
> [O] However modern
> [P] However, modern
> [R] grammar/readability
> 
>   sophisticated TCP management techniques employed by, for example,
>   HTTP(S) servers and load balancers.
> 
> 3.  DNS over TCP Requirements
> 
>   An average increase in DNS message size (e.g., due to DNSSEC), the
>   continued development of new DNS features (Appendix A), and a denial
>   of service mitigation technique (Section 9) show that DNS over TCP
> 
> [O] (Section 9) show that DNS
> [P] (Section 9), all show that DNS
> [R] readability
> 
> 
> 4.2.  Connection Management
> 
> This can be used to ensure that a single or small set of users can
> not consume ...
> [O] can not
> [P] cannot
> [R] spelling/clarity
> 
> 5.  DNS over TCP Filtering Risks
> 
> Therefore, filtering of DNS over TCP is considered harmful
>   and contrary to the safe and successful operation of the Internet.
>   This section enumerates some of the known risks known at the time of
> [O] known risks known at the time
> [P] known risks as of the time
> [R] readability
> 
>   this writing when networks filter DNS over TCP.
> 
> 
> 5.1.  DNS Wedgie
> 
> [O] If, for
>   instance, a resolver receives a truncated answer from a server, but
>   when the resolver resends the query using 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-11.txt

[Wessels, Duane]

This revision only addresses a small number if "idnits".

DW


> On Jun 11, 2021, at 9:59 AM, internet-dra...@ietf.org wrote:
> 
> 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   : DNS Transport over TCP - Operational Requirements
>Authors : John Kristoff
>  Duane Wessels
>   Filename: draft-ietf-dnsop-dns-tcp-requirements-11.txt
>   Pages   : 29
>   Date: 2021-06-11
> 
> Abstract:
>   This document updates RFC 1123.  This document strongly encourages
>   the operational practice of permitting DNS messages to be carried
>   over TCP on the Internet as a best current practice.  Such
>   encouragement is aligned with the implementation requirements in RFC
>   7766.  The use of TCP includes both DNS over unencrypted TCP, as well
>   as over an encrypted TLS session.  The document also considers the
>   consequences with this form of DNS communication and the potential
>   operational issues that can arise when this best current practice is
>   not upheld.
> 
> 
> The IETF datatracker status page for this draft is:
> https://secure-web.cisco.com/1RE6fQUuvtSZ2X0Zb8xcfK_QIZdZfvqljj_6qtwqxGL7XLvsRizHB9U3EzKWzyoJLoszV_KRtkEeQUY_0yzXsoxWWem6nFtOs99iRB1N_fBTNL5VBZLluEd7Cl9qVAD4g_w6uLMphh9QLC8OyWJ3d4Ag-oaCbIMioWj6s24lOsYS15ZurckwYMqPOd6cf4Joxv4SVfGpLp4dTRt4Q2D1syXUYYZtsVl4rewiAqr6gqbuU4NbcGYhE0QIA8mnvI7-iM1lUg2Tn0ghSb3xbifmcyw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-tcp-requirements%2F
> 
> There is also an htmlized version available at:
> https://secure-web.cisco.com/1kNznSgDdoHwcRaNaRjaNunvs1P1wDkEer6GcCFahtdiZpMgQlniHJrzjUV58Y04P4TVm1knncbsz8VC0vpAJjw1r_T51tjtzo3he5XrElgmpU11lV0BEJpksjv0ad41ckS7LnvvQm6fcomurbskg_viOP_gYr1l2bsiAj-ICXvRBTfx5DtdC6OsAHUiVHU1QgY3KzwbhbWTT3qJlGXHU7fXMMH_7uTWEqNu-J6ICxDv_G0ickIORYlJYADPm2R_ValL5VG2A4Dgya5yDr4fw_g/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dnsop-dns-tcp-requirements-11
> 
> A diff from the previous version is available at:
> https://secure-web.cisco.com/19Dzi2SMoWhzbWqXtjZWui-PixaooUh6g9RRDNm1SUnxyJ1OVYjRKWN9KH9z6fJFo2S6HD_3Z3EJBmeM9_NBwizH3ivW_6MsZ190mSsk5PVs9L6vKD9f6NCjLjTn4PaD_Ad2JzeRRC6qb13ZOJg29GSC-eknDxl09ggCv0WGVl6MzOq02zCRHoKODEh3wWymoVz5-6kyHMNCOg9U6-KLU4amk3krqhhNhzupkhsrbF8HUK-MPLLopR_ZZmb4XuPq6PjG2-wGh2cHI3Q5lT8trTw/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-dnsop-dns-tcp-requirements-11
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/1z5DL3clRsx7nBSMZ9Naq2zUx2aF20RiuWdd6iWpE2w1qP-F2yZSpcWVQdsCQbK2ETAIYfmxZUTvmV92FAM3acQD51E6YOFwwxL32IkJTpSpeHGGNp_3RRwoV6vIpOvJIMyyYFvHdQLYwhJ7K4F9tQiCCdVfA_A-N9a6oLwRePoQCLD_0nmM4QnbZcdKyc4KN68ZjEbMQYPbJqAUlu7aJOKo9XFWmPeMfXVzUeFTHwcPXCApf6zbISm0cGEoBylo--oAGNRRlUeturP_xw4XiWw/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop
> 



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-10.txt

[Wessels, Duane]

Dear DNSOP,

John and I have made a number of changes since the start of Working Group Last 
Call, thanks to your good feedback.  Here's a summary of the noteworthy changes 
since -06:

- The abstract emphasizes this document speak to operational requirements, in 
alignment with previously documented implementation requirements.

- Noted that this document updates RFC 1123

- Background section has been renamed to History of DNS over TCP

- Updated and clarified text on connection termination

- An earlier version mistakenly assumed that OpenBSD had the TCP "accept 
filter" feature

- EDNS(0) everywhere, instead of just EDNS

- Have added a few new or missing references to BIND, ECDSA, flag day 2020, and 
the KSK rollover list archives.

- Numerous updates to RFC references, including newly published RFCs and cases 
where some RFCs have new revisions published.  Also a number of RFC references 
were moved to the Normative section.

- Numerous other grammatical and typographical fixes

DW




> On Jun 8, 2021, at 4:10 PM, internet-dra...@ietf.org wrote:
> 
> 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   : DNS Transport over TCP - Operational Requirements
>Authors : John Kristoff
>  Duane Wessels
>   Filename: draft-ietf-dnsop-dns-tcp-requirements-10.txt
>   Pages   : 29
>   Date: 2021-06-08
> 
> Abstract:
>   This document updates [RFC1123].  This document strongly encourages
>   the operational practice of permitting DNS messages to be carried
>   over TCP on the Internet as a best current practice.  Such
>   encouragement is aligned with the implementation requirements in RFC
>   7766.  The use of TCP includes both DNS over unencrypted TCP, as well
>   as over an encrypted TLS session.  The document also considers the
>   consequences with this form of DNS communication and the potential
>   operational issues that can arise when this best current practice is
>   not upheld.
> 
> 
> The IETF datatracker status page for this draft is:
> https://secure-web.cisco.com/1Bt7uhovzfR-wXjPaS77JXhiNYAC3cbTLqKixLUer9be_snyAstM0vO7rbd-6tg1Af61WLfqMhmR6MVawQMyXSLUEvl0DDSRcPcGuyxR0DfQH5H1-kZ6dhoIrR03PqTyQi3sAPPE6MBNB866JcgyCfnKv7584QTS5Jn_PmyWhj4kZv-uLSWOYXn8yeY1J9dux9Tn-zR_72iBbLfxuN0DTm4R5rogWbVnF-09IUGVZim3fvZfuBJ6jxXNDkiM2XTUFlydxiUMOb96Sm7jng3ehyg/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-tcp-requirements%2F
> 
> There is also an htmlized version available at:
> https://secure-web.cisco.com/1kg3laQW73wmvxjmh3LHKPs8xTRL21Z8-8IsCg_LPFAwxpClKj5biuDi-KlWiOC4Fif8tl0V8GDQ42lYNX11vP-I18i5V8ywRYcweAMWL8D_8YyN6_WGgY2dWQvixDVv6AgA5A5mx_zx_LRNkTgrwokfiZjRkkDUFt7cvW6OizkTZE_MrZQbzUhAqaSzG_RH2qSx_Gjb2QYdcva1jZUArM1hJJQBk6zHznsMlqj1IqVShVtLC_o0wj79hWFYGDwzcuWBQgFHB_go1c8iIO0wFKA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dnsop-dns-tcp-requirements-10
> 
> A diff from the previous version is available at:
> https://secure-web.cisco.com/1n2z0gdPQvBFXazUbuwAkdVKLpzonHFKEqoPxbKuRCbnnqpluK3jeD0GmEy7EJinDCyKq6igwKrrmBzN77pynAgoRZRlaBSZh_DBffQQvgBPQp7oIjYftnLaBi98As0subHJYiUb2CyjeLCMHU3Pv8lQu3GlEKuFpvBZ9T5ZpIYwMyEVI6OdqZgGf7SIJWTOVBSH3tkSG53_yyD8bEsEIU7RHovBWnugdfFnQg5DQdqGBvoWiju0eLc14terdNJ-olPur3PGX8Pxe5uUS5H3nNQ/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-dnsop-dns-tcp-requirements-10
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/1atzUJwMeKlqFcZqpVfe8Y-YVhu0kYAZKSSZnLcQDJARLtFm--_PO-Fkny_8v_OaS_gx_xyLPn6t0B4C4zy7aZTik0WB0it44p4Gt3-ONgGe3E4KPY__3excCeCkkuZDE3ri7i246Mv9OjdthuvztVOvZih-Up5uIfkpaZUE5d6bYXpvTt8nUFPVbEG4L5470k8zF7qeYNs658KGsV0mMcokaG9lkQBtr-7wsY3tVPuYqpXj3TdTvTnl7CeFurE0GWLC83zGaYkYY7rQM5-tVYQ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop
> 



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] ZONEMD was Re: [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Wessels, Duane]

> On May 10, 2021, at 5:44 PM, Mark Andrews  wrote:
> 
> 
>> On 11 May 2021, at 09:20, Paul Hoffman  wrote:
>> 
>> On May 10, 2021, at 4:14 PM, Mark Andrews  wrote:
>>> Actually, the process problem is that record format keeps changing AFTER 
>>> the code point has been assigned and the record format THEORETICALLY been 
>>> FIXED.
>> 
>> Mark makes an excellent point, one that people in the DNS world routinely 
>> forget.
> 
> Just for reference ZONEMD switched two fields between 
> draft-wessels-dns-zone-digest-05.txt and
> RFC 8976.  "Digest Type | Reserved” -> "Scheme | Hash Algorithm”.  This 
> resulted in BIND rejecting
> zones with ZONEMD records using SHA-512 digests (digest field has the wrong 
> length for Digest Type 1).
> Renaming fields is fine.  Reordering/repurposing non reserved isn’t as it 
> breaks stuff.  Now we are
> making BIND compatible with RFC 8976 but we should never have been put in 
> this position.

Mark,

Thank you for quickly making this change in BIND.  You are correct that
the case of ZONEMD the interpretation of fields did change, although the
wire format did not.

You've made the point a few times that code point allocation freezes the
record format (not just in wire format but also presentation and meaning).
When I went through the RR type allocation process this was not evident
to me.  Is this (theoretical?) "policy" written down somewhere?  RFC 6895
doesn't seem to say anything like that.

DW





smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Wessels, Duane]

> On Apr 22, 2021, at 11:50 AM, Donald Eastlake  wrote:
> 
> 
> Hi,
> 
> This is a good document and I support publication.
> 
> However, I do have some comments. I scanned the Last Call comments by
> others, and they mostly seem like improvements, but some of my
> comments below may duplicate others for which I apologize in advance.
> 
> 
> Section 3, last paragraph: Cut out wishy-washy superfluous words. Be bold!
> OLD
> vice-versa.  However, it is the aim of this document to argue that
> BETTER
> vice-versa.  However, this document argues that
> BEST
> vice-versa.  However,

Done!

> 
> 
> Although Cookies are mentioned in this draft with a reference to the
> RFC 7873, it would be good to work in the point that the Cookies RFC
> recommends use of TCP whenever Cookies are not available as a way to
> get some of the benefits of Cookies. Thus, if I remember correctly,
> someone following that RFC would use Cookies or, when they are not
> available, TCP.

The appendix entry for RFC 7873 said:

[RFC 7873] mentions DNS over TCP as a reasonable fallback mechanism when 
DNS Cookies
are not available.

The phrase "reasonable fallback" doesn't sit quite right with me so I changed 
it to
"...as an alternative mechanism...".  Does that work for you or were you 
suggesting
that this point be made in the body of the document rather than only in the 
appendix?



> 
> Section 9, last paragraph: Don't be so negative :-)
> "not unlike" -> "similar to"

Done.

> 
> 
> Make the name of Section 2 a bit more explicit, something like
> "History of DNS over TCP"

Yes, done.


> 
> 
> Section 1.1: Update as per RFC 8174.

Done.

> 
> 
> Lots of references are good but I find it disturbing that all
> technical references are shown as Informational. I think a lot of them
> should be moved to Normative.

I wondered about that as well.  I moved many of the standards track RFCs to the 
normative section.  I will highlight this change when the next version is 
posted and I hope someone lets us know if any of those are not appropriate 
there.

DW




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Wessels, Duane]

> On Apr 21, 2021, at 4:39 PM, Wessels, Duane 
>  wrote:
> 
>> 2.2:
>> 
>>  DNSSEC originally specified in [RFC2541]
>> 
>> I thought this should be RFC 2535 rather than the operational guidelines?
> 
> Sure, 2535 works for me.
> 

Oops, correcting myself here.  It needs to be RFC 2541 because that is the
one that mentions TCP.  The text has been updated like this:

   and the second was the set of extensions
   collectively known as DNSSEC, whose operational considerations are
   originally given in [RFC2541]....while the latter
   warned "... larger keys increase the size of KEY and SIG RRs.  This
   increases the chance of DNS UDP packet overflow and the possible
   necessity for using higher overhead TCP in responses."


DW



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Wessels, Duane]

> On Apr 19, 2021, at 9:34 AM, Peter van Dijk  
> wrote:
> 
>> This message starts the Working Group Last Call for 
>> draft-ietf-dnsop-tcp-requirements 
>> (https://secure-web.cisco.com/1GUztR-Nd5B-MpjncjmDNOnqlKoeK5-09UeTvbL1dFyQqc0x3GpwWIzNUMvS9B4MsWztiWQY9T4fEg5m6LLL1pIw6mIP3Glh5Dv0eS5QuBH0_Er0tAvzCWC4zQmflkrgxR33_ZI_bjrpDA44xWmAs5GaN2Xu6HgIlfNUxBYXJzJjwsgJ_xviwCeTT7debqaByK_Oko0XxsVpateA6jVRS5dByfqyYMX03JeB_kJbfBGxtfsoWTcBVWSYTpsCG7_KrY8EWi3H9J7_369rrwCogbQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-tcp-requirements%2F)
> 
> This is a good document.
> 
> One comment here:
> 
>   The FreeBSD, OpenBSD, and NetBSD operating systems have an "accept
>   filter" feature ([accept_filter]) that postpones delivery of TCP
>   connections to applications until a complete, valid request has been
>   received.  The dns_accf(9) filter ensures that a valid DNS message
>   is received.  If not, the bogus connection never reaches the
>   application.  Applications must be coded and configured to make use
>   of this filter.
> 
> While it's good to point out that this feature exists, I do not think
> mandating it makes sense - implementers and operators might have other
> preferences for handling open-but-as-yet-unused TCP connections. (Also
> the lowercase 'must' is confusing.)

It was not intended as a requirement, but rather to note that the application 
needs to do some work to utilize them.  Hows this?

   These features are implemented as low-level socket options.
   It is necessary for applications to be specifically coded and
   configured to make use of them.


> Suggested extra text:
> 
>> The Linux TCP_DEFER_ACCEPT feature, while more limited in scope, can
> provide some of the same benefits as the BSD accept filter feature.

Added, thanks.

DW




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Wessels, Duane]

> On Apr 19, 2021, at 8:45 AM, Tony Finch  wrote:
> 
> Suzanne Woolf  wrote:
>> 
>> This message starts the Working Group Last Call for
>> draft-ietf-dnsop-tcp-requirements
> 
> I have read the draft and I am keen to see it published. Just the other
> day I was having a discussion about whether TCP support is really needed,
> and I wanted something stronger than RFC 7766 to point to.
> 
> The draft is readable and comprehensive. I like it.
> 
> Some minor and pedantic nits:
> 
> 2.2:
> 
>   DNSSEC originally specified in [RFC2541]
> 
> I thought this should be RFC 2535 rather than the operational guidelines?

Sure, 2535 works for me.


> 
> 2.3:
> 
>   This unsigned 16-bit field specifies, in bytes, the maximum
>   (possibly fragmented) DNS message size a node is capable of
>   receiving.
> 
> I suggest adding "over UDP" to the end of the sentence (since the EDNS
> buffer size doesn't restrict messages over other transports).

Done.


> 
> 2.4:
> 
> Last 2 paragraph s re. avoiding fragmentation, it might be worth
> suggesting minimal-any [RFC 8482].

I did add 8482 to the Appendix as you also suggested below.  I'm a little 
reluctant to
add a reference in section 2.4 since I think the primary motivation for 8482 
was about
DDoS amplification, rather than fragmentation.   But I could still be convinced 
otherwise.



> 
> 4.3:
> 
>   the Linux kernel provides a number of "sysctl" parameters related to
>   TIME_WAIT, such as net.ipv4.tcp_fin_timeout, net.ipv4.tcp_tw_recycle,
>   and net.ipv4.tcp_tw_reuse.
> 
> I believe that net.ipv4.tcp_tw_recycle is problematic and has been removed
> https://secure-web.cisco.com/1zq_T2G9VjiDGyCD0UqiwfZ7i0Jc_JcoiRaUvHdWj_Nfh6pjxxQygRKERClmruWq9Yie54GznGNn-TR0ijjBYdidyWjP-mbPF5EWAwdDtalD86OTC3Z--zQWHcwkJtpdtD_iHBJqo4tRAddX5cQM8cJpMFTDMKKcXx-upQpjW14N1FwLeCniHz9apzZbWcIvZ_xlx3UDB4cvVJmNXzOZni24brGiihUnUPzUOipM8mAlwkq7ZuVgFJYRfKCc4DjCjiBYP9m5stLbRNYinc72Nlw/https%3A%2F%2Fvincent.bernat.ch%2Fen%2Fblog%2F2014-tcp-time-wait-state-linux%23netipv4tcp_tw_recycle

I removed tcp_tw_recycle.

> 
> 4.4:
> 
>   Although DNS-over-TLS utilizes TCP port
>   853 instead of port 53, this document applies equally well to DNS-
>   over-TLS.
> 
> Um, how much of this document applies to DoT? Just the tuning advice, or
> the requirement that TLS MUST be supported like TCP MUST be?
> 
> 5:
> 
> re "DDoS mitigation techniques" would it be worth citing DNS RRL here as
> well as in section 9?

Hows this?

   message sizes, lack of EDNS(0) support, DDoS mitigation techniques
   (including [RRL]), or perhaps some future capability that is as yet



> 
> 10:
> 
>   Since DNS over both UDP and TCP use the same underlying message
>   format, the use of one transport instead of the other does change the
>   privacy characteristics of the message content
> 
> Missing "not"?

Yes indeed.

> 
> A:
> 
> Should RFC 2136 UPDATE be mentioned? (sections 2.1, 6.2, 7.8, 7.9) TBH I'm
> not sure how much UDP is used, but I certainly rely on 60+ KB updates.

I probably don't have enough direct experience with UPDATE to say.  If it is 
largely
over TCP then I think it should be included.


> 
> Also RFC 8482 section 4.4 talks about possible different behaviour for ANY
> queries over UDP compared to TCP.

RFC 8482 has been added to the appendix.

> 
> A.8:
> 
>   [RFC3226] strongly argued in favor of UDP messages over TCP largely
> 
> I had to read this twice! How about "instead of" instead of "over"?

yes, agreed.

> 
> A.14:
> 
> I think there should be a note that RFC 5966 has been obsoleted by RFC
> 7766, with a cross-reference to A.21.

Done.


DW




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Wessels, Duane]

> On Apr 19, 2021, at 4:31 AM, Joe Abley  wrote:
> 
> 
> Hi Suz,
> 
> On 18 Apr 2021, at 19:17, Suzanne Woolf  wrote:
> 
>> This message starts the Working Group Last Call for 
>> draft-ietf-dnsop-tcp-requirements 
>> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/)
> 
> I have read draft-ietf-dnsop-dns-tcp-requirements-07 and have the following 
> comments, in flagrant defiance of George's advice to ship the document based 
> mainly on considerations of age. :-)

Thanks Joe!

> 
> I think these are all fairly minor.
> 
> 
> Abstract, Section 4.4 "DNS-over-TLS"
> 
> The abstract includes the sentence "This includes both DNS over unencrpted 
> TCP, as well as over an encrypted TLS session." The later section 4.4 says 
> "this document applies equally well to DNS-over-TLS'.
> 
> The inclusion of DoT looks like an afterthought that has not been entirely 
> afterthought-through. The procedural updates to 1034 in section 3 clearly 
> don't apply to RFC 7858; the justifiable confusion about transports in the 
> DNS (the main topic of this document) also doesn't apply to 7858 which only 
> specifies use of TLS, not DTLS.
> 
> I suggest that this document is really only concerned with strengthening the 
> requirements around the use of TCP transport as described in 1034 and 1035 
> and that mentioning any other transport is unhelpful and arguably introduces 
> more confusion. I think that sentence should be changed in the abstract to 
> reflect that and section 4.4 should be removed. I would not be surprised to 
> hear that this DoT text was added precisely to address some other earlier 
> reviewer's opinion to the contrary, but this is what I think.

IIRC, DNS-over-TLS was added to this draft following a working group discussion 
at IETF 104.  I can easily be convinced to remove it, but I would like to hear 
more people supporting its removal.  I know Tony Finch also already raised 
questions about including DNS-over-TLS.


> 2.3 EDNS0
> 
> RFC 6891 uses the notation EDNS(0), not EDNS0. Since 6891 obsoletes 2671 it 
> seems reasonable to adopt its notation. I suggest going all search and 
> replace on that.

Okay, done.

> 
> 2.4 Fragmentation and Truncation
> 
> The second paragraph does not mention another fundamental problem with 
> stateless protocols over IPv6 when datagrams require truncation, which is 
> that the requirement in v6 to fragment and resent from the source is not 
> possible when the source has not retained any state regarding to the response 
> that was just sent. While I had my hands in the patient I also added a small 
> reference to tunnel encaps in IPv4.
> 
> OLD:
> 
>For IPv4-connected hosts, the de-facto MTU is often the Ethernet
>payload size of 1500 bytes.  This means that the largest unfragmented
>UDP DNS message that can be sent over IPv4 is likely 1472 bytes.  For
>IPv6, the situation is a little more complicated.  First, IPv6
>headers are 40 bytes (versus 20 without options in IPv4).  Second, it
>seems as though some people have mis-interpreted IPv6's required
>minimum MTU of 1280 as a required maximum.  Third, fragmentation in
>IPv6 can only be done by the host originating the datagram.  The need
>to fragment is conveyed in an ICMPv6 "packet too big" message.  The
>originating host indicates a fragmented datagram with IPv6 extension
>headers.  Unfortunately, it is quite common for both ICMPv6 and IPv6
>extension headers to be blocked by middleboxes.  According to
>[HUSTON] some 35% of IPv6-capable recursive resolvers were unable to
>receive a fragmented IPv6 packet.
> 
> NEW:
> 
>For IPv4-connected hosts, the MTU is often the Ethernet payload
>size of 1500 bytes.  This means that the largest unfragmented
>UDP DNS message that can be sent over IPv4 is likely 1472 bytes,
>although tunnel encapsulation may reduce that maximum message
>size in some cases.
> 
>For IPv6, the situation is a little more complicated.  First,
>IPv6 headers are 40 bytes (versus 20 without options in IPv4).
>Second, it seems as though some people have mis-interpreted
>IPv6's required minimum MTU of 1280 as a required maximum.  Third,
>fragmentation in IPv6 can only be done by the host originating
>the datagram.  The need to fragment is conveyed in an ICMPv6
>"packet too big" message.  The originating host indicates a
>fragmented datagram with IPv6 extension headers.  Unfortunately,
>it is quite common for both ICMPv6 and IPv6 extension headers
>to be blocked by middleboxes. According to [HUSTON] some 37% of
>IPv6-capable recursive resolvers were unable to receive a
>fragmented IPv6 packet.  Even if the originating host does receive
>a signal that fragmentation is required, the stateless nature
>of the DNS protocol is such that the host does not generally
>retain a copy of the message concerned and hence is unable to  
>fragment and re-send 

Re: [DNSOP] [Technical Errata Reported] RFC8976 (6425)

[Wessels, Duane]

Hi Brian,

I see what you're saying.  For implementations that treat the truncated digest 
as a zone parsing failure then example A.3 is not valid.

DW
  

> On Feb 11, 2021, at 11:19 AM, Wellington, Brian  wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> Hi Duane,
> 
> I’m not sure if I completely agree with this analysis.  The issue isn’t about 
> validation; it’s about parsing the presentation format.   The RFC says:
> 
>   When SHA384 is used, the size of the
>   Digest field is 48 octets.  The result of the SHA384 digest algorithm
>   MUST NOT be truncated
> I’d interpret that as requiring (or at least allowing) a zone file parser to 
> reject the example record as malformed, and fail to parse the zone.  Section 
> 2 is describing the format of the record itself, not the process of 
> validation, so I would expect the specific text in 2.2.3 to be applicable to 
> parsing the record, not validating it.
> 
> Thanks,
> Brian
> 
>> On Feb 11, 2021, at 10:25 AM, Wessels, Duane  wrote:
>> 
>> Brian,
>> 
>> Thank you for reporting this.  Indeed this example SHA384 digest should have 
>> 48 octets, although the A.3 example zone as a whole is still valid because a 
>> verifier will either exclude the ZONEMD RR in question either because of the 
>> private-use scheme or because it is truncated.  Since the example wasn't 
>> intended to include a truncated digest, we think the errata should be 
>> accepted and corrected.  Proposed correction:
>> 
>> example.  86400  IN  ZONEMD  2018031900 241 1 (
>>e1846540e33a9e41
>>89792d18d5d131f6
>>05fc283e8136a8ed
>>924937852d0076a3
>>fd5cd859c4265eaf
>>a8dd75c61e3dc079 )
>> 
>> DW
>> 
>> 
>>> On Feb 10, 2021, at 1:48 PM, RFC Errata System  
>>> wrote:
>>> 
>>> Caution: This email originated from outside the organization. Do not click 
>>> links or open attachments unless you recognize the sender and know the 
>>> content is safe. 
>>> 
>>> The following errata report has been submitted for RFC8976,
>>> "Message Digest for DNS Zones".
>>> 
>>> --
>>> You may review the report below and at:
>>> https://secure-web.cisco.com/1dYEy0TvU88Njg8yutPU4SwLggJQyQtMtCFHusS4a4nwHHkd3A6abr3omPJ9EK6U3LD99P6cBoRMQRg-6Qj9F83dYEUwv96xU0ZwpAXLazBepRocQLDO8SepHSeqtdZG2kjMy8KxUal-6tWtES4U88sanGAhpTvqbNvYpBaChoyDTB8PjjI0GnW8u0axgqd-BA6e4p8QHMODXQqiosSeXaDTrRmXEn4O3Ftg-2Mg-GdvlRjRjTBwrs4Q09iRyKBYb/https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6425
>>> 
>>> --
>>> Type: Technical
>>> Reported by: Brian Wellington 
>>> 
>>> Section: A.3
>>> 
>>> Original Text
>>> -
>>> example.  86400  IN  ZONEMD  2018031900 241 1 (
>>>   e1846540e33a9e41
>>>   89792d18d5d131f6
>>>   05fc283e )
>>> 
>>> 
>>> Corrected Text
>>> --
>>> 
>>> 
>>> Notes
>>> -
>>> 2.2.3 defines Hash Algorithm 1 as SHA384, and says that "the size of the 
>>> Digest field is 48 octets". There is nothing in 2.2.3 (or 2.2.2, where 
>>> Scheme is defined) that indicates that Scheme and Hash Algorithm are 
>>> dependent on each other, so the fact that the Scheme value (241) is private 
>>> should have no effect on the digest computed by Hash Algorithm 1.
>>> 
>>> Instructions:
>>> -
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party  
>>> can log in to change the status and edit the report, if necessary. 
>>> 
>>> --
>>> RFC8976 (draft-ietf-dnsop-dns-zone-digest-14)
>>> --
>>> Title   : Message Digest for DNS Zones
>>> Publication Date: February 2021
>>> Author(s)   : D. Wessels, P. Barber, M. Weinberg, W. Kumari, W. 
>>> Hardaker
>>> Category: PROPOSED STANDARD
>>> Source  : Domain Name System Operations
>>> Area: Operations and Management
>>> Stream  : IETF
>>> Verifying Party : IESG



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Technical Errata Reported] RFC8976 (6425)

[Wessels, Duane]

Brian,

Thank you for reporting this.  Indeed this example SHA384 digest should have 48 
octets, although the A.3 example zone as a whole is still valid because a 
verifier will either exclude the ZONEMD RR in question either because of the 
private-use scheme or because it is truncated.  Since the example wasn't 
intended to include a truncated digest, we think the errata should be accepted 
and corrected.  Proposed correction:

example.  86400  IN  ZONEMD  2018031900 241 1 (
 e1846540e33a9e41
 89792d18d5d131f6
 05fc283e8136a8ed
 924937852d0076a3
 fd5cd859c4265eaf
 a8dd75c61e3dc079 )

DW


> On Feb 10, 2021, at 1:48 PM, RFC Errata System  
> wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> The following errata report has been submitted for RFC8976,
> "Message Digest for DNS Zones".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6425
> 
> --
> Type: Technical
> Reported by: Brian Wellington 
> 
> Section: A.3
> 
> Original Text
> -
> example.  86400  IN  ZONEMD  2018031900 241 1 (
> e1846540e33a9e41
> 89792d18d5d131f6
> 05fc283e )
> 
> 
> Corrected Text
> --
> 
> 
> Notes
> -
> 2.2.3 defines Hash Algorithm 1 as SHA384, and says that "the size of the 
> Digest field is 48 octets". There is nothing in 2.2.3 (or 2.2.2, where Scheme 
> is defined) that indicates that Scheme and Hash Algorithm are dependent on 
> each other, so the fact that the Scheme value (241) is private should have no 
> effect on the digest computed by Hash Algorithm 1.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC8976 (draft-ietf-dnsop-dns-zone-digest-14)
> --
> Title   : Message Digest for DNS Zones
> Publication Date: February 2021
> Author(s)   : D. Wessels, P. Barber, M. Weinberg, W. Kumari, W. 
> Hardaker
> Category: PROPOSED STANDARD
> Source  : Domain Name System Operations
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-nsec-ttl

[Wessels, Duane]

> On Feb 3, 2021, at 3:24 PM, Michael StJohns  wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> On 2/3/2021 2:31 PM, Paul Hoffman wrote:
>> On Jan 29, 2021, at 9:31 AM, Michael StJohns  wrote:
>>> I can't support this as Standards track even though it purports to update 
>>> standards as it doesn't actually specify an implementable protocol.   
>>> Basically, this is dependent upon humans doing the right thing, rather than 
>>> specifying behavior of the protocol.
>> I don't understand the context of this. The draft specifies that the 
>> protocol is changing, and now authoritative servers change the way they act 
>> from $x to $y. Where is the "humans" part?
> 
> You're not specifying a change in how the Auth servers work AFAICT, you're 
> specifying a change in the data parameters for a few records which get set by 
> humans (and maybe enforced by tools, not necessarily by the server).  This is 
> operational guidance rather than implementation guidance - the servers 
> continue to serve the data they are provided regardless of whether its 
> "right" with respect to this guidance.


I agree its not specifying a change in how servers work.  And I agree its 
specifying a change in data parameters.

But I don't agree that NSEC TTLs get set by humans.  Certainly not in the same 
way that other TTLs do.  So in my view this is really implementation advice, 
not operational advice.


> 
> For example, one of the texts you reference (RFC4034 Section 4) is all about 
> crafting the contents of the data protocol, rather than what the server 
> should do to enforce things.  It probably should have said instead - "The 
> authoritative server SHOULD treat (and send) the TTL of the NSEC RR as having 
> the same value as the SOA minimum TTL field"

4034 probably should've said nothing about NSEC TTLs and just left it to 4035.

Where this draft updates 4035 to say "The TTL value for any NSEC RR SHOULD" I 
think it might be better to say "each NSEC RR" rather than any?


> 
> So I'm fine with the changes to the TTL setting, but you need to impose the 
> requirement on the client to do the right thing even if the data creator 
> screws up and does the wrong thing.

I think the draft already explains why that it not always possible.  The client 
might not have any other information that it can use to do the right thing.  
But as Paul is suggesting upthread if the client does have the other 
information (SOA) then yes, it could change its caching behavior.

DW






smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc7816bis

[Wessels, Duane]

All,

I have a few comments, focusing on the algorithm in section 3.


> 3.  Algorithm to Perform QNAME Minimisation
> 
>   This algorithm performs name resolution with QNAME minimisation in
>   the presence of zone cuts that are not yet known.
> 
>   Although a validating resolver already has the logic to find the
>   zone cuts, implementers of resolvers may want to use this algorithm
>   to locate the zone cuts.
> 
>   (0)  If the query can be answered from the cache, do so; otherwise,
>   iterate as follows:
> 
>   (1)  Get the closest delegation point that can be used for the
>   original QNAME/QTYPE combination from the cache.

Shouldn't that be just "original QNAME" since the QTYPE should be irrelevant
in locating zone cuts and delegation points?


> 
>   (1a)  For queries with QTYPE=DS this is the NS RRset with the
>owner matching the most labels with the QNAME stripped by
>one label.  The QNAME will be a subdomain of (but not equal
>to) this NS RRset.  Call this ANCESTOR.

How confident are we that DS will remain the only RR with parent-side
authoritative data?  There was recently a proposal
(draft-peetterr-dnsop-parent-side-auth-types) to reserve a range for types
with this property, but I guess it was pretty quickly shot down.  If a new
authoritative-in-parent RR type is defined in the future, then would it
need to update this specification?


> 
>   (1b)  For queries with other original QTYPEs this is the NS RRset
>with the owner matching the most labels with the QNAME.  The
>QNAME will be equal to or a subdomain of this NS RRset.
>Call this ANCESTOR.
> 
>   (2)  Initialise CHILD to the same as ANCESTOR.
> 
>   (3)  If CHILD is the same as the QNAME, or if the CHILD is one label
>   shorter than the QNAME and the original QTYPE is DS, resolve the
>   original query using ANCESTOR's name servers, and finish.

Throughout this section (and maybe elsewhere) the document should be
consistent with "the CHILD" and "the QNAME" or just "CHILD" and "QNAME".
My suggestion is to drop "the".


> 
>   (4)  Otherwise, add a label from the QNAME to the start of CHILD.

I'd like to see a lot more specificity here.  e.g., not just "a label" but
the next relevant label.

Also Section 2.3 talks about appending more than one label per iteration
in some cases, which isn't mentioned here.


> 
>   (5)  Look for a cache entry for the RRset at CHILD with the original
>   QTYPE.  If this entry is for an NXDOMAIN and the resolver has
>   support for [RFC8020], the NXDOMAIN can be used in response to
>   the original query, and stop.  If the entry is for a NOERROR
>   answer (either positive or negative), go back to step 3.  If the
>   entry is for an NXDOMAIN answer and the resolver does not support
>   RFC 8020, go back to step 3.

I find this step somewhat confusing as written.  My interpretation of it
goes something like this:

if A and B then X;
if C then Y;
if A and not B then Y;

I would like to see it (if not the whole algorithm!) as a flow chart, or
maybe pseudo-code?

Wording like "an NXDOMAIN" and "the NXDOMAIN" is imprecise.  It really
means a cached response whose RCODE is NXDOMAIN.

This talks about RCODES NXDOMAIN and NOERROR.  What about others, SERVFAIL,
REFUSED?  Assumes they are never cached?

Since NXDOMAIN means there are no RRsets of any type for the name, I would
expect the (original) QTYPE to be irrelevant when looking for a cached
NXDOMAIN response, especially in the RFC 8020 case.

Instead of "If the entry is for a NOERROR answer (either positive or
negative).." consider "If the cached response code is NOERROR (including
NODATA)..."


> 
>   (6)  Query for CHILD with the selected QTYPE using ANCESTOR's
>   name servers.  The response can be:

Using one of ANCESTOR's name servers?


> 
>   (6a)  A referral.  Cache the NS RRset from the authority section,
>and go back to step 1.
> 
>   (6b)  A NOERROR answer (either positive or negative).  Cache this
>answer, and go back to step 3.

again consider "(including NODATA)" instead of "(either positive or
negative)".


> 
>   (6c)  If the resolver is doing RFC 8020 with strict NXDOMAIN, an
>NXDOMAIN answer.  Return an NXDOMAIN answer in response to
>the original query, and stop.  If the resolver does not
>support RFC 8020, go back to step 3.

This would be better as:

(6c) An NXDOMAIN response.  If the resolver supports RFC8020, return an
NXDOMAIN response to the original query and stop.  If the resolver does
not support RFC8020, go to step 3.

> 
>   (6d)  An answer with another RCODE, or no answer.  Try another
>name server at the same delegation point.  Stop if none of
>them are able to return a valid answer.

This seems to be specifying (requiring?) some retry behavior.  I don't
know if or where resolver retry 

Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

[Wessels, Duane]

Dear IESG,

I believe all outstanding comments and concerns have now been addressed, so 
revision -14 has been posted.  

DW



> On Oct 15, 2020, at 3:38 AM, Rob Wilton (rwilton)  wrote:
> 
> Hi Duane,
> 
> That looks good.  Thanks for accommodating.
> 
> Regards,
> Rob
> 
>> -Original Message-
>> From: iesg  On Behalf Of Wessels, Duane
>> Sent: 14 October 2020 13:35
>> To: Rob Wilton (rwilton) 
>> Cc: draft-ietf-dnsop-dns-zone-dig...@ietf.org; Tim Wicinski
>> ; dnsop@ietf.org; dnsop-cha...@ietf.org; The IESG
>> 
>> Subject: Re: Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-
>> digest-12: (with COMMENT)
>> 
>> 
>> 
>>> On Oct 12, 2020, at 8:56 AM, Rob Wilton (rwilton)
>>  wrote:
>>> 
>>> 
>>> 
>>>> 
>>>>> 
>>>>>  2.  The ZONEMD Resource Record
>>>>> 
>>>>> It is
>>>>> RECOMMENDED that a zone include only one ZONEMD RR, unless the
>>>> zone
>>>>> publisher is in the process of transitioning to a new Scheme or
>>>> Hash
>>>>> Algorithm.
>>>>> 
>>>>> I'm not quite sure how well this fits with sections 2.2.3 restriction
>>>> that
>>>>> SHA384 MUST be implemented, and SHA512 SHOULD be implemented.   As a
>>>> recipient
>>>>> of the zone info I understand that I would need to implement both, but
>>>> as a
>>>>> sender am I allowed to only send SHA512, or both, or must I always
>> send
>>>> SHA384?
>>>> 
>>>> As sender (publisher) you are allowed to publish whatever you want.
>>> [RW]
>>> 
>>> Okay, taken in conjunction with 2.2.3 that didn't seem clear to me.  My
>> reading is that the sender SHOULD only send one, and [everyone] MUST
>> support SHA384, effectively implying that is SHA384 that MUST be sent ...
>> Perhaps the RFC 2119 language in section 2.2.3 needs to be restricted to
>> receivers processing ZONEMD records?  ... or some other way to convey the
>> difference in requirements on algorithm implementation between senders and
>> receivers.
>>> 
>> 
>> 
>> Hi Rob,
>> 
>> To address this, here is what we suggest:
>> 
>> In sections 2.2.2 and 2.2.3, rather than saying "MUST/SHOULD be
>> implemented" we'll say "MUST/SHOULD be supported by implementations."
>> 
>> The paragraph about multiple digests at the start of section 2 will be
>> moved to this new section 2.5:
>> 
>> 2.5.  Including ZONEMD RRs in a Zone
>> 
>>   The zone operator chooses an appropriate hash algorithm and scheme,
>>   and includes the calculated zone digest in the apex ZONEMD RRset.
>>   The zone operator MAY choose any of the defined hash algorithms and
>>   schemes, including the private use code points.
>> 
>>   The ZONEMD RRSet MAY contain multiple records to support algorithm
>>   agility [RFC7696].  [RFC Editor: change that to BCP 201] When
>>   multiple ZONEMD RRs are present, each MUST specify a unique Scheme
>>   and Hash Algorithm tuple.  It is RECOMMENDED that a zone include only
>>   one ZONEMD RR, unless the zone operator is in the process of
>>   transitioning to a new scheme or hash algorithm.
>> 
>> 
>> DW
>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

[Wessels, Duane]

> On Oct 12, 2020, at 8:56 AM, Rob Wilton (rwilton) 
>  wrote:
> 
> 
> 
>> 
>>> 
>>>   2.  The ZONEMD Resource Record
>>> 
>>>  It is
>>>  RECOMMENDED that a zone include only one ZONEMD RR, unless the
>> zone
>>>  publisher is in the process of transitioning to a new Scheme or
>> Hash
>>>  Algorithm.
>>> 
>>> I'm not quite sure how well this fits with sections 2.2.3 restriction
>> that
>>> SHA384 MUST be implemented, and SHA512 SHOULD be implemented.   As a
>> recipient
>>> of the zone info I understand that I would need to implement both, but
>> as a
>>> sender am I allowed to only send SHA512, or both, or must I always send
>> SHA384?
>> 
>> As sender (publisher) you are allowed to publish whatever you want.
> [RW] 
> 
> Okay, taken in conjunction with 2.2.3 that didn't seem clear to me.  My 
> reading is that the sender SHOULD only send one, and [everyone] MUST support 
> SHA384, effectively implying that is SHA384 that MUST be sent ...  Perhaps 
> the RFC 2119 language in section 2.2.3 needs to be restricted to receivers 
> processing ZONEMD records?  ... or some other way to convey the difference in 
> requirements on algorithm implementation between senders and receivers.
> 


Hi Rob,

To address this, here is what we suggest:

In sections 2.2.2 and 2.2.3, rather than saying "MUST/SHOULD be implemented" 
we'll say "MUST/SHOULD be supported by implementations."

The paragraph about multiple digests at the start of section 2 will be moved to 
this new section 2.5:

2.5.  Including ZONEMD RRs in a Zone

   The zone operator chooses an appropriate hash algorithm and scheme,
   and includes the calculated zone digest in the apex ZONEMD RRset.
   The zone operator MAY choose any of the defined hash algorithms and
   schemes, including the private use code points.

   The ZONEMD RRSet MAY contain multiple records to support algorithm
   agility [RFC7696].  [RFC Editor: change that to BCP 201] When
   multiple ZONEMD RRs are present, each MUST specify a unique Scheme
   and Hash Algorithm tuple.  It is RECOMMENDED that a zone include only
   one ZONEMD RR, unless the zone operator is in the process of
   transitioning to a new scheme or hash algorithm.


DW





smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)

[Wessels, Duane]

> On Oct 12, 2020, at 9:24 AM, Roman Danyliw  wrote:
> 
> Hi Duane!
> 
> Thanks for the extensive changes in -13.  They address my concerns.  I have 
> left one remaining comment about clarifying "provably secure" with a 
> reference.  Otherwise, I've cleared my ballot.

Thanks Roman,

Instead of "provably secure," how does this look to you:

   1.  The verifier MUST first determine whether or not to expect DNSSEC
   records in the zone.  By examining locally configured trust
   anchors, and, if necessary, querying for and validating DS RRs in
   the parent zone, the verifier knows whether or not the zone to be
   verified should include DNSSEC keys and signatures.  For zones
   where signatures are not expected, or if DNSSEC validation is not
   performed, digest verification continues at step 4 below.

   2.  For zones where signatures are expected, the existence of the
   apex ZONEMD record MUST be validated.  If the DNSSEC data proves
   the ZONEMD RRSet does not exist, digest verification cannot
   occur.  If the DNSSEC data proves the ZONEMD does exist, but is
   not found in the zone, digest verification MUST NOT be considered
   successful.

   3.  For zones where signatures are expected, the SOA and ZONEMD
   RRSets MUST have valid signatures, chaining up to a trust anchor.
   If DNSSEC validation of the SOA or ZONEMD RRSets fails, digest
   verification MUST NOT be considered successful.


DW



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-dns-zone-digest-13: (with COMMENT)

[Wessels, Duane]

> On Oct 11, 2020, at 9:03 PM, Benjamin Kaduk via Datatracker 
>  wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dnsop-dns-zone-digest-13: Yes
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for addressing my discuss (and comment!) points.  There are still
> a few more threads to tidy up, but I'm happy with the direction we're
> going.
> 
> Section 1
> 
> We (implicitly) mention "integrity" here as provided in the absence of
> DNSSEC, but later in Section 1.1 we say that integrity can only be assured
> when the zone is signed.  I leave it to Roman to say when his discuss is
> resolved, but it seems likely that we should be consistent about which way
> we go with it.

Looks like I missed that spot in when addressing Roman's point.  Now changed
to this:

   It allows a receiver of the
   zone to verify the zone's integrity and authenticity when used in
   combination with DNSSEC.



> Section 1.1
> 
> It's perhaps unusual to follow "the motivation for this protocol" with "a
> secondary motivation"; instead writing "the primary motivation" would reduce
> the surprise at seeing a secondary motivation added later.

Agreed.  This has been changed.


> 
> Section 2.2.2
> 
> This change seems to be a regression?  The value 1 in question is the
> scheme value, not a Hash Algorithm value.  (I would make this a
> Discuss point but I am sure we will get it resolved quickly.)

Oops, I changed that in the wrong place.  Now it says "with Scheme value 1" 
there
and "with Hash Algorithm value 1" in the next section.


> 
> Section 3
> 
> (nit) Right now the literal reading of "identical" is that the ZONEMD and
> the signature and the denial-of-existence records are identical, which
> is of course nonsensical.  Perhaps adding "to the ones produced by this
> procedure" or similar would reduce the stress for people who habitually
> make sentence diagrams.

Changed to this:

   Implementations that deviate from the
   described algorithm are advised to ensure that it produces ZONEMD
   RRs, signatures, and dential-of-existence records that are identical
   to the ones generated by this procedure.

> 
> Section 4
> 
> I can't tell if there's a duplicate line in the XML source or not, here
> (as an editing leftover), but that's my guess as to what happened.  In
> particular, I'm not sure how one would query for a DS RR *in the anchor*.
> If I'm reading the previous thread correctly we were only proposing to talk
> about querying for (and validating) DS RRs in the parent zone, not the
> anchor (whatever that means).

Yes indeed there was a line duplicated during editing.  Now:

   This is done by examining locally
   configured trust anchors, and, if necessary, querying for (and
   validating) DS RRs in the parent zone.

> 
> Who is going to come to a conclusion on the "[ Maybe remove all the "SHOULD
> report" above and just say this:]"?  (I'd be fine with it, for what little
> it's worth, but I don't think my opinion is anywhere close to the most
> relevant one.)

Both you and Rob asked about this -- the possibility of overly verbose 
reporting.
I'd like to hear Rob's opinion.

DW




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

[Wessels, Duane]

> On Oct 7, 2020, at 11:55 PM, Murray Kucherawy via Datatracker 
>  wrote:
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-dnsop-dns-zone-digest-12: No Objection

Hi Murray, thanks for the comments. 


> 
> --
> COMMENT:
> --
> 
> I support Benjamin's DISCUSS about the IANA issues.  I'd also suggest adding
> text about what the possible values of the "Implementation Requirement" column
> are and what they mean.

Based on the discussion with Benjamin that column has been dropped.


>  Further, what's the "Mnemonic" used for?  That word
> appears nowhere in the document other than in the column headings in this
> section.

I assumed that was relatively standard thing in protocol registry tables.
It probably came from using the DNSKEY algorithm registry as a model.
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1



> 
> Roman made some other good editorial suggestions.  Please check those out.
> 
> Section 3.3.1 says: "SIMPLE is a good choice for zones that are small and/or
> stable, but probably not good for zones that are large and/or dynamic." 
> There's no alternative presented for large/dynamic zones.  Are there plans to
> develop such a thing?

I have some ideas that I have shared on the DNSOP list and in some
presentations about zone digests.  Others probably have ideas as well.
Nothing is to the stage of being written down as an Internet Draft yet,
as far as I know.

DW



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

[Wessels, Duane]

> On Oct 9, 2020, at 12:08 PM, Ben Schwartz  wrote:
> 
> 
> 6.2.  Use of Multiple ZONEMD Hash Algorithms
> 
>When a zone publishes multiple ZONEMD RRs, the overall security is
>only as good as the weakest hash algorithm in use.
> 
> Why not require recipients to verify all digests with recognized algorithms?
> 

That text stating that one is sufficient was based on a conversation in the 
working group that started here:

https://mailarchive.ietf.org/arch/msg/dnsop/RFCklH7Lx00bL-tOVRCAc0j5ftw/


DW




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)

[Wessels, Duane]

> On Oct 7, 2020, at 1:52 PM, Roman Danyliw  wrote:
> 
> 
> In that case (where no assumptions are made about the transport), it seems 
> that only these scenarios from the list above apply:
> 
> With an on-path attacker (and trusted server hosting the zone file)
> 
> ** No DNSSEC  = integrity: NO; authenticity = NO
> ** DNSSEC = integrity: YES; authenticity = YES
> 
> With a rogue server hosting the zone file (but is not the operator of the 
> zone)
> 
> ** No DNSSEC = integrity: NO; authenticity = NO
> ** DNSSEC = integrity: YES; authenticity = YES
> 
> Or more succinctly, without DNSSEC, the two stated security properties aren't 
> provided.  
> 
> I'm not sure of what the best way is to resolve this mismatch based on the 
> use cases.  I can see (at least) two paths to resolution:
> 
> (1) Specify that ZONEMD records MUST only be used with DNSSEC -- this will 
> preserve the authenticity and integrity properties described in Section 1.1. 
> and 6.  An additional step or two might be needed to the verification process 
> in Section 4.  Does this impact the planned use cases or workflows?
> 
> (2) Provide appropriate caveats that ZONEMD information may not mean what you 
> think it means depending on whether DNSSEC is used.  This likely means: the 
> motivational goal in Section 1.1 may need to be weakened; the analysis of 
> alternatives in Section 1.2 won't make sense (for the non-DNSSEC case); and 
> an appropriate applicability-like statement might also be necessary to 
> describe how to use an insecure checksum.  Section 6 would needs additional 
> language to capture the difference between the DNSSEC vs. non-DNSSEC 
> deployment.  Editorially, clearer words like checksum might also help.

Thanks Roman, I see your point.  With the help of my coauthors we have made 
some edits that I think will address your concerns. 
Rather than try to include them all here, it will probably be easier to read 
the diff of the next revision that we hope to
submit later today.  Alternatively I can give you a github pull request link 
showing the changes if that would be helpful.

DW



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

[Wessels, Duane]

> On Oct 8, 2020, at 4:18 AM, Robert Wilton via Datatracker  
> wrote:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-dnsop-dns-zone-digest-12: No Objection
> 
> 
> --
> COMMENT:
> --
> 
> Thank for you this document.  I found it interesting and it looks useful.
> 
> I have a few comments that may improve this document for you to please 
> consider:
> 
>   Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash
>   Algorithm defined for ZONEMD records that MUST be implemented.  When
>   SHA384 is used, the size of the Digest field is 48 octets.  The
>   result of the SHA384 digest algorithm MUST NOT be truncated, and the
>   entire 48 octet digest is published in the ZONEMD record.
> 
>   SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for
>   ZONEMD records, and SHOULD be implemented.  When SHA512 is used, the
>   size of the Digest field is 64 octets.  The result of the SHA512
>   digest algorithm MUST NOT be truncated, and the entire 64 octet
>   digest is published in the ZONEMD record.
> 
> For consistency, perhaps change "with value 1" to "with Hash Algorithm value 
> 1"?

Done.


> 
>2.2.4.  The Digest Field
> 
>   The Digest field MUST NOT be shorter than 12 octets.  Digests for the
>   SHA384 and SHA512 hash algorithms specified herein are never
>   truncated.  Digests for future hash algorithms MAY be truncated, but
>   MUST NOT be truncated to a length that results in less than 96-bits
>   (12 octets) of equivalent strength.
> 
> When I read this, I wonder why the limit of 12 bytes was chosen.  Possibly a
> sentence that justifies why this value was chosen might be useful, noting that
> the two suggested algorithms have significantly longer digests.


I know there has been some followup on this with Donald.  In our earlier
conversations with him he wrote "96 bits seems to be a common minimum
length for disgests in the IETF although perhaps I have that impression
due to the common case of SHA-1 truncated to 96 bits."


> 
>2.  The ZONEMD Resource Record
> 
>   It is
>   RECOMMENDED that a zone include only one ZONEMD RR, unless the zone
>   publisher is in the process of transitioning to a new Scheme or Hash
>   Algorithm.
> 
> I'm not quite sure how well this fits with sections 2.2.3 restriction that
> SHA384 MUST be implemented, and SHA512 SHOULD be implemented.   As a recipient
> of the zone info I understand that I would need to implement both, but as a
> sender am I allowed to only send SHA512, or both, or must I always send 
> SHA384?

As sender (publisher) you are allowed to publish whatever you want.

The purpose of the recommendation above is to hopefully avoid the situation
where multiple records are published (with both types) on an ongoing basis.
That is something we observe with DS records quite often.  For example,
750 TLDs today publish both SHA1 and SHA256 digest types as DS records in
the root zone.  This new paragraph has been added to the security
considerations:

6.2.  Use of Multiple ZONEMD Hash Algorithms

   When a zone publishes multiple ZONEMD RRs, the overall security is
   only as good as the weakest hash algorithm in use.  For this reason,
   Section 2 recommends only publishing multiple ZONEMD RRs when
   transitioning to a new scheme or hash algorithm.  Once the transition
   is complete, the old scheme or hash algorithm should be removed from
   the ZONEMD RRSet.


> 
>3.1.  Add ZONEMD Placeholder
> 
>   In preparation for calculating the zone digest, any existing ZONEMD
>   records (and covering RRSIGs) at the zone apex are first deleted.
> 
> I think that this places a requirement that all zone digests must be
> constructed at the same time.  I suggest at least changing "zone digest" to
> "zone digest(s)", but it might also be worth adding a sentence to highlight
> that.

I've changed it to "zone digest(s)" as you suggest.

Strictly speaking, there is not a requirement that all digests must be created
at the same time (in parallel).  

The reason for the placeholder is explained in the next paragraph, which is to
ensure correct NSEC/NSEC3 records when the zone is signed with DNSSEC. 


> 
> I was also left wondering whether it is strictly required that the zone 
> digests
> must be deleted, or just that placeholder zone digests must be used in their
> place during the calculation.  E.g. what happens if a request is received to
> fetch the ZONEMD record at the same time that it is being reconstructed?

It is not strictly required to delete any existing digest first.  The ZONEMD 
records
are not included in the digest calculation.

To address your questions around this, I suggest adding this text to section 3,
before section 3.1:

3.  Calculating the Digest

   The algorithm described in this section is designed for 

Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

[Wessels, Duane]

> On Oct 7, 2020, at 2:47 AM, Éric Vyncke via Datatracker  
> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-dnsop-dns-zone-digest-12: No Objection
> 
> --
> COMMENT:
> --
> 
> Thank you for the work put into this document. I really like the idea of
> protecting the zone integrity even at rest.
> 
> Please find below one non-blocking COMMENT points and one nit. I would really
> appreciate a reply for my comment about section 1.2.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> -- Section 1.2 --
> Why is draft-ietf-dprive-xfr-over-tls not mentioned in this section as an
> alternative for data on the move?

Just an oversight.  The document does (did) mention "a future version of 
DNS-over-TLS"
which I think was meant as a reference to draft-ietf-dprive-xfr-over-tls when 
that was
just getting started.  Ben pointed this out as well and I suggest changing the 
text to this:

   The Transport Layer Security protocol suite also provides channel
   security.  The DPRIVE working group is in the process of specifying
   DNS Zone Transfer-over-TLS [I-D.ietf-dprive-xfr-over-tls].


> 
> == NITS ==
> -- Section 1.4.3 --
> Suggest to add "(RPZ)" after the first use of the expansion.
> 


Done.

DW




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

[Wessels, Duane]

> On Oct 6, 2020, at 3:26 PM, Erik Kline via Datatracker  
> wrote:
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-dnsop-dns-zone-digest-12: Yes
> 
> 
> --
> COMMENT:
> --
> 
> [[ nits ]]
> 
> [ section 1.2 ]
> 
> * "Whereas DNSSEC is primarily protects" ->
>  "Whereas DNSSEC primarily protects"
> 
> [ section 6.2 ]
> 
> * "DNSSESC" -> "DNSSEC"
> 

Thanks, these have been fixed!

DW



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)

[Wessels, Duane]

Hi Benjamin, thanks for the extensive review and comments.  Responses are
inline.  As you've noted some of this overlaps with Roman's comments as
well.


> On Oct 6, 2020, at 10:41 AM, Benjamin Kaduk via Datatracker 
>  wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dnsop-dns-zone-digest-12: Discuss
> 
> 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://secure-web.cisco.com/1BhOfb00VlP-8nUKujrBf7Xdn619jDI_JYiZUqXkRxJrGzti31tg1_lvl6zhDB3k4IUREe6b8Nw3PlWFa0tN3hSEXudysqKd2OxwaaOs0SBHZvEEKVIPc1f-JzrxCn2NAZvke4gWp4K8Nu32aoVdLQKo7SS5PVgHXC9ilgSSqgG_on7pnLuTvHDjYBitnA0fUBIgsOzbVX0tkBue9G06o0C0r80D6EsaK6UoD5cuNz9mUjPZ56TJxzip1UXrfJZ28kGt4MPwe8JIqa4VLKcwz8GqlffyQuXEquiSqih46whY/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://secure-web.cisco.com/1xe5afi0q1U9T8XBGtR5t0vEYlrnzaadCkXqE09yMZj4z0tASslenLfkLmcnAJ7Mh9GZqXJwg_vPKpS0X4wUosrcy_CVVGV42vwFrwqpNkm-3ukWQWroGS3v0hj84_EQOKGAHQG7X87FSo9kCMC4VX43uHk4s9tUi1QT-f1gd4kngZnItz73If8TdNzt_dLWdlpOjGkd1YSMOMD9ZAitEfs_X25RrGQdC2vFNdrGXdbChufVU8h4Ex2uZCVCakgPLhbPUKXVdXDkZ5JCPHireHA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-zone-digest%2F
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Inclusion of an "implementation requirement" column in the IANA
> registries implies a need for a defined procedure to make changes to
> existing registrations.  With only a "specification required" procedure,
> it seems there would need to be a "change controller" column as well.
> Furthermore, is it expected that anyone with any specification could
> set, e.g., an implementation requirement of "MUST"?  It seems like this
> attribute might be better left for the RFCs defining the protocol, to be
> modified by an updating RFC...

To be honest, I feel like the "implementation requirement" column is a
bit of a can-of-worms.  I have a hard time finding other IANA registries
that use it.  Would it be better to omit this from the registry?

If not, would it be sufficient to say something like "all specifications
requesting an allocation must have the implementation requirement set to
MAY unless being published on the standards track"?



> 
> If we are to retain the Implementation Status appendix in the final RFC,
> the boilerplate will need some changes, and I think those changes should
> get review prior to AUTH48.  For example, "at the time of posting of
> this Internet-Draft" will make no sense in an RFC, and the relationship
> to RFC 7942 is not quite as clear given that we diverge from its
> recommendations.  "[A]ssist the IETF in its decision process" does not
> seem to apply after the IETF has made its decision, though the
> disclaimer about endorsement seems highly important to retain.


Is this okay?

  RFC Editor: Please retain this section upon publication.

  This section records the status of known implementations of the
  protocol defined by this specification, and is inspired by the
  concepts described in RFC7942.

  Please note that the listing of any individual implementation here
  does not imply endorsement by the IETF.  Furthermore, no effort has
  been spent to verify the information presented here that was supplied
  by IETF contributors.  This is not intended as, and must not be
  construed to be, a catalog of available implementations or their
  features.  Readers are advised to note that other implementations may
  exist.


> 
> This seems to be related to Roman's Discuss point, but the document
> seems to be inconsistent as to the primary purpose of the mechanism --
> Section 1.1 says that it is to verify "authenticity" of a stand-alone
> zone, whereas the Introduction implies that "integrity" is primary (with
> authenticity as an add-on "when used in combination with DNSSEC), and
> the Abstract refers to "accuracy and completeness".  In particular, it
> is easy to read references to "integrity" (and, indeed, the Abstract
> itself) as referring to something akin to a transport checksum instead
> of a cryptographic message integrity code.  I think the document needs
> to be much more clear, and consistent, about what properties it aims to
> provide.  (I do not believe that the "authenticity" property can be
> provided without DNSSEC, and Roman covers the cryptographic integrity
> case in his ballot position.)

Thanks for pointing this out. Here's some diff showing changes to address
this:

-that provides a cryptographic message digest over DNS zone data.
+that provides a cryptographic message digest over DNS zone data at 
rest.

-can 

Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)

[Wessels, Duane]

Hi Roman, thanks for the detailed review and comments.  My responses are inline.


> On Oct 5, 2020, at 7:47 PM, Roman Danyliw via Datatracker  
> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-dnsop-dns-zone-digest-12: Discuss
> 
> 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://secure-web.cisco.com/1PmgI5C3eeSLOyMacI0tFtTZ2Xp1ZVDLlBYygPBOj1Q0bVtLkzLwmmN5ldjjcypZn5nnasJsm9E5GpsNMDvWdtGaM2kaFHhp7jZlEgufkzdln1LmRT84DKcbrePOUdtgU2M4UwQqhJ69IT0KBrKkQNN1OLFRMyYwhXs48zGHMkPxAOQ9L2Je4TLpCoWGXIqZExBn5ErrQBYfVsEcz2xB1L-eKHO_l_zDzfiAHtMP8zHJQ_7GCF6YPn4OTvYHtKq1TL85oSNMxkc-a9TwIaBuzcEx2aRPzSqAPypDs7bIbFPs/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://secure-web.cisco.com/1In2W1aOUrhepme0YYTCWi_KVrjzwPz6gRHK3wqiBh8JhXsVPR-caNTg-liKbKCksx5Y35akHQwb5BB41XUadJT3by_ZmHTxwdiSU3QpC4eNTBAE42Pw2mywlUcsCxUsDMgrwL3ph93cdoIxfnYKlbiF9GQp0v74iO_IcfqqkdmjHCiFqNSIrWIJsjsae_FUkueb3LzXcJ3Ine0GDo664s3xd60kYguQsCr17CZmEHlHTLEzHiGGXW8IrEm4JcgBjaAU2ABRPZ-bfBv0LsmZR0Q/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-zone-digest%2F
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Section 6.1.   My read of the text is that the security properties are 
> intended
> to be independent of the transport protocol.  With that assumption and the
> validation procedures in Section 4, I need help understanding the security
> properties the client can rely on in the absence of DNSSEC.  Consider the
> following scenarios and attacker types; and the assurances a client could have
> when retrieving the zone file from the server:
> 
> With an on-path attacker (and trusted server hosting the zone file)
> 
> ** No DNSSEC; No Secure transport = integrity: NO; authenticity = NO
> 
> ** No DNSSEC; Secure transport = integrity: YES (from the on-path attacker);
> authenticity = NO
> 
> ** DNSSEC = integrity: YES; authenticity = YES
> 
> With a rogue server hosting the zone file (but is not the operator of the 
> zone)
> 
> ** No DNSSEC; No Secure transport = integrity: NO; authenticity = NO
> 
> ** No DNSSEC/Secure transport = integrity: NO; authenticity = NO
> 
> ** DNSSEC = integrity: YES; authenticity = YES
> 
> The text states that:
> 
> The zone digest allows the recipient of a zone to verify its
>  integrity.  In conjunction with DNSSEC, the recipient can
>  authenticate that it is as published by the zone originator.
> 
> Can the means to realize integrity without DNSSEC unless there is a reliance 
> on
> transport security of some form be clarified.  Minimally, it seems like this
> section needs cautionary text (likely with normative language) to the effect 
> of
> “ZONEMD information from zone files lacking DNSSEC support or that were shared
> over ‘unsecure transport’ cannot be relied upon for cryptographic integrity
> assurance.”

You are correct that we intend the security properties to be independent of
any transport protocol.   I'm reluctant to suggest in this document that
a recipient could rely on ZONEMD for integrity because it came over a secure
transport.  Although that might be true, I have to think that the secure
transport itself provides the integrity assurance, and not the ZONEMD record.


> 
> 
> --
> COMMENT:
> --
> 
> Thank you for addressing the SECDIR review (and thank you to Donald Eastlake
> for performing the review).
> 
> ** Section 1.  s/allowing verification of the zone/allowing verification of 
> the
> integrity of the zone/

The sentence preceding this one talks about verifying both integrity and
authenticity (given DNSSEC).  I'm not sure why you want to focus on just
integrity here in this sentence?


> 
> ** Section 1.2.  In the discussion about alternatives, it seems like the two
> competing designs are “channel security” vs. “data security”?  Is the latter
> the equivalent to “object security”, a term with which I’m more familiar?  
> That
> is, the data itself carries a set of security properties independent of the
> channel or session exchanging it.

Yes, data security means the same thing as object security.


> 
> ** Section 1.3.  Clarifying language.
> OLD
> As specified herein, the digest is re-calculated over the
>  entire zone content each time
> 
> NEW
> As specified herein, the digest is re-calculated over the
>  entire zone content each time the zone is updated.

Okay.


> 
> ** Section 1.3.  Editorial.  The sentence “It is, however, extensible so 
> future
> schemes to 

Re: [DNSOP] zone contents digest and DNSSEC stuff

[Wessels, Duane]

> On Sep 29, 2020, at 6:42 AM, libor.peltan  wrote:
> 
> Hi Joe,
> 
> Dne 29.09.20 v 15:03 Joe Abley napsal(a):
>> The other use case I seem to think you're implying is that a consumer of the 
>> signed zone could verify that it was intact using the signed-zone ZONEMD, 
>> then strip the DNSSEC RRs and retain the ability to verify that the result 
>> was an accurate representation of the unsigned zone using the unsigned-zone 
>> ZONEMD. This seems like a slightly odd thing to want to do, but perhaps I'm 
>> just not thinking hard enough?
>> 
>> 
>> Joe
> 
> yes, something like this.
> 
> My initial thought was that the signer, which converts the un-signed zone by 
> adding signatures and keys, might not be able to compute/update the ZONEMD 
> record.
> 
> It might also be useful, when the zone is only re-signed and otherwise 
> unchanged, if the zone checksum was unchanged.
> 
> I'm not sure. This is just a thing to be thought of.
> 
> I would love if there was a bit flag indicating if the checksum has been 
> computed including DNSSEC records, or without them. This would let the 
> freedom of choice on the users, while adding some complexity to software 
> implementation.
> 
> Thanks for consideration,
> 
> Libor


Joe's response was very good, especially with respect to signed and unsigned 
being two different zones. 

During the working group discussions, we often heard the opinion that ZONEMD is 
not reliable without DNSSEC signatures.  Without a signature on the ZONEMD 
record, an adversary can easily change the digest to match changes to zone 
content.  I expect in most cases digest calculation will be done at the same 
time as zone signing.

There is no flags field, but you could probably accomplish your goal with a new 
or private use scheme code point.  That is, you could define a collation scheme 
that excludes DNSSEC RR types during digest calculation.

If there were a proposal to standardize such a scheme, the concern I would have 
is that it complicates the meaning of zone digest verification.  It would 
essentially be verifying a subset of the zone, which is not as strong as 
verifying the full zone.

DW



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop