Re: [DNSOP] [v6ops] New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt

Hi again, On Oct 16, 2022, at 13:09, Momoka Yamamoto wrote: > [...] However, we thought that in theory (but maybe not currently) an > iterative resolver is the only application that actually needs IPv4 to > operate. I'm interested in this perspective. My feeling is that it's far more

Re: [DNSOP] [v6ops] New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt

Hi there, On Oct 8, 2022, at 13:58, Momoka Yamamoto wrote: > re: Mark Andrews 's comments > > this is yet another example of why DNS64 should be made historic. > > This is requesting even more support to work around problems introduced by > > DN64, a poorly thought out, supposedly short term

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

Fujiwara-san, On Sep 22, 2022, at 11:05, Kazunori Fujiwara wrote: > Thanks. "Path MTU Disovery" API and setting IP_DF API are complex and > they often don't work as expected. > > However, it may be easy to avoid using the Fragment Header on IPv6. > (limit IPv6 response packet smaller than

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

On Aug 24, 2022, at 11:27, Schanzenbach, Martin wrote: > We (I) learned that this is a good approach after conversations with our > reviewers in particular since it is very difficult to distinguish what "case" > actually is with respect to i18n. Fortunately (at least as far as understanding

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

On Aug 24, 2022, at 10:13, Joe Abley wrote: > That's a large installed base of assumptions; to a close approximately it's > all users of the internet and all software that makes use of it. Approximation, not approximately. My phone and I have different ideas about language, soapy about

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

Hi Peter, On Aug 24, 2022, at 09:40, Peter Thomassen wrote: > On 8/23/22 18:37, Joe Abley wrote: >> So your suggestion is that this document should specify behaviour for QNAMEs >> whose final label is exactly "alt" but that names with different >> capitalisat

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

On Aug 23, 2022, at 18:07, Peter Thomassen wrote: > Unaware applications: yes, perhaps mixed; but as they're unaware, they'll > ignore the carve-out regardless of case > > Aware applications: ... will produce only what's compliant. And the question > here is what we want to define as

Re: [DNSOP] draft-ietf-dnsop-alt-tld-17

On Aug 23, 2022, at 16:03, Schanzenbach, Martin wrote: > " > > This document uses ".alt" for the pseudo-TLD in the presentation > format for the DNS, corresponding to a 0x03616c7400 suffix in DNS > wire format. The presentation and on-the-wire formats for non-DNS > protocols

Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

On Aug 16, 2022, at 16:15, Schanzenbach, Martin wrote: > And this is why there must be a registration policy and process. If that's really where this conversation has landed, then perhaps it's worth pointing out again that a variety of such registration policies and processes already exist,

Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

On Aug 8, 2022, at 08:08, Christian Huitema wrote: > The name space is "almost" unitary. People deploy things like domain suffix > search lists so that users can type "mailserver" and arrive at > "mailserver.corp.example.com" -- or something else, depending where they > started for. There

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

Hi Andrew, On Aug 4, 2022, at 15:33, Andrew McConachie wrote: > I apologize for derailing this conversation by bringing up NAT. My point was > that the document makes a claim that PMTUD ‘remains widely undeployed due to > security issues’. Yet it makes no reference to anything that might back

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

On Aug 2, 2022, at 10:26, Independent Submissions Editor (Eliot Lear) wrote: > On 02.08.22 09:56, Joe Abley wrote: >> >> If the position of the ISE is to ignore the prior discussion and publish one >> set of opinions regardless then perhaps it would be more straightforwa

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

Hi Eliot, On Aug 2, 2022, at 07:59, Independent Submissions Editor (Eliot Lear) wrote: > But what is not reasonable to expect researchers to attempt to enter the > ICANN arena in order to facilitate a the safe use of a new naming system that > doesn't require use of the DNS. This argument

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

On Aug 1, 2022, at 15:58, Ben Schwartz wrote: > I think we already have such a mechanism: ICANN. People who want unique > registrations can acquire them via the existing ICANN and registry processes. I think we have been around and around these arguments at the ietf and in various parts of

Re: [DNSOP] The DO bit - was Re: [Ext] Re: signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)

On Jul 29, 2022, at 16:49, Paul Wouters wrote: > Interesting history, > > I would have expected (and have taught) that this was by design to not > disrupt systems with new data unless we knew they were ready for it. I didn’t > realize we first tried to do it without that  By the time we

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

Hi Andrew, On Jul 29, 2022, at 11:14, Andrew McConachie wrote: > We don’t need a useful standard for NAT to recognize that most > implementations break PMTUD, and that those implementations of NAT are > deployed enough to make PMTUD significantly broken. I was really just suggesting that

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

On Jul 28, 2022, at 12:24, Andrew McConachie wrote: > PMTUD doesn’t work through NAT That's a very definitive statement considering that there's no useful standard for NAT. If there's actual research on this to demonstrate that, pragmatically speaking, no implementations use the payload of a

Re: [DNSOP] signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)

On Jul 26, 2022, at 15:29, Ólafur Guðmundsson wrote: > Parent is authoritative for the existence of the delegation > Child is authoritative for the contents of the delegation > > DNS design did not take this into account thus there is no "range" of Parent > only records, > DS is the only

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-06.txt

On Jul 8, 2022, at 08:50, Bob Harold wrote: > I thought the catalog zone was required to be a valid zone. I think it might be worth exploring what "valid zone" might mean. All consumers of catalogue zones digest the whole zone as an atomic unit; they don't retrieve it piecemeal or walk the

Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

On Jun 27, 2022, at 13:40, Peter Thomassen wrote: > Thinking about it, perhaps there's no reason for normative language here. If > others agree, please let me know and I'll change to lowercase "should". If you are going to downgrade the requirement, MAY seems better than should, perhaps

Re: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation

On Mar 25, 2022, at 18:36, Benno Overeinder wrote: > 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. I think it's clear that there are people who want to do this, I think a standard approach is important

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt

On Apr 7, 2022, at 21:10, Paul Vixie wrote: > but it seems to me you'd be better off with a zero-length option called > SERIAL which if set in the query causes the SOA of the answer's zone to be > added to the authority section (similar to an RFC 2308 negative proof) and > which option would

Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping

On Mar 25, 2022, at 16:28, Benno Overeinder wrote: > With this email we start a period of two weeks for the call for adoption of > draft-thomassen-dnsop-dnssec-bootstrapping on the mailing list. > > The draft is available here: >

Re: [DNSOP] DNSSEC as a Best Current Practice

On Mar 22, 2022, at 10:06, Masataka Ohta wrote: > Bjorn Mork wrote: > >>> Plain DNS with long enough message ID is secure enough. >> Hello! >> Can you please point me to the set of RFCs (or draft) which describes >> this "secure enough" alternative to DNSSEC? > > As I wrote "rely on DNS

Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-02.txt

On Mar 9, 2022, at 00:12, Shumon Huque wrote: >> This document looks good. Some comments: >> >> In fact, the Extensible Provisioning >> Protocol (EPP) [RFC5731], that is often used by TLDs to configure >> delegation parameters has no provision to set the TTL. This inhibits >> a

Re: [DNSOP] Another attempt at consensus on the bailiwick discussion

On Dec 15, 2021, at 18:11, Brian Dickson wrote: > Overly-pedantic clarification on wording/semantics: > Glue is non-authoritative data in a zone, where the owner name of that glue > data is below some zone cut (or otherwise out-of-zone, like different-TLD, if > that is even permitted by the

Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)

On 29 Nov 2021, at 14:56, Paul Hoffman wrote: > On Nov 29, 2021, at 11:48 AM, Joe Abley wrote: >> The idea of modifying the protocol to accommodate namespaces outside the DNS >> is causing me to throw up in my mouth a bit, to be honest. Perhaps the DNS >> could just

Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)

Hi Peter, On 29 Nov 2021, at 14:25, Peter van Dijk wrote: > On Mon, 2021-11-29 at 14:16 -0500, Paul Wouters wrote: >> On Mon, 29 Nov 2021, RFC Errata System wrote: >> >>> Original Text >>> - >>> 5. Authoritative DNS Servers: Authoritative servers MUST respond to >>> queries

Re: [DNSOP] Deprecating infrastructure .INT domains

On Nov 12, 2021, at 08:28, Masataka Ohta wrote: > Kim Davies wrote: > >> Datatracker link: https://datatracker.ietf.org/doc/draft-davies-int-historic/ >> It’s a short document, but at its heart we’ve identified the >> following domains that are referenced in places but seem to be obsolete: >

Re: [DNSOP] Deprecating infrastructure .INT domains

Hi Kim, I like the idea of cleaning this up. Choosing nsap.int as an example, I think it would be useful to either update RFC 1706 to make it clear that the advice in section 6 of that document no longer applies, and that no reverse mapping for NSAP is provided in the DNS. I don't think this

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

On Nov 8, 2021, at 17:35, Wessels, Duane wrote: > Is this better? > > The use of TLS places even stronger operational burdens on DNS > clients and servers. Cryptographic functions for authentication and > encryption requires additional processing. Require, not requires. I know, I know.

Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

On Nov 3, 2021, at 08:49, Joe Abley wrote: > If there is any concern about DoH not receiving equitable treatment compared > to DoT, I think it's sufficient simply to observe that DoH is a horse of a > different colour and move on. (Those who are not familiar with that final phr

Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

On Nov 2, 2021, at 16:00, Roman Danyliw wrote: > I believe that if this draft is going to be the BCP to discuss DNS over TCP, > all of the flavors of DNS over TCP need to be covered. I think it's sloppy to characterise DoH as a flavour of DNS over TCP, given that the H part doesn't

Re: [DNSOP] Question on interpretation of DO and CD

On Oct 7, 2021, at 10:43, Brian Dickson wrote: >> Do you mean reliably determine if a resolver is claiming to validate, or >> reliably determine whether a resolver is actually validating? >> > Claiming… if the answer is that it is not claiming that, it might simplify > some parts of the logic

Re: [DNSOP] Question on interpretation of DO and CD

On Oct 7, 2021, at 09:49, Brian Dickson wrote: > Quick question in a top-reply, sorry: > Mark: > Is there any combination of flag bits or EDNS options that a stub can use to > reliably determine if a resolver is validating? Do you mean reliably determine if a resolver is claiming to validate,

Re: [DNSOP] [Ext] SHA-1 DS algo in arpa. :)

Hi Paul (W), On Sep 9, 2021, at 12:05, Paul Wouters wrote: > On Thu, 9 Sep 2021, Paul Hoffman wrote: >> >> Did you first ask the administrators of the zone in question before sending >> this message to a grooup that has no administrative power over the zone? > > No, I used this group as the

Re: [DNSOP] [Ext] DS glue for NS draft

On Aug 18, 2021, at 15:29, Brian Dickson wrote: > I'd be interested in pointers if consolidation by authority operators is a > privacy concern. Authority operators only see traffic from resolvers, not > from end users, and all of the data served is by definition public. This is a bit of a

Re: [DNSOP] [Ext] DS glue for NS draft

On Aug 16, 2021, at 19:41, Brian Dickson wrote: >> On Mon, Aug 16, 2021 at 3:14 PM Ben Schwartz wrote: >> >> [...] This thread makes me think draft-jabley-dnsop-refer wasn't as insane and operationally complex as I thought. Joe___ DNSOP mailing

Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

On Aug 12, 2021, at 16:53, Paul Wouters wrote: > On Thu, 12 Aug 2021, Joe Abley wrote: > >> I think the set of acceptable algorithms is constrained sufficiently often >> by registries and registrars that it makes little sense to consider any >> other case. > >

Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

Hi Paul, On 12 Aug 2021, at 15:48, Paul Wouters wrote: > On Thu, 12 Aug 2021, Joe Abley wrote: > >>> This would have been excellent to do when we did DS. It would still be >>> good to do this now, I agree. But it would be too late for some of the >>> things d

Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

On Aug 12, 2021, at 10:57, Paul Wouters wrote: > On Thu, 12 Aug 2021, Olafur Gudmundsson wrote: > >> The DS record is a unique record that it lives only at the parent side of >> delegation, when DNS was defined no such records were >> envisioned, if more are needed this working should take up

Re: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld

Hi Paul, On Jul 30, 2021, at 14:55, Paul Wouters wrote: > We literally had a survey to ask us “what should we kill because we don’t > have enough time” I don't think that's exactly the question I saw, but perhaps I misremember. For what it's worth (and as you know from our conversations

Re: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld

Hi Paul, On Jul 30, 2021, at 14:29, Paul Wouters wrote: > We are seeing the WG dropping actual protocol work because of these > discussions. I now consider these discussions harmful. I think we've seen the working group drop particular proposed efforts for a variety of reasons. I don't think

Re: [DNSOP] IETF 111 DNSOP WG session II agenda updated

Hi Peter, On 29 Jul 2021, at 14:39, Peter van Dijk wrote: > On this version, I see under New Working Group Business a draft (the > black lies sentinel) that was posted two days ago. Can somebody please > explain to me what the purpose of the draft cutoff is, if drafts can > appear in the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

On Jul 28, 2021, at 14:00, Paul Wouters wrote: > If the zone example contains amongst other content: > > foo.example. IN NS ns0.foo.example. > foo.example. IN NS ns0.bar.example. > ns0.foo.example. IN A 1.2.3.4 > ns0.bar.example. IN A 1.2.3.5 > > Then for the DNS server returning an NS query

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

Hi Paul, On Jul 28, 2021, at 10:13, Paul Wouters wrote: > Do you want dns servers to spend extra CPU power to lookup whether this is a > “non-functional” glue case instead of spending less CPU just looking if it > has a glue record and adding it? I'm not sure I understand your argument about

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

On Jul 28, 2021, at 07:51, Ralf Weber wrote: > On 28 Jul 2021, at 5:10, Paul Wouters wrote: > >> First, as Mark said, sibling glue is sometimes needed. > It is only needed for broken circular dependancies, which we don’t care about. I tend to agree with this. There are a lot of ways a

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

On 27 Jul 2021, at 16:15, John Levine wrote: >> * Section 5: Promoted or orphan glue >> The considerations for handling orphan glue will be different for a >> TLD vs a lower level zone within a domain. I would think that orphan >> glue in a TLD context should go away when a zone is

Re: [DNSOP] IETF meeting prep and what

On 30 Jun 2021, at 14:59, Peter van Dijk wrote: > I feel that the right mechanism for root key distribution is software > distributors. This is working fine for the CA system, and with keys announced > far enough in advance, should work fine for DNSSEC. Software distributors > have solved

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt

On 24 Jun 2021, at 19:21, John R Levine wrote: >>> I'd also like it to say more clearly up front that .ALT is for names that >>> are >>> totally outside the DNS protocols, not for names handled locally using DNS >>> protocols. >>> It's for things like .onion, not like .local. >> >> Both

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt

On Jun 24, 2021, at 14:37, John Levine wrote: > It appears that Ben Schwartz said: >> I think the "Privacy Considerations" section should probably mention QNAME >> minimization, which ought to help a little. > > I'd also like it to say more clearly up front that .ALT is for names that are >

Re: [DNSOP] IETF meeting prep and what

On 23 Jun 2021, at 12:28, Vladimír Čunát wrote: > On 18/06/2021 19.40, Peter van Dijk wrote: > >> I propose replacing rfc5011-security-considerations with a short document >> deprecating 5011 in its entirety. I am happy to write text for that, if >> there is an appetite - when the WG queue is

Re: [DNSOP] IETF meeting prep and what

On Jun 18, 2021, at 16:36, Paul Wouters wrote: > Sure, but if we were to deprecate 5011, what would we expect to happen > when we want to do another rollover ? To be more clear, I was *not* suggesting that 5011 should be deprecated. Joe ___ DNSOP

Re: [DNSOP] IETF meeting prep and what

On 18 Jun 2021, at 14:45, Paul Wouters wrote: > On Jun 18, 2021, at 13:41, Peter van Dijk wrote: > >> I propose replacing rfc5011-security-considerations with a short document >> deprecating 5011 in its entirety. > > Eh? 5011 is baked into various software. Why would replace 5011 ? > > Did

Re: [DNSOP] Call for Adoption: draft-salgado-dnsop-rrserial

Hi Hugo, On 1 Jun 2021, at 10:05, Hugo Salgado wrote: > On 13:20 01/06, Peter van Dijk wrote: > >> I like this. I suspect defining it well for answers from resolvers to >> clients would open up a big can of worms that could kill the draft, >> like many other drafts that have been crushed under

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On 12 May 2021, at 17:39, John Levine wrote: > It appears that Joe Abley said: > >> Do you know of an example of a DNS authoritative or recursive server that >> does return truncated RRSets in the ANSWER section? > > A lot return truncated glue in the ADDITION

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On 12 May 2021, at 17:03, Eric Orth wrote: > On Wed, May 12, 2021 at 4:28 PM Brian Dickson > wrote: > >> Responses including partial RRsets are as unlikely (and as illegal) as a >> response to a query for SVCB being a TXT record saying "I'm a teapot". > > Agreed that there is no such issue

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On 11 May 2021, at 12:32, Ben Schwartz wrote: > On Tue, May 11, 2021 at 9:20 AM Joe Abley wrote: >> On 11 May 2021, at 12:08, Ben Schwartz >> wrote: >> .. >>> * It saves at least 11 bytes of overhead per parameter by avoiding >>> repetition of >>&

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi Ben, On 11 May 2021, at 12:08, Ben Schwartz wrote: > OK, I've proposed text documenting the reasoning here: > https://github.com/MikeBishop/dns-alt-svc/pull/323/files > . I definitely appreciate the effort, since I think I agree

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi Ben, On 10 May 2021, at 12:56, Ben Schwartz wrote: > I don't support breaking the SvcParams into separate RRs across the RRSet. > This would be an extremely inefficient encoding in wire format, I think that assertion may well be worth challenging, and... > and would conflict with the

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

Hi Vladimir, On 10 May 2021, at 04:32, Vladimír Čunát wrote: > On 10. 05. 21 10:19, Petr Špaček wrote: >> I think the proper solution should be a real multi-query option, which >> incidentally provides a superset of RRSERIAL capabilities. > > If multi-queries require the records being in sync

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Hi Pieter, On 10 May 2021, at 11:23, Pieter Lexis wrote: > You then invite the following issues: > > Clients need to match the tuple (ownername + prio + target) and get all > data from all matched rrsets, whereas now you get all that data in one > piece of rdata. Inviting that issue is also a

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On May 10, 2021, at 05:42, Pieter Lexis wrote: >> On 5/9/21 2:01 PM, Dick Franks wrote: >> Pre-processing of '\\,' into the RFC1035 standard '\,' is >> superficially attractive, but also fraught with danger. >> >> A parser could have some fun with this one: >> >>$ORIGIN example.com >>@

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On May 9, 2021, at 19:27, Paul Hoffman wrote: > If I'm wrong about this being as good as it can be, there must be an item > delimiter that is better than a comma. I am not thinking creatively enough to > figure out what might be better than a comma. I'd be happy to hear proposals > for a

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

On 7 May 2021, at 13:39, John Levine wrote: > It appears that Hugo Salgado said: >> -=-=-=-=-=- >> >> I'll upload a new version to revive it, and ask for a slot >> in IETF111 for further discussion! > > It looks like it's worth considering, but I also wonder how > relevant it is for DNS

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

Hi Hugo, On 7 May 2021, at 12:47, Hugo Salgado wrote: > I'll upload a new version to revive it, and ask for a slot > in IETF111 for further discussion! Just to add my voice to the chorus, I missed this the first time around so thanks, Mauricio, for mentioning it. I haven't read the draft in

Re: [DNSOP] Call for Comment: (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)

On 6 May 2021, at 14:48, IAB Executive Administrative Manager wrote: > This is an announcement of an IETF-wide Call for Comment on > draft-iab-arpa-authoritative-servers-00. > > The document is being considered for publication as an Informational RFC > within the IAB stream, and is available

Re: [DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt

On 28 Apr 2021, at 08:29, Jaap Akkerhuis wrote: > Let me make some pedantic remarks about the terms used in this > discussion. Thanks Jaap, I welcome the accuracy :-) Joe ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt

Hi Donald, On 27 Apr 2021, at 22:34, Donald Eastlake wrote: > I am not comfortable with grabbing all the permanently unassigned 2-letter > country codes for DNS private use. > > Note: I was the primary author of RFC 2606 and have been involved in this > sort of thing before. See >

Re: [DNSOP] [Ext] WGLC for draft-ietf-dnsop-tcp-requirements

On 21 Apr 2021, at 14:27, Paul Hoffman wrote: > On Apr 18, 2021, at 4:17 PM, Suzanne Woolf wrote: >> We’d like to advance this but it needs some active support, so we need to >> hear from folks who have found it useful, especially implementers. > > It is indeed useful, and should be

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

On 19 Apr 2021, at 12:40, Peter van Dijk wrote: > This note on statelessness is good, but I don't think it should be tied to > IPv6. Packets get lost in IPv4 too, especially when they are big, and even if > such evens trigger a report in the form of an ICMP message, the same > lack-of-state

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

On 18 Apr 2021, at 19:17, Suzanne Woolf wrote: > We’d like to advance this but it needs some active support, so we need to > hear from folks who have found it useful, especially implementers. I didn't mention explicitly before, sorry, but I think this is a good document, it's useful and it

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

Hi John, On 19 Apr 2021, at 07:57, John Kristoff wrote: > On Mon, 19 Apr 2021 07:31:49 -0400 > Joe Abley wrote: > >> NEW: >> >> The specification of the DNS allows both UDP and TCP to be used >> as transport protocols for exchanging unencrypted DNS me

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

Hi Suz, On 18 Apr 2021, at 19:17, Suzanne Woolf wrote: > This message starts the Working Group Last Call for > draft-ietf-dnsop-tcp-requirements > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ >

Re: [DNSOP] draft-ietf-dnsop-delegation-only is still not useful

On 7 Mar 2021, at 15:23, Paul Wouters wrote: > Note that the count presented has other issues too. For example, > the first pseudo random domain I picked to look further from the top > of the file: > > info.txt.gz:ns1.breeat.info. 86400 in rrsig a 7 3 > 86400

Re: [DNSOP] [Ext] DNSSEC Strict Mode

Hi Ulrich, On Mar 1, 2021, at 05:43, Ulrich Wisser wrote: > On 25 Feb 2021, at 16:11, Joe Abley wrote: > >> On Feb 25, 2021, at 06:53, Ulrich Wisser >> wrote: >> >>> But this is a real world problem, one that is holding DNSSEC back. >>&

Re: [DNSOP] [Ext] DNSSEC Strict Mode

Hi Ulrich, On Feb 25, 2021, at 06:53, Ulrich Wisser wrote: > But this is a real world problem, one that is holding DNSSEC back. > If you buy DNS operations the operator will usually tell you what algorithm > they use, you have no choice in that. This feels like one of those areas where more

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refer-00.txt

On 12 Feb 2021, at 17:33, Paul Wouters wrote: > I think for the special processing this introduces, it doesn’t solve enough > problems. Oh, I see what you mean. I was reading dangers vs. gains as risk vs. benefit. Joe ___ DNSOP mailing list

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refer-00.txt

On 12 Feb 2021, at 15:37, Paul Wouters wrote: > On Fri, 12 Feb 2021, Joe Abley wrote: > >> I have discovered that without liberal access to bars and hallways at >> in-person IETF meetings, I no longer know how to tell the difference >> between ambition and insanity wh

[DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-refer-00.txt

end of the scale. Happy Friday! Joe > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-jabley-dnsop-refer-00.txt > Date: 12 February 2021 at 10:52:38 EST > To: "Joe Abley" > > > A new version of I-D,

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On 6 Jan 2021, at 15:48, Ben Schwartz wrote: > On Wed, Jan 6, 2021 at 3:37 PM Joe Abley <mailto:jab...@hopcount.ca>> wrote: > On Jan 6, 2021, at 14:45, Ben Schwartz <mailto:40google@dmarc.ietf.org>> wrote: > > > That model works well when (a) all vali

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Jan 6, 2021, at 14:45, Ben Schwartz wrote: > That model works well when (a) all validators implement an algorithm you like > OR (b) you view each algorithm as either "definitely strong" or "worthless" > (no middle ground). We are in scenario (b). When you sign a zone you choose one or

Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))

On 10 Dec 2020, at 19:41, Paul Hoffman wrote: >> "Authenticate authoritative servers" is a bit vague for me. Parent and child >> are namespace concepts and not relying parties that you'd ordinarily expect >> to be able to authenticate anything. > > A resolver asks a parent what the NS records

Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))

On Dec 10, 2020, at 19:25, Paul Hoffman wrote: > In DPRIVE, there is a desire to TLSA records to authenticate authoritative > servers. In order to do that without getting into a chicken-and-egg loop, the > parent needs to authenticate the NS records of the child authoritative server. I

Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))

On Dec 10, 2020, at 19:14, Mark Andrews wrote: > Before going on I would really like to know what operational problem is being > attempted to be solved by signing delegating information? +1 ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] Tell me about tree walks

On 11 Nov 2020, at 17:08, Paul Vixie wrote: > if you guys are going to automate and secure the public suffix list > functionality, please spare a thought for automated / at-scale ("not > in whois") identification of the domain's registrar and registrant. I understand the reason why being able

Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Hey, On 3 Nov 2020, at 10:49, Joe Abley wrote: >>> Well, 200+ TLD's are now removing this problematic orphan glue due to >>> security reasons unrelated to this draft. > > I have not done a survey of other TLD zones, but perhaps if I have a few > spare minutes I'll t

Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Hi Paul, On 3 Nov 2020, at 09:59, Paul Wouters wrote: > You never replied to this. I would really appreciate an answer so that > the Working Group knows whether or not your objection is still relevant, > based on the below developments of the Registry that is running the > TLD for which you

Re: [DNSOP] Going forward on draft-ietf-dnsop-private-use

On 2 Nov 2020, at 12:56, Joe Abley wrote: > On 2 Nov 2020, at 12:19, Paul Wouters wrote: > >> On Mon, 2 Nov 2020, Roy Arends wrote: >> >>> As for version -01, the authors propose to separate the document into two: >>> >>> (1) A document that d

Re: [DNSOP] Going forward on draft-ietf-dnsop-private-use

Hi Paul, On 2 Nov 2020, at 12:19, Paul Wouters wrote: > On Mon, 2 Nov 2020, Roy Arends wrote: > >> As for version -01, the authors propose to separate the document into two: >> >> (1) A document that discusses the motivation for private space top level >> domains, provides recommendations

Re: [DNSOP] zone contents digest and DNSSEC stuff

Hi Libor, On Sep 29, 2020, at 05:51, libor.peltan wrote: > Often the zone operators work with both un-signed and signed "versions" of > their zone. The un-signed version usually comes from a registry system or a > database, whereas a "signer" server adds "the DNSSEC stuff", like DNSKEYs, >

Re: [DNSOP] Authoritative servers announcing capabilities

On Sep 12, 2020, at 02:47, Paul Vixie wrote: > On Sat, Sep 12, 2020 at 09:40:11AM +1000, Mark Andrews wrote: >> and why is it a RR type at all. An EDNS option or a opcode is better suited >> for this sort of thing. > > +1. Plus lots. See below for TL;DR. Operational reality is that there

Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

On 30 Jul 2020, at 17:10, Paul Wouters wrote: > On Thu, 30 Jul 2020, Joe Abley wrote: > >> My sense is that this is a nice idea in theory but doesn't solve a problem >> that anybody actually has, and the camel is starting to look a little bit >> fraught. But I

Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

On 30 Jul 2020, at 16:36, Paul Wouters wrote: > Seems like .org needs to update an 18+ year old operation policy, and > just to clarify that has nothing to do with this draft as .org already > has this problem. Again, I'm not a lawyer, but I think what we are doing is a consequence of the

Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

On 30 Jul 2020, at 16:36, Paul Wouters wrote: > On Thu, 30 Jul 2020, Joe Abley wrote: > >>> The .org is definately what I would call a >>> delegation-only domain. Now let's examine the corner case you have >>> and see if/what we can do. >> >>

Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Hi Paul, On 30 Jul 2020, at 16:28, Paul Wouters wrote: > On Thu, 30 Jul 2020, Ben Schwartz wrote: > >> I do not believe that is correct. The first and foremost purpose is for >> the bit to signal the parent zone's behaviour in a public way that >> prevents targeted / coerced

Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Hi Paul, On 30 Jul 2020, at 15:43, Paul Wouters wrote: > You are mixing up the generic policy of delegation only with the exact > semantics of the bit. I don't think so, but I would definitely appreciate some clarification if you think that's happening. > The .org is definately what I would

Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Hi Paul, On 30 Jul 2020, at 13:20, Paul Wouters wrote: > On Thu, 30 Jul 2020, Petr Špaček wrote: > >> It is hard to see what benefits draft-ietf-dnsop-delegation-only brings >> without having description of "DNSSEC Trasparency" mechanism available. > > I do not believe that is correct. The

Re: [DNSOP] Question regarding RFC 8499

Hi Evan, On 23 Jul 2020, at 14:34, Evan Hunt wrote: > On Thu, Jul 23, 2020 at 01:38:58PM -0400, Joe Abley wrote: >> I don't think primary/secondary are exact substitutes for master/slave in >> the way that those four terms are commonly used today. > [...] >> If we are

Re: [DNSOP] Question regarding RFC 8499

On 23 Jul 2020, at 13:44, Tim Wicinski wrote: > On Thu, Jul 23, 2020 at 1:39 PM Joe Abley <mailto:jab...@hopcount.ca>> wrote: > > If we are looking for alternative terminology to master/slave (which I am not > against, because change is a constant and inclusiveness

<    1   2   3   4   5   6   7   8   >