Re: [DNSOP] Call for Adoption: draft-huque-dnsop-ns-revalidation
On Tue, Jun 2, 2020 at 8:20 PM Shumon Huque wrote: > > On Tue, Jun 2, 2020 at 12:09 PM Daniel Migault wrote: >> >> Hi, >> >> I support the adoption of the document. >> draft-ietf-dnsop-dnssec-validator-requirements-00 [1] references this >> document and would like it to become a standard. >> >> I suspect that many felt that [2] had a flavor of call for adoption. I was >> myself surprised to see the call for adoption. >> I support adoption of the draft and i'm willing to review. >> Yours, >> Daniel >> >> >> [1] https://mailarchive.ietf.org/arch/msg/dnsop/fXmzHFzh153OO01hA5Oq8-T-fO8/ >> [2] >> https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-validator-requirements-00 >> > > With the disclaimer that I'm a co-author, I also support adoption of > draft-huque-dnsop-ns-revalidation. > > To answer Daniel's question, the first thread was where I introduced the > draft on the mailing list. Although the DNSOP chairs chimed in and asked for > general review there, it was not an official call for adoption. Tim's message > that we are responding to now is the adoption call. > > Shumon. > > ___ > 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] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.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 : Glue In DNS Referral Responses Is Not Optional Author : M. Andrews Filename: draft-ietf-dnsop-glue-is-not-optional-00.txt Pages : 5 Date: 2020-06-03 Abstract: The DNS uses glue records to allow iterative clients to find the addresses of nameservers that live within the delegated zone. Glue records are expected to be returned as part of a referral and if they cannot be fitted into the UDP response, TC=1 MUST be set to inform the client that the response is incomplete and that TCP SHOULD be used to retrieve the full response. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-glue-is-not-optional-00 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-glue-is-not-optional-00 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
Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis
On Wed, Jun 3, 2020 at 2:07 PM Tim Wicinski wrote: > > 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. > We are looking for *explicit* support for adoption. > > I support adoption, and am willing to review. Brian > > This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis > > The draft is available here: > https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ > > 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. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 15 June 2020 > > Thanks, > tim wicinski > DNSOP co-chair > > > > ___ > 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-belyavskiy-rfc5933-bis
On Wed, Jun 3, 2020 at 5:07 PM Tim Wicinski wrote: > > 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. > We are looking for *explicit* support for adoption. > I support adoption. Some background: The authors of this has asked me to AD sponsor it, but I felt it was much better to have it progress through the normal IETF / DNSOP process, and so I asked them to bring it here, but my support for adoption should be viewed like any other... W > > > This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis > > The draft is available here: > https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ > > 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. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 15 June 2020 > > Thanks, > tim wicinski > DNSOP co-chair > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis
On Wed, 3 Jun 2020, Tim Wicinski wrote: As we stated in the meeting and in our chairs actions, we're going to run regular call for adoptions over next few months. We are looking for *explicit* support for adoption. This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis I support adoption, willing to review and contribute txt. Note, the DS in the example in section 4.1 seems to be using 5 as the assigned number, but this should probably be a TBA2 for now :) Unless, an early code point has already been assigned, and looking at the iana table the next available value is indeed 5 :) Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis
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. We are looking for *explicit* support for adoption. This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis The draft is available here: https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ 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. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 15 June 2020 Thanks, tim wicinski DNSOP co-chair ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
All The call for adoption ended on monday and this has enough consensus to be adopted by the working group. tim On Thu, May 21, 2020 at 9:36 PM Paul Vixie wrote: > On Friday, 22 May 2020 00:31:34 UTC Masataka Ohta wrote: > > ... > > > > While I'm not against the clarification, the draft should mention > > that rfc1034 already states: > > > > To fix this problem, a zone contains "glue" RRs which are not > > part of the authoritative data, and are address RRs for the servers. > > These RRs are only necessary if the name server's name is "below" the > > > > cut, and are only used as part of a referral response. > > ^ > > > > which means the glue RRs are necessary for a referral response. > > Though not very obvious, it logically means that they MUST be > > included as part of a referral response, because it is the only > > reason to make them necessary. > > i agree. this is why later versions of BIND would return referrals rather > than > answers when queried for these names, which were in-bailiwick but > below-zone. > by implication, they can only be retrieved from the delegating server as > part > of a referral, and they will be in the additional section not the answer > section even though they do match the qname. this distinction is also > necessary in the assignment of credibility levels in the downstream cache. > > -- > 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-huque-dnsop-ns-revalidation
> On Jun 3, 2020, at 2:38 PM, Stephane Bortzmeyer wrote: >> This starts a Call for Adoption for draft-huque-dnsop-ns-revalidation > > I think it addresses a real problem, I think it is a good start for a > draft, and I'm willing to review it. (In other words: I support > adoption.) I agree. This seems like a very reasonable approach to a real problem. I also support adoption. -Bill signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-huque-dnsop-ns-revalidation
On Sun, May 24, 2020 at 05:51:24AM -0400, Tim Wicinski wrote a message of 61 lines which said: > This starts a Call for Adoption for draft-huque-dnsop-ns-revalidation > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huque-dnsop-ns-revalidation/ I think it addresses a real problem, I think it is a good start for a draft, and I'm willing to review it. (In other words: I support adoption.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] questions about Signaling Cryptographic Algorithm Understanding (RFC 6975)
Hi dnsop, it seems that OpenDNS is the first to implement RFC 6975: https://lists.dns-oarc.net/pipermail/dns-operations/2020-June/020219.html This reminded me of its existence so I looked at definition for validating recursors: 4.2.1. Validating Recursive Resolvers A validating recursive resolver sets the DAU, DHU, and/or N3U option(s) when performing recursion based on its list of algorithms and any DAU, DHU, and/or N3U option lists in the stub client query. When the recursive server receives a query with one or more of the options set, the recursive server MUST set the algorithm list for any outgoing iterative queries for that resolution chain to a union of the stub client's list and the validating recursive resolver's list. For example, if the recursive resolver's algorithm list for the DAU option is (3, 5, 7) and the stub's algorithm list is (7, 8), the final DAU algorithm list would be (3, 5, 7, 8). If the client included the DO and Checking Disabled (CD) bits, but did not include the DAU, DHU, and/or N3U option(s) in the query, the validating recursive resolver MAY include the option(s) with its own list in full. If one or more of the options are missing, the validating recursive resolver MAY include the missing options with its own list in full. What is your opinion on: a) Sending RFC 6975 EDNS options with queries which target zone cuts which are not signed (DS provably not present in parent)? That sounds like waste of bytes, but maybe it is not worth optimizing. Opinions? b) It is not clear if/how authors took into account deduplication of queries: the recursive server MUST set the algorithm list for any outgoing iterative queries for that resolution chain to a union of the stub client's list and the validating recursive resolver's list. Multiple queries from stubs can translate to a single upstream query. Typically this happens for very frequently asked names on cache miss event. E.g. many stubs ask "www.google.com " but recursor can optimize traffic upstream and send only single query to auth. Of course stub queries will likely not arrive simultaneously so the first query to auth (possibly with union of algo sets) is already in flight when second stub query (possibly with diffent set) arrives. Now what? (Section 7. Traffic Analysis Considerations shifts the problem to oneone else, but I think deduplication trick + interaction with DNS cache should be pointed out because it significantly complicates analysis.) c) Is union of sets even a good idea? Why not copy ENDS options from stub and append _another_ "instance" of options so the auth can see there are multiple parties with different set of options? d) Is there a risk of inflating queries too much/new attack vector? What about stub sending EDNS option with all alg fields present (700+ bytes)? Should there be a limit on number of algs? (I cannot see any in the RFC.) e) What should happen if multiple options are present? Answer with FORMERR? (But see questions c,d above.) Thank you for opinions! P.S. Sorry for opening this topic again, but this seems like another example of RFC which would benefit from more implementation experience prior publication. -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-00.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-00.txt Pages : 11 Date: 2020-06-03 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-dns-catalog-zones-00 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-catalog-zones-00 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
