Re: [DNSOP] Éric Vyncke's Discuss on draft-ietf-dnsop-rfc7816bis-10: (with DISCUSS)
On Tue, Aug 24, 2021 at 05:23:31AM -0700, Éric Vyncke via Datatracker wrote: > -- Section 2.1 -- > I support Erik Kline's COMMENT on this and am raising it to a blocking > DISCUSS. > > A/ in all the discussion in the last §, a would have the same benefit > when > compared to a NS QTYPE. Or what did I miss ? Actually, it might not be quite as effective in practice. The reason is that "" records are absent more often than "A" records, and when "A" records are present, but "" records are not, "" queries elicit a "denial of existence" response. Unfortunately, broken denial of existence, though rare, is not as infrequent as I'd like. I see a non-negligible set of names where "A" queries return answers, but "" queries SERVFAIL. I am not aware of any advantage to using "" for the qname minimisation queries, so "A" appears to me to be the better choice. Examples: https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/qmin.d/mail.ajsuarez.com.html https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/qmin.d/mail.puz.de.html https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/qmin.d/gloria.sntech.de.html https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/qmin.d/mx1.espresso-gridpoint.net.html https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/qmin.d/exchange.hctec.net.html https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/qmin.d/fallback.hctec.net.html -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Éric Vyncke's Discuss on draft-ietf-dnsop-rfc7816bis-10: (with DISCUSS)
Works for me too. My main observation was to consider acknowledging there might be some nuance in this QTYPE area, and this sounds sufficiently nuance-y for me. Thanks Paul! On Tue, Aug 24, 2021 at 10:36 PM Eric Vyncke (evyncke) wrote: > Paul, > > First , thank you for your reply. > > Second, your proposed change actually addresses my DISCUSS and will be > happy to change my ballot in a NO OBJECTION once a revised I-D is published > ;-) > > Regards > > -éric > > -Original Message- > From: iesg on behalf of Paul Hoffman < > paul.hoff...@icann.org> > Date: Wednesday, 25 August 2021 at 00:44 > To: Eric Vyncke > Cc: dnsop , The IESG , " > draft-ietf-dnsop-rfc7816...@ietf.org" < > draft-ietf-dnsop-rfc7816...@ietf.org> > Subject: Re: [Ext] Éric Vyncke's Discuss on > draft-ietf-dnsop-rfc7816bis-10: (with DISCUSS) > > On Aug 24, 2021, at 5:23 AM, Éric Vyncke via Datatracker < > nore...@ietf.org> wrote: > > == DISCUSS == > > > > -- Section 2.1 -- > > I support Erik Kline's COMMENT on this and am raising it to a > blocking DISCUSS. > > > > A/ in all the discussion in the last §, a would have the same > benefit when > > compared to a NS QTYPE. Or what did I miss ? > > > > B/ the last two sentences "Another potential benefit...happy > eyeballs query for > > the A QTYPE." are puzzling as using A QTYPE will actually only cache > the A > > answer for the minimized request and more and more Internet users > are using > > IPv6 nowadays (and possibly even more recursive DNS servers). > > > > Hence, I would welcome some discussion in the last § about the > benefit of using > > A QTYPE rather than QTYPE and, as suggested by Erik Kline, > please remove > > the last 2 sentences. > > If we change from: > >A good candidate is to always use the "A" >QTYPE because this is the least likely to raise issues in DNS >software and middleboxes that do not properly support all QTYPEs. >The QTYPE=A queries will also blend into traffic from non-minimising >resolvers, making it in some cases harder to observe that the >resolver is using QNAME minimisation. Using the QTYPE that occurs >most in incoming queries will slightly reduce the number of queries, >as there is no extra check needed for delegations on non-apex >records. Another potential benefit of using QTYPE=A is that >[RFC8305] clients that need answers for both the A and types >will send the query first. When minimising using QTYPE=A the >minimised query might be useful, and now already in the cache, for >the happy eyeballs query for the A QTYPE. > > to: > >Good candidatesare to always use the "A" or "" >QTYPE because these is the least likely to raise issues in DNS >software and middleboxes that do not properly support all QTYPEs. >QTYPE=A or QTYPE= queries will also blend into traffic from > non-minimising >resolvers, making it in some cases harder to observe that the >resolver is using QNAME minimisation. Using a QTYPE that occurs >most in incoming queries will slightly reduce the number of queries, >as there is no extra check needed for delegations on non-apex >records. > > does that alleviate your concers? > > --Paul Hoffman > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-03.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 : DNS Catalog Zones Authors : Peter van Dijk Libor Peltan Ondrej Sury Willem Toorop Leo Vandewoestijne Filename: draft-ietf-dnsop-dns-catalog-zones-03.txt Pages : 20 Date: 2021-08-25 Abstract: This document describes a method for automatic DNS zone provisioning among DNS primary and secondary nameservers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-catalog-zones-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
Re: [DNSOP] [art] Artart telechat review of draft-ietf-dnsop-rfc7816bis-10
Thanks Valery for your review! I balloted No objection (https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/ballot/ ). Francesca On 18/08/2021, 10:24, "art on behalf of Valery Smyslov via Datatracker" wrote: Reviewer: Valery Smyslov Review result: Ready I am the assigned ART directorate reviewer for this document. These comments were written primarily for the benefit of the ART area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes the technique called DNS Query Name Minimisation, which was originally defined in RFC 7816, and since then has been widely using in the Internet to improve privacy. The goal of this document is to replace RFC 7816 (which has an Experimental status) with a Standards Track RFC, adding some clarifications based on the experience of using this technique in the Internet. The DNS Query Name Minimisation doesn't change DNS protocol, it only defines the way the resolver constructs DNS queries, so the interoperability is preserved. The document is well written and easy to read. Nit: RFC 7626, referenced in the document, has been just obsoleted by RFC 9076. ___ art mailing list a...@ietf.org https://www.ietf.org/mailman/listinfo/art ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Francesca Palombini's No Objection on draft-ietf-dnsop-rfc7816bis-10: (with COMMENT)
Francesca Palombini has entered the following ballot position for draft-ietf-dnsop-rfc7816bis-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/ -- COMMENT: -- Thank you for the work on this document. Thanks to Valery Smyslov for the ART ART review, please address his comment with the next update: > Nit: RFC 7626, referenced in the document, has been just obsoleted by RFC > 9076. Francesca ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Tsvart last call review of draft-ietf-dnsop-dns-tcp-requirements-12
Reviewer: Mirja Kühlewind Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. Thanks for the well-written document! I have a couple of points below regarding the recommend TCP tuning in section 4. Other parts of the document don't seem to have any transport issues and are clear to me. 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. 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. 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! On section 4.4, maybe mention TCP fast open here again as well? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Zaheduzzaman Sarker's No Objection on draft-ietf-dnsop-rfc7816bis-10: (with COMMENT)
Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-dnsop-rfc7816bis-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/ -- COMMENT: -- Thanks for this document. I have one question - * what is a "full cache" as mentioned in the section 5? if not a well known term to describe a cache then please explain it shortly. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Doodle poll for DNSOP WG interim week 13-17 September 2021
Dear DNSOP WG, We are scheduling a DNSOP WG interim meeting in the week of 13-17 September. The following drafts are on the agenda: * dnsop-avoid-fragmentation * dnsop-glue-is-not-optional To select a date and time slot, we created a doodle poll. The authors of the drafts are in the US and Japan time zone, so the time slots available take this into account. https://doodle.com/poll/4gfit23w3ixrmgh8?utm_source=poll_medium=link Please fill in the doodle before the end of Monday (30 August). Thank you, Suzanne, Tim and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
