[DNSOP] Protocol Action: 'Interoperable Domain Name System (DNS) Server Cookies' to Proposed Standard (draft-ietf-dnsop-server-cookies-05.txt)
The IESG has approved the following document: - 'Interoperable Domain Name System (DNS) Server Cookies' (draft-ietf-dnsop-server-cookies-05.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ Technical Summary DNS cookies, as specified in RFC 7873, are a lightweight DNS transaction security mechanism. This document provides precise directions for creating Server Cookies so that an anycast server set including diverse implementations will interoperate with standard clients. Working Group Summary There were several discussions during the working group process, but they were all resolved. Document Quality The document was the result of different interpretations of the original RFC that cause some implementation issues. Appendix C points out there are several implementations that interact successfully. Personnel Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] IETF 110 Internet Draft submission cut-off in 4 weeks (22 Feb 2021)
Hi, For those who want to publish a new Internet Draft (version) for IETF 110, the cut-off is Monday, February 22, 2021 (UTC 23:59). Four weeks gives the opportunity to consult the WG or contact the WG chairs well before the cut-off date. Best, -- Suzanne, Tim and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-ttl-01.txt
Hello DNSOP, inspired by success stories from other WGs, I've written up an implementation report on the IETF Trac wiki, at https://trac.ietf.org/trac/dnsop/wiki/draft-ietf-dnsop-nsec-ttl This will allow us to track implementation after document publication - when the 'Implementation Status' from the draft is gone (we usually do not publish it in the final RFC - and if we did, it would quickly be outdated). If we do this for other documents too, we can easily check how implementation is going - and if implementation is happening at all! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SVCB without A/AAAA records at the service name
From: Ben Schwartz Sent: Friday, January 22, 2021 1:29 PM To: Hollenbeck, Scott Cc: m...@lowentropy.net; dnsop@ietf.org Subject: [EXTERNAL] Re: Re: [DNSOP] SVCB without A/ records at the service name On Fri, Jan 22, 2021 at 12:43 PM Hollenbeck, Scott mailto:40verisign@dmarc.ietf.org>> wrote: From: DNSOP mailto:dnsop-boun...@ietf.org>> On Behalf Of Ben Schwartz Sent: Tuesday, January 19, 2021 10:01 PM To: Martin Thomson mailto:m...@lowentropy.net>> Cc: dnsop mailto:dnsop@ietf.org>> Subject: [EXTERNAL] Re: [DNSOP] SVCB without A/ records at the service name On Tue, Jan 19, 2021 at 7:40 PM Martin Thomson mailto:m...@lowentropy.net>> wrote: On Wed, Jan 20, 2021, at 09:17, Ben Schwartz wrote: > As I noted in that discussion, the client generally doesn't know in > advance that they aren't needed. I am asserting that the client very much knows. Indeed, it has to know. If we define a new protocol that relies on SVCB and that protocol is able to use SVCB exclusively (which would be a good thing in my view, all this parallel DNS querying is unnecessary, even if the DNS protocol is pretty good at it), then a client can very much know. Querying in parallel is of course just an optimization, but the client can't obviously know that those queries won't be needed, even for a protocol that uses SVCB exclusively. Every SVCB mapping ultimately relies on A/ records for the ServiceMode TargetName. The client doesn't know what that TargetName will be until it gets the SVCB response. However, in every protocol considered thus far, the most likely TargetName is the original hostname (or its CNAME alias). By querying that name in parallel, the client can short-circuit a subsequent lookup and reduce latency. This has nothing to do with fallback. [SAH] We need to think about the impact on the servers that have to respond to those queries, too. Sending unnecessary queries to the root and TLD servers puts a load on those servers that can have an impact on every client/resolver that needs to be able to reach them. This is important, but I don't think it's applicable here. The various options under consideration all impose the same amount of load on root and TLD servers. [SAH] So if some number if queries X and some number of queries Y are processed in parallel, the value of X + Y will be the same as if those queries are processed serially? Scott ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-ttl-01.txt
Hello dnsop, please find below revision -01 of this document. Matt Nordhoff noticed that I upgraded the NSEC TTL requirements from 'SHOULD' to 'MUST' compared to the original texts, and pointed out that incremental signers might have a hard time honouring that 'MUST'. Matthijs Mekking (ISC/BIND) confirmed this theory. So, -01 drops the requirement level back to SHOULD, just like the original texts. I believe the document is ready for publication. Chairs, can we do a WGLC? On Sun, 2021-01-24 at 23:59 -0800, 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 : NSEC(3) TTLs and NSEC Aggressive Use > Author : Peter van Dijk > Filename: draft-ietf-dnsop-nsec-ttl-01.txt > Pages : 8 > Date: 2021-01-24 > > Abstract: >Due to a combination of unfortunate wording in earlier documents, >aggressive use of NSEC(3) records may deny names far beyond the >intended lifetime of a denial. This document changes the definition >of the NSEC(3) TTL to correct that situation. This document updates >RFC 4034, RFC 4035, and RFC 5155. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec-ttl-01.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-ttl-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-nsec-ttl-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 : NSEC(3) TTLs and NSEC Aggressive Use Author : Peter van Dijk Filename: draft-ietf-dnsop-nsec-ttl-01.txt Pages : 8 Date: 2021-01-24 Abstract: Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC(3) records may deny names far beyond the intended lifetime of a denial. This document changes the definition of the NSEC(3) TTL to correct that situation. This document updates RFC 4034, RFC 4035, and RFC 5155. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec-ttl-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-ttl-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
