Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-01.txt
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
[DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-01.txt
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://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-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-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://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNS Directorate...
Hi there all, At IETF 114 I mentioned that Eric Vynke and I were planning on creating a DNS Directorate. Unfortunately we got a little busy, and so it took a bit longer than expected, but we've finally had a chance to write up a "charter" (below). A number of people have already kindly offered to participate, but we'd like some more, so, if you are willing, please fill in this form - https://forms.gle/GDffKp2XuT9acK9T6 - this will add your info to a (private) spreadsheet so that Eric and I don't accidentally miss an email. If you have already volunteered, please fill it in anyway, just to make sure we didn't miss your mail… As usual, we are not looking only for "the" experts on DNS (even if those are welcome), but also for volunteers with good understanding of DNS security, privacy, operations, implementing, scalability, ... even if 'new' at the IETF. If you are willing to dedicate some time to review early drafts for the benefit of the IETF community: please step forward ! Thank you, W - # DNS Directorate Charter (draft) DNS directorate reviewers assist Area Directors, Working Group chairs, and document authors with documents containing DNS-related content. More detailed guidance on DNS directorate process can be found at: http://wiki.ietf.org/group/dnsdir WG chairs or responsible ADs may request a DNS directorate review via the draft's Datatracker page. They are encouraged to do so as early in the process as possible to ensure that structural concerns are caught early in the document development. The DNS directorate secretaries will assign reviews to reviewers, but they are not required to check the list of IETF drafts for DNS-related ones. The DNS directorate reviews will be sent to the DNS Directorate mailing list (dns...@ietf.org), draft authors, WG chairs, and the respective AD. The DNS directorate reviewers and secretary are volunteers, and serve at the pleasure of the INT and OPS area ADs. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNSOP WG interim-2022-dnsop-02 meeting agenda (September 26, 2022)
Hi all, As mentioned on the mailing list, we have settled on a date for the DNSOP WG virtual interim meeting on Monday, September 26, from 15:00 to 16:00 UTC. The agenda for the interim is: * Administrivia - Agenda Bashing, Blue Sheets, etc, 5 min * Current Working Group Business - DNS Terminology https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/ Paul Hoffman and Kazunori Fujiwara, 55 min Chairs Action: Information about agenda, remote participation and more: - https://datatracker.ietf.org/doc/agenda-interim-2022-dnsop-02-dnsop-01/ - https://datatracker.ietf.org/meeting/interim-2022-dnsop-02/session/dnsop Best regards, Suzanne, Tim and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)
Hi all,
Firstly, and most importantly, thank y'all for keeping this civil, friendly
and productive; I really appreciate it.
I've (informally) checked with the IESG on the proposed change in the
PR and also including Erik's proposed operational note ("Some
implementations may not allow A or records on names starting with an
underscore due to various interpretations of RFCs. This could be an
operational issue when the TargetName contains an attrleaf label, as well
as using an TargetName of "." when the owner name contains an attrleaf
label.") and everyone seems fine with it.
So, I'm ask the authors to cut a new version with these changes in
(basically, accept the PR and add the proposed text) and I will then email
the IESG with a diff to get "official" consensus on the change.
Dealing with process exception handling is always stressful, so thanks all
again for keeping this moving along nicely.
Also, a reminder that while we *can* make changes after approval (and
before RFC publication) we really really avoid doing so, and so this should
only happen under exceptional circumstances[0].
W
[0]: I'm not convinced that this situation rose to the "exceptional
circumstances" bar, but seeing as I'd already paused it (not knowing what
all the issues were) and because the changes are clarifications, I'm
willing to accepting it.
On Thu, Sep 08, 2022 at 12:34 PM, Erik Nygren wrote:
> There seem to be two topics:
>
> 1) Victor's clarification makes sense, although the wording is a little
> awkward and perhaps we can improve that sentence.
> The section was already implying that meaning (ie, that the fallback
> addition of the QNAME was for the AliasMode case)
> but clarifying this in a more normative way seems worthwhile and not a
> technical change.
> I'd propose we refine this PR and incorporate it as the "clarifying
> sentence" that Warren was willing to accept.
>
> 2) There is the issue of whether attrleaf labels are valid owner names for
> A/ records.
> This document does not seem like the place to land that, and it seems
> like it may be open for interpretation
> as different implementations may have interpreted it differently. If
> anything, we might add a non-normative sentence like:
>
>"Some implementations may not allow A or records on names
> starting with an underscore
> due to various interpretations of RFCs. This could be an
> operational issue when the TargetName contains an attrleaf label,
> as well as using an TargetName of "." when the owner name contains
> an attrleaf label."
>
>This wouldn't be a normative change but just an operational warning ---
> would this be acceptable to include at this stage?
>Further clarification of this seems worth a draft in its own right
> since the existing RFCs are inconsistent
>on this topic and there is room for multiple interpretations, as shown
> in some implementations.
>
>
>
> On Thu, Sep 8, 2022 at 12:05 PM Paul Hoffman
> wrote:
>
>> On Sep 8, 2022, at 8:35 AM, Viktor Dukhovni
>> wrote:
>> > This is a bug fix, the proposed behaviour makes no sense when $QNAME
>> > is the unaltered (attrleaf prefixed) starting point. The current
>> > meaning was not intended. If the edit can be made without any
>> > major process, just a note to the RFC editor, it'll save errata,
>> > and possible confusion later.
>>
>> A technical change made after the IESG review requires, at a minimum,
>> another IESG review. The IESG could ask for another IETF review, if they
>> want. It's up to Warren, the responsible AD, to decide if that's "major
>> process".
>>
>> --Paul Hoffman
>>
>> ___
>> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] [core] WGA call for draft-lenders-dns-over-coap
Hello everyone, Speking as the author of RFC 7830 – there was some discussion whether the document should say “SHOULD NOT” or “MUST NOT” when padding DNS packets over unencrypted packets. We couldn’t come up with any other use case (maybe except testing of the feature over unencrypted transport), so the consensus of the group was that we should be strict, especially as padding might be an easy way to bloat packets. I do agree that this connects DNS answer behaviour with transport choice – hence creates a dependency that’s probably not very wise in a protocol that has already pretty complex dependencies. If the community believes that this requirement should be relaxed (and it’s worth the effort), I’m up for creating a revision of RFC 7830. This might also be a chance to step up EDNS Padding to Internet Standard – I think it’s widely deployed on billions of devices (Android..). Thoughts? Best, Alex Von: dns-privacy Im Auftrag von Vladimír Cunát Gesendet: Freitag, 9. September 2022 18:11 An: Ben Schwartz Cc: c...@ietf.org; DNS Privacy Working Group ; dnsop ; Jaime Jiménez Betreff: Re: [dns-privacy] [DNSOP] [core] WGA call for draft-lenders-dns-over-coap On 06/09/2022 17.06, Ben Schwartz wrote: The choice of transport is independent of the DNS server's answering behavior, which must not be modified by the transport. Nit: there's a very specific counter-example of EDNS padding which is meant to be added depending on transport encryption. https://www.rfc-editor.org/rfc/rfc7830#section-6 There might be some others (in future, too), as encryption does change some considerations, but yes - not basic stuff like following CNAMEs. --Vladimir | knot-resolver.cz ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
