Re: [DNSOP] Call for Adoption: Compact Denial of Existence in DNSSEC
All The call for adoption has ended with consensus to adopt this work. Thanks for the feedback. We'll work with the authors on a version with the updated aame, and in a few weeks we are considering another drafts - send suggestions to the chairs. thanks tim On Sun, Apr 16, 2023 at 8:53 PM Tim Wicinski wrote: > > Happy Monday (UTC) All, > > The chairs heard some strong support to adopt and work on this. > > This starts a Call for Adoption for draft-huque-dnsop-compact-lies > > The authors did do some updates in the draft around the "lies" moniker. > Once adopted perhaps someone can suggest a better draft name. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huque-dnsop-compact-lies/ > > 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: April 29, 2023 > > Thanks, > tim wicinski > For DNSOP co-chairs > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: Compact Denial of Existence in DNSSEC
On Wed, Apr 26, 2023 at 8:43 AM Shumon Huque wrote: > I support adoption too. > > Me too. Support. Happy to review or contribute. (Not a lie.) Brian > As I've mentioned earlier, this mechanism is widely deployed and needs a > published specification. Adopting the work will also allow us to formally > specify an accurate NXDOMAIN signal (and work out its related details more > fully). > > Shumon. > > On Sun, Apr 16, 2023 at 8:54 PM Tim Wicinski wrote: > >> >> Happy Monday (UTC) All, >> >> The chairs heard some strong support to adopt and work on this. >> >> This starts a Call for Adoption for draft-huque-dnsop-compact-lies >> >> The authors did do some updates in the draft around the "lies" moniker. >> Once adopted perhaps someone can suggest a better draft name. >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-huque-dnsop-compact-lies/ >> >> 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: April 29, 2023 >> >> Thanks, >> tim wicinski >> For DNSOP co-chairs >> ___ >> 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] WGLC rfc8499bis one week extension for lame delegation definition
I prefer option 2. I think it fulfills the implicit obligations inherent in 1) -which would be to fill the hole of uncertainty. Its succinct, and it covers the cases I think define the condition. I would ask if 2) also needs to define ".. or cannot be resolved" because "[or not at all]" is a bit wide to encompass "that FQDN didn't actually resolve" for a listed NS. As it stands it seems to terminate in a belief you have something to ask. It's equally lame to be pointed to this.name.hasnt.been.delegated.alt. as an NS Irrespective I prefer 2). I don't like the dangling fate of 1) I think the lack of agreement is only conditionally true: I think we could reach consensus on 2) if we tried a bit harder. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
(speaking as a chair) On Thu, Apr 27, 2023 at 5:22 PM John R Levine wrote: > On Thu, 27 Apr 2023, Miek Gieben wrote: > >> I think it's an interesting idea but I also don't want to spend time on > it > >> if it's just going to be filed and forgotten. > > > > I looked into this for https://github.com/miekg/dns > > > > The option is trivial to implemented (in an auth server). I.e. seems > similar > > to NSID. > > I agree that it's not hard to do. But the Camel reminds us that there is > an unlimited number of hacks that would be easy to implement, but not > necessarily that anyone would use. Hence my question about whether > anyone's implemented it. > ' John While you are correct on remembering the camel, the "OP" part of DNSOP stands for "Operations" (DNSOP for the Operators!), I try to judge new work with a another question "does this make it easier for operators to deploy and benefit from?" (now speaking as myself) In this case I do feel this would be useful and will be used by operators. And more so than ZoneMD, because as George point, it's a different class of checks. tim > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
On Thu, 27 Apr 2023, Miek Gieben wrote: I think it's an interesting idea but I also don't want to spend time on it if it's just going to be filed and forgotten. I looked into this for https://github.com/miekg/dns The option is trivial to implemented (in an auth server). I.e. seems similar to NSID. I agree that it's not hard to do. But the Camel reminds us that there is an unlimited number of hacks that would be easy to implement, but not necessarily that anyone would use. Hence my question about whether anyone's implemented it. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] WGLC rfc8499bis one week extension for lame delegation definition
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://mailarchive.ietf.org/arch/msg/dnsop/4E1AQKGivEHtJDB85gSNhofRuyM/): "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://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
[ Quoting in "Re: [DNSOP] WGLC for draft-ietf-dns..." ] It appears that Suzanne Woolf said: Colleagues, This email begins a Working Group Last Call for draft-ietf-dnsop-zoneversion-02 (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). If you've reviewed this document and think it's ready for publication, please let us and the WG know, by responding on-list to this message. We particularly need to hear from implementers and operators whether this EDNS option is implementable and useful. If you don't think it's ready, and have specific concerns or suggestions, please let us know about those too. Since it's a year old, has anyone implemented it beyond the one server listed in the draft? I think it's an interesting idea but I also don't want to spend time on it if it's just going to be filed and forgotten. I looked into this for https://github.com/miekg/dns The option is trivial to implemented (in an auth server). I.e. seems similar to NSID. "Resolver and forwarder behavior is undefined" is too weak IMO, and should point to the hop-by-hop nature for EDNS0 options, are explicitly say what's expected here wrt to this option. /Miek -- Miek Gieben ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] John Scudder's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT)
On Wed, Apr 26, 2023 at 5:18 PM, John Scudder wrote: > John Scudder has entered the following ballot position for > draft-ietf-dnsop-alt-tld-23: 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/about/groups/iesg/statements/ > handling-ballot-positions/ for more information about how to handle > DISCUSS and COMMENT positions. > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ > > -- > COMMENT: > -- > > One comment -- Section 3.2 has "DNS server operators MAY be aware that > queries for name ending in .alt are not DNS names, and queries for those > names were leaked into the DNS context." The RFC 2119 MAY appears misused > in this context. > > (Also, in that quote, s/queries for name/queries for names/) > Fair 'nuff - fixed in PR. W ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
It appears that Suzanne Woolf said: >Colleagues, > > >This email begins a Working Group Last Call for >draft-ietf-dnsop-zoneversion-02 >(https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). > >If you've reviewed this document and think it's ready for publication, please >let us and the WG know, by responding on-list to this message. We particularly >need to hear >from implementers and operators whether this EDNS option is implementable and >useful. > >If you don't think it's ready, and have specific concerns or suggestions, >please let us know about those too. Since it's a year old, has anyone implemented it beyond the one server listed in the draft? I think it's an interesting idea but I also don't want to spend time on it if it's just going to be filed and forgotten. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
On Wed, Apr 26, 2023 at 23:07, Suzanne Woolf <[swo...@pir.org](mailto:On Wed, Apr 26, 2023 at 23:07, Suzanne Woolf < wrote: > This email begins a Working Group Last Call for > draft-ietf-dnsop-zoneversion-02 > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). > > If you've reviewed this document and think it's ready for publication, please > let us and the WG know, by responding on-list to this message. We > particularly need to hear from implementers and operators whether this EDNS > option is implementable and useful. > > If you don't think it's ready, and have specific concerns or suggestions, > please let us know about those too. > > The Last Call will be two weeks, ending on Thursday 11 May. As I think I have said before, I like this idea and I think it is genuinely useful. The draft is well-written and mainly clear but I have some observations. I think some additional work would be beneficial before we raise the draft up the IESG flagpole. In section 1 I see "Resolver and forwarder behaviour is undefined". However, in section 3.2 the specification says that if various conditions (including "server that is authoritative for the zone") are not met, the answer "MUST NOT add an EDNS ZONEVERSION option to the response". This seems inconsistent; 3.2 in fact does in fact seem to define the required behaviour for at least some resolvers and forwarders (those that are not also authoritative servers). The draft refers to "the zone" in various places, as in one of the sentences quoted above. I think it's fairly obvious what this means, but I don't think it would hurt to be a little more specific about it. After all, if the whole point is to identify something specific about a zone, wouldn't it be good to be clear about which zone we are talking about? Should the option included in responses include the identity of the zone explicitly? For example, suppose I am doing a recursive lookup on an empty cache. I send a query to a root server with the EDNS ZONEVERSION option and get a referral response. Is it reasonable for that response to include a version token for the root zone in its response? Is it sufficiently obvious to the receiver of such a response which zone's version is being returned? The draft contains phrases like "QNAME belongs to an authoritative zone of the server" which I also feel has the potential to be misunderstood. The idea of omitting the option in a response which also includes the SOA serial seems problematic. I feel like this could mask various kinds of implementation problems, and an explicit signal might be better. For example, what about the case where the SOA serial does not represent the zone version, and the response is omitted by error, e.g. because a member of an anycast cluster is badly configured? That should be interpreted by the receiver as a missing response option, not as a new version number that can safely be processed and compared with others. How would the receiver of the response know to do this? I fully confess I haven't thought about this in detail, but I think there are some lurking dragons here. Happy to suggest text around these various points if there is some kind of consensus that these are things that would merit from attention. Again, great idea though. I do like it and would definitely use it if it existed. Joe >___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
