Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02
On Fri, Apr 17, 2020 at 6:20 AM Alessandro Ghedini wrote: > Hello, > > First off, I have started implementing support for SVCB and HTTPSSVC as > part of > the dnspython library [0] and I'd be interested in doing some interop > testing > with other people's implementations. > > I also have a few comments/questions about the draft, apologies if they > have > already been discussed in the past (haven't been following the draft from > the > start). > > 1. For interop testing purposes it would be very helpful if the draft > listed > commonly agreed upon code-points for the new RR types. Ideally in the form > of an > official early assignment from IANA, but if that's not possible picking a > couple > of codepoints at random from the "private use" range would also be > helpful. In > my implementation I'm currently using "65481" for SVCB and "65482" for > HTTPSSVC. > > 2. The structure of the draft is a bit odd, as it lists a bunch of examples > before introducing any of the records. This was a bit confusing to me, so > I'd > suggest moving sections 1.5 and 1.6 _before_ the examples (that is, > immediately > after the introduction). It might also be a good idea to just move the > examples > to an Appendix instead. > > 3. Would it make sense to move the ESNI/ECHO config paramenter to the > ESNI/ECHO > draft instead? This way the DNS draft wouldn't need to depend on the ESNI > draft > (so e.g. if ESNI ends up taking longer, this draft could be published > without > having to wait for it). > > 4. What is the point of differentiating between AliasForm and ServiceForm? > Like, > couldn't the draft just say that the SvcFieldValue is an optional field > and be > done with that? It seems like not having to explicitly differentiate the > two > cases would simplify the draft a bit without sacrificing much, though I > might > be missing something. > I think the stronger distinction makes it easier to describe the required behavior differences. Much simpler to just say things like don't mix both forms in the same response, and to ignore non-alias if any aliases are present, than to make more detailed descriptions about what specific optional contents are allowed to be mixed or not to accomplish the same thing. > > 5. Section 2.1.1 says > >The presentation format for SvcFieldValue is a whitespace-separated >list of elements representing a key-value pair, with an absent value >or "=" indicating an empty value. > > It took me longer than I'd like to admit to understand the "with an absent > value > or "=" indicating an empty value" part. I'd suggest rewording that > paragraph to > something like: > >The presentation format for SvcFieldValue is a whitespace-separated > list of >key=value pairs (e.g. "key123=value1 keys456=value2"). When the value, > or >both the value and the "=" are omitted, the value should be interpreted > as >being empty. > > Or something better :) > > 6. In Section 2.2 it says (in reference to param field values): > >o an octet string of the length defined by the previous field. > > It might be good to say here that the format of this octet string is > defined > according to the corresponding SvcParamKey, and then reference section 6 > for > ths currently defined keys. The same applies for section 2.1.1 for the > presentation format. > > 7. Section 4.3 says: > >All DNS servers SHOULD treat the SvcParam portion of the SVCB RR... > > Should it be SvcFieldValue instead of SvcParam? "SvcParam" is not mentioned > anywhere else. > > 8. Maybe I'm missing something, but the following sentence in Section 6.4 > seems > wrong: > >When SvcDomainName is ".", server operators SHOULD NOT include these > hints, >because they are unlikely to convey any performance benefit. > > My understanding is that ipv4hint and ipv6hint are the way to solve the > ESNI > multi-CDN problem, so let's say I have "www.example.net" that CNAMEs to > both > "cname.cdn-a.example" and "cname.cdn-b.example". A client queries both A > and > HTTPSVC concurrently for "www.example.net", and receives two answers (the > answer > to the A query points to CDN A, while the answer to HTTPSSVC points to CDN > B): > > www.xample.net 3600 IN CNAME cname.cdn-a.example > cname.cdn-a.example 3600 IN A 192.0.2.1 > > and > > www.xample.net 3600 IN CNAME cname.cdn-b.example > cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=h3 esniconfig="..." > > My understanding is that in this case the client could end up connecting to > 192.0.2.1 (CDN A) with CDN B's ESNI config (or e.g. with the wrong ALPN). > So if > the server doesn't provide IP hints there would indeed be impact on > performance > because the client would just straight up fail to connect initially (e.g. > maybe > CDN A doesn't support HTTP/3, but CDN B's HTTPSSVC says the client can use > it, > or just because of the wrong ESNI config). > > Long story short, I don't think the text should discourage setting > ipv4hint and > ipv6hint
Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind
On Apr 20, 2020, at 14:35, Dave Lawrence wrote: > > I support adoption, with the caveat that either the draft name should > be updated with something like s/powerbind/delegation-only-dnssec/, or > the draft should describe why it is being called "powerbind". The name was a joke. It is not used anyway in the document text on purpose and will not appear in the name when adopted. Paul > > ___ > 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] Call for Adoption: draft-pwouters-powerbind
I support adoption, with the caveat that either the draft name should be updated with something like s/powerbind/delegation-only-dnssec/, or the draft should describe why it is being called "powerbind". ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Call for Adoption: draft-pwouters-powerbind
All, As we stated in the meeting and in our chairs actions, we're going to run regular call for adoptions over next few months. >From the presentation during the last meeting, there was interest in adtoping this document around the idea of DNSSEC transparency. This interest comes the privacy side of things, more than the DNS side. This starts a Call for Adoption for draft-pwouters-powerbind The draft is available here: https://datatracker.ietf.org/doc/draft-pwouters-powerbind/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. We are looking for *explicit* support for adoption. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 4 May 2020 Thanks, tim wicinski DNSOP co-chair ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] The DNSOP WG has placed draft-pwouters-powerbind in state "Call For Adoption By WG Issued"
The DNSOP WG has placed draft-pwouters-powerbind in state Call For Adoption By WG Issued (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-pwouters-powerbind/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Document Action: 'Multi Signer DNSSEC models' to Informational RFC (draft-ietf-dnsop-multi-provider-dnssec-05.txt)
The IESG has approved the following document: - 'Multi Signer DNSSEC models' (draft-ietf-dnsop-multi-provider-dnssec-05.txt) as Informational RFC 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-multi-provider-dnssec/ Technical Summary The draft documents operational models for deploying DNSSEC signed zones across multiple DNS providers to distribute their authoritative DNS service. It presents challenges depending on the configuration and feature set in use, and presents several deployment models that may be suitable. Working Group Summary The document has been reviewed and discussed on the DNSOP mailing list and during DNSOP workgroup meetings. Contributions were done by a relative small number of interested folks, feedback by the WG was promptly integrated in the document. No points of difficulty or controversy appeared and consensus was quick. There has been good consensus during the WGLC period. External parties (DNS zone owners and DNS providers) have architected the DNSSEC multi-provider model in their operations and use it in their daily job (e.g., see DNSOP mailing list, email thread “[DNSOP] Working Group Last Call for draft-ietf-dnsop-multi-provider-dnssec”.) Document Quality The document is of good quality, and describes a real issue and (real world) operational advice on how to deal with this. The security section mentions the need for strong authentication to protect DNSSEC key material, but although the usefulness of the warning, this is beyond the scope of the document. The document shepherd has no specific concerns or issues with the document or with the WG process. The shepherd stands behind the document and thinks the document is ready for publication. Personnel Document Shepherd: Benno Overeinder Area Director: Warren Kumari ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft on delegation revalidation
Hi, I'm new to posting on this list, so please accept my advance apologies if I make any novice errors or posted this in the wrong place. Apologies also for the long email. :-) I can't claim to have the same detailed knowledge of the protocol as the authors of this draft. All the same, I've been mulling this child/parent-centric resolver question for a while and watching its impact on our customers and developers. This draft seems to resolve this question with the conclusion that child-centric (non-sticky?) is the correct behaviour. Shumon Huque: > There is a range of different behaviors in resolver implementations > in this respect today, and it would be good if we could agree on > more commonality. I agree. Having a predictable standard behavior (at least for recent, well-behaved resolvers) is very desirable. The recent thread on the DNS OARC list seemed to frame this question as a trade off mostly of these points: [a] https://tools.ietf.org/html/rfc2181#section-5.4.1 saying the in-zone NS is authoritative and more trustworthy. (pro: child-centric) [b] flexibility for DNS operators to lower the effective TTL on a delegation during changes despite registries fixing their TTL. (pro: child-centric) Paragraph 4 in https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01#section-2 [c] the additional complexity resolvers will have to bear (pro: parent-centric) [d] making resolution deterministic (pro: parent-centric) I'd like to draw attention to a fifth item which I haven't see addressed. [e] obeying the principle of least astonishment for mortal DNS operators who do not understand this subtlety (and who I assume are the overwhelming majority). (pro: parent-centric) The child-centric resolver behaviour applied by many resolvers today is probably clear to most who reads this list and DNS OARC. But it's very counter-intuitive to everyone else. In my experience the overwhelming majority of people operating DNS do not understand this very subtle point. They all tend to assume the parent-centric behaviour. Perhaps that's because many of them have a software developer background and are familiar with tree data structures and linked lists. Put another way, child-centric resolvers effectively insist on there being two sources of truth for a delegation, which is very surprising. My organization tends to operate with every team being enabled (and expected) to own their own service, including its DNS, so we have a lot of software developers and others who don't have time or inclination to read DNS RFCs and books dealing with DNS but still need to do it. We delegate domains at multiple levels to give people that autonomy. We're also a DNS vendor for many public customers. I've seen lots of outages and security issues either caused by or prolonged by people surprised by child-centric resolver behaviour. So much so, that I am inclined to prefer parent-centric. [a] seems like a definition which could be changed if it was so decided. DS records are totally parent centric for example. It seems like NS could be too if we declared the in-zone NS to be "informational only". I understand the desire for [b], but it seems to propose to dictate a specific behavior at every level of delegation in order to work around a problem that only exists with second level delegations (those managed by registries). In so doing, it optimizes for an arcane but admittedly useful flexibility that only a tiny minority of DNS operators will ever understand how to use. At the same time, we'd be standardizing on behavior that surprises the majority of operators and at times causes them (or at least leads them into) outages, even when they are working at a 3rd or 4th level delegation (ie not a registry). There are two categories of unfortunate "surprises" we commonly see due to child centric resolvers. The first surprise is that when redelegating a third level domain, it's obvious to moderately experienced operators that they must lower the parent NS TTL in order to get a fast rollback, but as they don't realise the in-zone NS takes over, they don't lower that TTL. Now their fast rollback plan is ineffective on child-centric resolvers. It's great to see in this draft that the "delegation revalidation" section of the draft seems to solve that sharp edge by choosing the minimum TTL at the delegation. If we conclude we must have child-centric behaviour, this at least makes it safer than today. But still the misunderstanding points to the surprising behaviour of child-centric resolvers. The second surprise category are a variety of subtle misconfigurations which we have seen at the in-zone NS which operators don't understand (copying the NS from the previous zone, altering the NS in an effort to get a full sideways delegation, just plain errors, etc). When we explain these problems, our customers say "but the child NS isn't used for delegation, what are you talking about?". "dig +trace" also ignores
Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2020-04-23
Dear DNSOP WG, We have added another agenda item to our interim meeting next Thursday: ### Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC - https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ - Dmitry Belyavsky, 15min - Chairs Action: The interim meeting therefore most likely runs until 16:15 UTC. You can add the DNSOP virtual interim meeting to your calendar: https://datatracker.ietf.org/meeting/interim-2020-dnsop-02/sessions/dnsop.ics See also https://datatracker.ietf.org/group/dnsop/meetings/ Best regards, Suzanne, Tim and Benno On 17/04/2020 15:57, IESG Secretary wrote: > The Domain Name System Operations (dnsop) Working Group will hold > a virtual interim meeting on 2020-04-23 from 17:00 to 18:00 Europe/Amsterdam > (15:00 to 16:00 UTC). > > Agenda: > # DNS Operations (DNSOP) Working Group > ## interim-2020-dnsop-02 > > * Date: 23 April 2020 > * Time: > * Webex: > > ### > * Jabber: dn...@jabber.ietf.org > * EtherPad: > > ### Chairs > * Tim Wicinski tjw.i...@gmail.com > * Suzanne Woolf suzworldw...@gmail.com > * Benno Overeinder be...@nlnetlabs.nl > > ### IESG Overlord > * Warren Kumari war...@kumari.net > > ### Document Status > * https://github.com/DNSOP/wg-materials/blob/master/dnsop-document-status.md > > ### Datatracker > * https://datatracker.ietf.org/wg/dnsop/documents/ > > # Agenda > > ## Administrivia > * Agenda Bashing, Blue Sheets, etc, 5 min > > ## Current Working Group Business > > ### YANG Types for DNS Classes and Resource Record Types > - https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ > - Ladislav Lhotka, 10 min > - Chairs Action: > > ### Interoperable Domain Name System (DNS) Server Cookies > - https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ > - Willem Toorop, 15min > - Chairs Action: How close to WGLC? > > > # > ## New Working Group Business > > ### DNS TIMEOUT Resource Record > - https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/ > - Tom Pusateri/Tim Wattenberg, 15 min > - Chairs Action: Adopt? > > ### Delegation Revalidation by DNS Resolvers > - https://datatracker.ietf.org/doc/draft-huque-dnsop-ns-revalidation/ > - Shumon Huque, 15 min > - Chairs Action: > > > # > ## Reference > > ### BlueSheets > > Attendees are asked to visit and enter your Name+Affiliation in the > Blue-Sheet section of the DNSOP Etherpad. > > ### Mic Line Queue > > The Mic Line will use the WebEx chat channel. To get in the queue type q+ to > leave type q-. > Please don't type questions or other things into the WebEx chat channel as > that will make > managing the queue very hard for the chairs. Please use the Jabber channel > for side conversations. > > When you connect into WebEx you should start off as auto-muted so you'll > need to unmute yourself to speak when called. > > ### Helpful Info & Prep > > The IETF has prepared a couple of documents to help get everyone ready. > > https://www.ietf.org/how/meetings/107/session-participant-guide/ > > https://www.ietf.org/how/meetings/107/session-presenter-guide/ > > Information about remote participation: > https://ietf.webex.com/ietf/j.php?MTID=m8d49e59807a47eec1d8cf5fbd4f81fa3 > > ___ > 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
