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

On 08/08/2022 14.53, Jim Reid wrote: How about having an IANA registry of these experimental TLDs? Those strings don’t go in the root. And they don't get added to the IETF’s special use list and ICANN is still free to create these TLDs if/when they decide to create more. This hypothetical IANA

Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review

On 19/08/2022 20.06, Paul Wouters wrote: Security Considerations could say that .alt queries MUST NOT be forwarded to other DNS servers for resolution. There's a dilemma with SUDNs.  If a resolver isn't allowed to "send the name upstream", it might not be able to return DNSSEC-correct denial. 

Re: [DNSOP] Use of CNAMEs for NS Records

On 23/08/2022 14.15, Tobias Fiebig wrote: Is there something I missed/should CNAME in NS be considered valid now? [...] However, it seems odd that RFC2181 and operational practice seem to diverge here. This sounds like running a few tests in the wild might imply that such setup is OK.  (co

Re: [DNSOP] [dns-privacy] [core] WGA call for draft-lenders-dns-over-coap

On 06/09/2022 17.06, Ben Schwartz wrote: The choice of transport is independent of the DNS server's answering behavior, which must not be modified by the transport. Nit: there's a very specific counter-example of EDNS padding which is meant to be added depending on transport encryption. https

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt

On 07/10/2022 18.21, Paul Wouters wrote: Perhaps even: DNSSEC documents predating {{RFC4033}}, {{RFC4034}}, and {{RFC4035}} specify obsoleted DNS RRtypes that never saw deployment beyond early adopter testing, and haven't been deployed in nearly two decades, and are of no concern to implementers

Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?

On 17/10/2022 23.28, Benno Overeinder wrote: The DNSOP WG chairs welcome feedback on the draft draft-homburg-add-codcp, Control Options For DNS Client Proxies (https://datatracker.ietf.org/doc/draft-homburg-add-codcp/). I find it a bit weird for a client to *choose* how the proxy/resolver mi

Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?

OK.  I suppose I'm stuck in the model of (at least) machine-wide policies, thinking that it would be really messy if each app chooses properties of their DNS separately.  (Which sounds more like a job for a library API anyway.)___ DNSOP mailing list DN

Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?

On 19/10/2022 10.06, Philip Homburg wrote: And then we end up with potentially many different implementations in applications, which seems worse to me. That aim doesn't seem consistent with the statement that the proxy won't be trusted with DNSSEC validation.  That way you still need a rather

Re: [DNSOP] .alt filtering in recursive servers

On 08/11/2022 11.33, Mark Andrews wrote: Filtering .alt in recursive servers should be a MUST NOT. [...] It would be nice to define this *in RFCs* somewhat uniformly for *all* the different special-use names. There's this unfortunate conflict between blocking and not blocking: total prevent

[DNSOP] draft-thomassen-dnsop-mske: DNSKEYs in non-apex

Hello. It's not a major thing in your design, but I see a risk that DNSKEYs at non-apex might have trouble validating, so at some point I'd expect your proposal to choose a different approach (e.g. allocate a new identical RR type) or at least confirm that it won't be a major problem. --Vlad

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

Hello. I don't know... my opinions often differ from recommendations of this draft, but ultimately it's subjective to some degree.  As feedback was requested on IETF 115, let me highlight more significant differences in this e-mail, though I dislike arguing about (mostly) opinions. Nit: th

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

OK, thanks.  The changes are certainly improvements, in my eyes.  Below I'll further clarify what I meant. 4033 indicates it does not make much sense to keep a RRSIG whose validity period has expired ( TTL > Validity period). Yes, I should stress that I do agree with trimming TTL of whole RR

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

On 25/11/2022 18.26, Daniel Migault wrote: So let me know how we came to this lines and I suspect we do share some similar concerns. A recurrent question and reticence we receive from MNO and ISPs regarding DNSSEC is that they are really scared about having the cache with incoherent RRsets in t

Re: [DNSOP] draft-thomassen-dnsop-mske: DNSKEYs in non-apex

I didn't explain why, so let me add just a short pointer.  No need to go deeper here at this point of the draft, I think. On 28/11/2022 19.26, Peter Thomassen wrote: As such, I don't see any risk that would not be exposed immediately during implementation/testing, and the fix is also trivial.

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

On 15/12/2022 01.59, Martin Schanzenbach wrote: If there is an obvious way to do it, the draft could give an example. Whatever you mean by "go to a regulated space" should be given with clear example. You can simply register a DNS name and use that sub-tree in non-DNS context (as well).  That

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

On 15/12/2022 14.45, Peter Thomassen wrote: In what sense is this document "informational" when it is called "validator requirements", or, conversely, in what sense does it spell out "requirements" when it is only "informational" and not "standards track"? The current *title* says "Recommend

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

On 15/12/2022 23.36, Daniel Migault wrote: I don't see the part about extended errors as problematic (RFC 8914).  It really seems to be getting into (open-source) implementations and it can help with debugging in some cases, though deploying it is probably not very important eith

[DNSOP] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: Knot Resolver + Knot DNS

With Knot Resolver + Knot DNS the fragmentation issues are currently being addressed quite simply: * IP_PMTUDISC_OMIT to avoid spoofed MTU * UDP size limit, 1232 by default (and of course honoring if the other side wants lower, etc.) Other points from the draft, perhaps less important: *

Re: [DNSOP] Updated: Compact Denial of Existence

On 06/03/2023 03.35, Shumon Huque wrote: I suspect that unilaterally putting NXDOMAIN into the rcode field will break a lot of validator code. They are likely to use the rcode to advise them on what type of proof to look for in the message body, and they won't find a traditional NXDOMAIN proof.

Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-alt-tld-22

On 07/04/2023 06.12, Linda Dunbar via Datatracker wrote: Question: Are the .local and .onion part of the Special-use domain names registered in IANA? They do appear in the registry: https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml ___

Re: [DNSOP] Coming soon: WG interim meeting on the definition of "lame delegation"

On 19/06/2023 17.00, Masataka Ohta wrote: I can't see any problem with "lame" delegation than a "secondary" or "slave" server, because of the history of racial discrimination in US. Honestly, I'm personally still failing understand the problem of using slightly offending word when referring t

Re: [DNSOP] Working Group Last Call for Negative Caching of DNS Resolution Failures

On 26/06/2023 16:47, Peter van Dijk via Datatracker via dnsdir wrote: The document has not seen a lot of WG discussion; I hope this means people have read it and generally agree. Yes, I've read through the document now again and I generally agree with it. (But I'm afraid I can't think about th

Re: [DNSOP] Followup One Week Working Group Last Call for draft-ietf-dnsop-avoid-fragmentation

I see nothing wrong with the current version (-15), and as I posted before, I consider it a nice reference for DNS fragmentation. (I'm a bit late, but at least for the record.) --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mail

Re: [DNSOP] Tsvart last call review of draft-ietf-dnsop-avoid-fragmentation-15

On 22/10/2023 13.18, Mirja Kühlewind via Datatracker wrote: 3) In R8 you mention a timeout. Is it already anywhere specified how to set such a time for DNS retransmissions? If so, I think a reference would be useful. If not, more guidance is need to avoid network overload. No, I don't think so

Re: [DNSOP] DELEG and parent only resolution

On 30/01/2024 07.55, Kazunori Fujiwara wrote: It proposes new name resolution using only information on the parent side. Let me just point out a key distinction: the typical use case of DELEG should be kind-of child centric.  Most people will only use a simple alias-mode DELEG at the parent,

Re: [DNSOP] DELEG and parent only resolution

On 31/01/2024 09.16, Joe Abley wrote: It seems important to be prepared for a long transition phase [...] Yes, that's been well known since the very beginning of the discussions at IETF 118.  Support in resolvers will also take years to deploy widely, even for relatively simple changes. _

[DNSOP]Re: Our reading of consensus on draft-hardaker-dnsop-rfc8624-bis, and the "must-not-algorithm" docs.

On 14/05/2024 22.57, Warren Kumari wrote: This means that we should actually have a column per type (i.e “Operators” and “Implementers”) crossed with a column per DNSSEC usage type (“Signing” and “Validation”), such that for the “Domain Name System Security (DNSSEC) Algorithm Numbers” table we

[DNSOP] Re: New draft on collision free key tags in DNSSEC

I believe that such a draft is NOT worth all the implied human effort, I'm afraid.  The idea isn't new, but let me reiterate my points below. Even if we forbid all keytag collisions, there will be many more ways how attackers may attempt to generate lots of work for validating resolvers.  (man

[DNSOP] Re: New draft on collision free key tags in DNSSEC

On 30/07/2024 09.41, libor.peltan wrote: Anyway, it can realistically take decades before any new algorithms seize some good portion of DNSSEC. In other words, that flag day has already silently passed. I don't think that's a helpful point in time.  I assume the main target of this RFC is def

[DNSOP] Re: New draft on collision free key tags in DNSSEC

On 31/07/2024 15.29, Petr Špaček wrote: Per-zone limit does not defend against resource exhaustion because an attacker can construct chain of delegations a.b.c.d.e.. and max out limit on each level. Then you instantly get about 126*(per-zone limit on validations) just for this particular at

[DNSOP] Re: Light weight encrypted DNS proposal

Hello. I think dprive fits the encryption topic better than dnsop?  Anyway, some quick thoughts below. On 15/08/2024 00.06, Vint Joseph wrote: using UDP and only one or two packets I suspect that larger answers will be... a complication. You could rely on UDP fragmentation, but in that case

Re: [DNSOP] some 2015-era thoughts about RFC 7706 -bis

On 7/25/19 7:44 AM, Evan Hunt wrote: > [... TLD XFR] However, admittedly, one probably > wouldn't want to do it for large zones, and I don't know of any TLD's that > allow transfer in the first place, so for the purposes of the current > discussion, you're right enough. I know about .se (and .nu)

Re: [DNSOP] Call for Adoption: draft-hoffman-dns-terminology-ter

On 8/1/19 6:08 PM, Tim Wicinski 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'm in favor of adoption. I'm not sure if it's a good idea to suggest content changes in this same thread already, bu

[DNSOP] Special-use TLDs in resolvers

Hello, I've been wondering what's best to do around these TLDs: invalid, local, onion, test.  The RFCs say that resolvers SHOULD recognize them as special and answer NXDOMAIN without any interaction with nameservers (by default).  What do you think about NOT following this "advice", subject to som

Re: [DNSOP] Special-use TLDs in resolvers

On 8/16/19 3:10 PM, Ted Lemon wrote: > If you look up “onion”, you have revealed that the user is trying to > use tOR, even if you haven’t revealed where they are going. Well, in this particular case the tOR client would probably better not send onion queries to DNS resolver, but generally there w

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-08.txt

Hello, authentication of blocking decisions is an interesting idea to consider, though it's probably beyond the scope of this RFC draft.  Most interesting cases can be already covered by securing the channels between the first resolver that does blocking and the final stub. On 9/4/19 2:31 PM, Vitt

Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs

On 9/12/19 8:10 PM, Viktor Dukhovni wrote: > SERVFAIL means, and will continue to mean, I can't help you, better luck next > time (or elsewhere). > > The new EDEs are *diagnostic* detail to aid in troubleshoots, but do not > override RCODEs. They are not a more fine-grained RCODE one might "act o

[DNSOP] I-D Action: draft-ietf-dnsop-extended-error-09.txt

The following comments are only loosely related to multiple threads here, so let me post them in a single bunch. On 9/11/19 8:05 AM, Viktor Dukhovni wrote: > Section 3.2 (code 2), may warrant more guidance on when this is > appropriate. AFAIK, there is nothing wrong with all DNSKEY algorithms > b

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-08.txt

On 9/24/19 12:36 PM, Tony Finch wrote: > Petr Špaček wrote: >> IMHO the most useful information is dichotomy: >> >> a) the problem is local (= call network admin/ISP/telco) >> >> b) the problem is remote (= call your bank because their internetbanking >> broke and _do not your bother ISP_). > I th

Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

On 9/26/19 12:30 PM, Jan Včelák wrote: The current draft attempts to minimize complexity for implementers by offering a fully generic encoding for unknown key types. For example, "alpn=h3" can also be expressed as "key1=h3", and "port=8003" can also be expressed as "key2=\031\067". This encod

Re: [DNSOP] draft-ietf-dnsop-extended-error status

On 9/30/19 11:47 PM, Warren Kumari wrote: > On Mon, Sep 30, 2019 at 7:54 AM Tony Finch wrote: >> Difficult. In general there will be multiple upstream servers, even in >> the simplest case of a stub talking to a recursive server talking directly >> to authoritative servers. So there can be an arbi

Re: [DNSOP] Call for Adoption: draft-nygren-dnsop-svcb-httpssvc

Hello; I do support adoption. On 10/7/19 4:52 PM, Stephen Farrell wrote: The main caveat for me is I don't know if it'd be worth publishing an RFC if this doesn't end up getting deployed in browsers. So getting clarity there as early as poss would be good if we can. I agree, but I wouldn't blo

Re: [DNSOP] [Ext] Re: Working Group Last Call for draft-ietf-dnsop-7706bis

On 11/1/19 1:26 AM, Paul Hoffman wrote: > On 10/31/19 6:10 PM, A. Schulze wrote: >> editorial note: Appendix B2 and B4 are mostly the same. > Mostly, but not exactly. Folks asked us to add B4 because of the new features > in BIND 9.14. Is this still what the WG wants? New features in Unbound 1.9,

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-02.txt

Hello! On 10/28/19 10:32 PM, Wessels, Duane wrote: > The one defined hash algorithm SHA384 has been renamed to SHA384-STABLE to > reflect that it designed for use on stable (or small) zones where it is not > burdensome to recalculate the digest over the entire zone data each time. Tiny nitpick:

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

On 11/14/19 12:05 AM, Viktor Dukhovni wrote: > It'd be a shame (though admittedly not frequent) to have a resolver > retry over TCP just to get the same answer with additional information > it does not need and perhaps does not even understand. EDE codes themselves take very little space, so trunc

Re: [DNSOP] On .ZZ

On 11/21/19 8:26 AM, Paul Wouters wrote: > for example if ICANN delegates .zzz there will be interesting typo attacks > possible in this weird private space In this respect .zz is at least better than .xx which was among the suggestions. > Finally, I agree. People want something semantic and mor

Re: [DNSOP] draft-ietf-dnsop-svcb-httpssvc-01 feedback

On 12/6/19 11:43 PM, Eric Orth wrote: > Section 1.3: Compared to previous drafts, not much value anymore in > SvcFieldPriority being a first-class field outside SvcFieldValue. [...] There's still advantage for resolvers implementing the chain-jumping (Sec. 4); it allows them to avoid looking insid

Re: [DNSOP] Last Call: (A Common Operational Problem in DNS Servers - Failure To Communicate.) to Best Current Practice

On 12/16/19 10:39 AM, Stephane Bortzmeyer wrote: > Do we agree that Knot is wrong and the draft is right? Or is FORMERR > acceptable? The discrepancy should disappear eventually: https://gitlab.labs.nic.cz/knot/knot-dns/commit/2b31ee57a7c I personally do have occasional issues finding out which R

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

On 1/7/20 3:15 AM, Michael StJohns wrote: >>> >>> 1) A recommendation for the maximum size of the zone [...] >> I am reluctant to add this.  As John said, I think it won't age well. >> [...] > > As I suggested in one of my messages, giving an idea of how long it > takes to digest various sizes of z

Re: [DNSOP] SVCB chain lengths

On 12/23/19 9:22 PM, Eric Orth wrote: > 2) Any chain limiting enforcement only applies to stubs following > chains, not recursives. > > Recursives are already following CNAMEs without a standardized limit. > [...] (I'm a bit late, I'm sorry.)  Recursives *in practice* seem quite limited.  Unbound

Re: [DNSOP] DNS stamps

These stamps do contain interesting ideas, I believe. On 1/9/20 5:13 PM, Ted Lemon wrote: > In order for this to actually be useful, two things would be required. > > 1. The assertions about resolver behavior (e.g., logging, etc) would > have to be signed > [...] Depends what you'd want from the

Re: [DNSOP] DNS stamps

On 1/9/20 6:37 PM, Ted Lemon wrote: > On Jan 9, 2020, at 9:21 AM, Vladimír Čunát <mailto:vladimir.cunat+i...@nic.cz>> wrote: >> Depends what you'd want from the stamps. > If the stamps make assertions about what service is offered, I’d want > that to be verifiable

Re: [DNSOP] rrserial as a path to fame and fortune (was: Adoption of new EDNS opcode "rrserial")

Hello. On 1/29/20 11:57 AM, Shane Kerr wrote: > One possible application of this might be to allow a resolver to > extend the TTL of an entire zone. Overall I suspect the TTL-extending use case might be sufficiently different (and much more complicated) to consider separately/independently. > A

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/21/20 1:04 PM, Klaus Malorny wrote: > according to my colleagues, who are in contact with the customers, the > use case is mostly in the context of CDNs. Some of them maintain a > larger set of domains with alternate spellings of their product names, > with different ccTLDs, some for promotion

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/21/20 2:23 PM, Klaus Malorny wrote: > I see a major drawback in comparison to the ANAME draft, namely that > there seems to be no fallback for old browsers (and robot software > accessing websites) being defined. Of course, authoritative name > servers could implement a similar mechanism as sp

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/21/20 3:01 PM, Klaus Malorny wrote: > simply that I want to get rid of it. IMHO one aim of a new technology > should be to make old technology obsolete, esp. such workarounds. If I > have to keep them (forever?), where is the benefit (for me as a company)? I see.  You'd like to deploy someth

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/25/20 8:07 PM, Andrew M. Hettinger wrote: > Frankly, you've got it exactly the wrong way around: even with httpsvc > speced out completely, it will take time for it to be deployed to > browsers. That's assuming you can get enough buying from (mostly) > google to even make it happen at all. I

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/26/20 11:28 PM, Andrew M. Hettinger wrote: > Is there actually a commitment from browser makers to implement it? > [...] > But let's be clear, the biggest group that we need buy-in from are the > chromium devs. Without them, this isn't worth the bits we've sent down > the wire discussing it.

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/27/20 4:51 AM, Lanlan Pan wrote: > [...] > Just configure ANAME in the zonefile,  authortitative return response > is CNAME, no ANAME. > If enable DNSSEC, this will cause some dynamic signature > calculation（ECDSA will be better). I would (generally) NOT recommend sending CNAME in answer in c

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-7706bis-07

On 2/28/20 2:02 PM, Ines Robles via Datatracker wrote: > 1- Appendix B.5: it seems that the link is not valid: resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc- >7706> > > This link worked for me: > https://knot-resolver.readthedocs.io/en/stable/module

Re: [DNSOP] New draft on delegation revalidation

On 4/22/20 9:32 PM, Shumon Huque wrote: > Since delegation records and glue address records are unsigned, they > can be spoofed, and DNSSEC should really allow us to detect such > spoofing once a resolver sees referral data. I wouldn't put much energy into improving this part in *this* draft.  Eve

Re: [DNSOP] Privacy and DNSSEC

Original subject: New draft on delegation revalidation On 4/24/20 4:49 PM, Shumon Huque wrote: > > Even DNSSEC-validated NSs and IPs aren't sufficient to ensure privacy, > so I'd rather kill this problem by proper encrypted protocol towards > authoritatives (in current dprive charter).

Re: [DNSOP] Validating responses when following unsigned CNAME chains...

On 4/30/20 2:01 AM, Shumon Huque wrote: > It definitely can't set the AD bit. So, I suppose your argument is why > bother authenticating the target. That's a defensible question. [...] Certainly not defensible.  The AD bit isn't the only part.  What if the CNAME target is spoofed (BOGUS) or someth

Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt

Hello, I'm still a bit skeptical. 1. Validation without logging. At the end of 3.1 you claim that mode is still useful.  When I focus on intentional attacks, signing a malicious DS seems among the easiest ones, and that can't be detected without the attacked machine doing logging (the DS might be

Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt

On 5/7/20 6:06 AM, Paul Wouters wrote: > On Tue, 5 May 2020, Vladimír Čunát wrote: >> 1. Validation without logging. >> At the end of 3.1 you claim that mode is still useful.  When I focus on >> intentional attacks, signing a malicious DS seems among the easiest >> ones,

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

On 5/12/20 3:24 AM, John Levine wrote: > It doesn't seem like a bad idea but I'm wondering who's likely to > implement it, since that makes it much more interesting. Knot DNS has an implementation already.  It's not merged and can't create catalog zones yet, but we expect to support it in future.

Re: [DNSOP] DNSSEC actual failures log where?

On 5/14/20 4:50 PM, Bob Harold wrote: > I am preparing to enable DNSSEC validation, so I am working on alerts > for failed validations, so I can see whether they are user errors > (that might need negative trust anchors or other exceptions) or actual > attacks. > But it seems that the "dnssec" cate

Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses)

Hello. On 5/28/20 10:00 AM, Shane Kerr wrote: > As I have mentioned several times on microphone, I think this draft > has huge potential, potentially cutting the number of queries handled > by recursive resolvers almost in half - since they could ask for A and > records in a single query. I

Re: [DNSOP] DNS RR Type Allocation Request

On 6/16/20 11:05 PM, Brian Dickson wrote: > Nit: I think this should be "code points" (plural), one for HTTPS and > one for SVCB, right? There's even a new registry to be added.  Whole IANA section should get "executed", I expect. --Vladimir ___ DNSOP

Re: [DNSOP] Algorithm implementation recommendations in 8624

On 6/17/20 8:30 AM, Mats Dufberg wrote: >> I wonder if there is a way to extend  >> https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml >> >> to add signing/validation recommendations.  This seems "hard" from >> the world of IANA, but I'm not an expert. > > What strikes m

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

On 6/18/20 7:22 PM, Ted Lemon wrote: >> I suspect it will work like every other locally-served domain or >> every other private namespace that exists today, i.e. just fine with >> no configuration changes expected or required on dependent >> (downstream) DNS clients. And if there are new species of

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On 6/19/20 6:20 AM, Martin Thomson wrote: > As long as the space of codepoints isn't too small (2^16 is fine), then I see > no reason not to allow external publications request a value as long as they > don't abuse the privilege. The space for DNSKEY and DS algorithms is one octet, so each of th

[DNSOP] draft-ietf-dnsop-delegation-only​: exchanging DS set

Hello dnsop. Let me start a simple thought experiment - attacking the planned scheme.  It feels like I'm missing some part of the defense. A .evil registry is using the DELEGATION_ONLY flag.  They additionally sign a different victim.evil DS set, say adding hash of a DNSKEY they generated themsel

Re: [DNSOP] draft-ietf-dnsop-delegation-only​: exchanging DS set

On 7/31/20 2:34 PM, Paul Wouters wrote: > The process of a rogue parent is not a purely technical one. It can include a > legal system, a payment dispute, and many other things. > > Per definition, it will be a manual process to confirm if a “changed child” > is a legitimate change or not. Loggin

[DNSOP] draft-hoffman-dnssec-iana-cons

Hello. I didn't speak but I'd still like to indicate my support.  Requiring "Standards Action" just to allocate algorithm numbers seems quite an overkill.  I'd find it healthy to split that into an easier step, so it's also clearly separable from endorsing or even requiring support for those algor

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

Hello. I think the draft should also mention glue *addresses*, as that's another closely related piece that often comes from the parent side (and is also unavoidable to use in some situations).  Even if that means not really recommending anything about them, though I'd personally expect these to b

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

I'm sorry for the delay. On 11/19/20 8:47 AM, P Vixie wrote: > On Tue, Nov 17, 2020 at 09:32:09AM +0100, Vladim??r ??un??t wrote: >> I think the draft should also mention glue *addresses* [...] > do you mean where the NSDNAME is in-zone and there is a non-authoritative > copy of the or A RRs

Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)

Hello. From resolver point of view... this implies that signed *positive* wildcard answers will now get cached with this shorter "negative TTL", right?  These do need to deny existence of non-wildcard match, so they need to contain NSEC*. Maybe the final text would better explicitly note suc

Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)

On 1/6/21 9:01 PM, Peter van Dijk wrote: On Sat, 2020-12-12 at 11:46 +0100, Vladimír Čunát wrote: From resolver point of view... this implies that signed *positive* wildcard answers will now get cached with this shorter "negative TTL", right? These do need to deny existence of no

Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)

On 1/13/21 10:28 AM, Peter van Dijk wrote: That all said, I now no longer think we need to do a whole update/clarification thing on this, but I will add a note to my document saying that changing the NSEC TTL might affect wildcards, as you requested earlier. Sounds good to me.  Thanks. --Vladi

Re: [DNSOP] NSA says don't use public DNS or DoH servers

On 1/22/21 3:10 AM, Tom Pusateri wrote: Would it be ok to allow DNSSEC signed responses from any server? If they’re signed and verified, does it matter how you got them? Another missing part is privacy, i.e. even if you get exactly the same answers, it doesn't imply you get similar (privacy)

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-intentionally-temporary-insec-00.txt

Hello. I'm certainly not fond of trying to call this "best practice". I'd rather try persuading people to either improve such tooling or switch production to another one, but I understand that in real life there are cases where the proposed approach may be considered a better choice than a pro

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-iana-cons-00.txt

Hello. I'm quite surprised that the IANA section of the draft includes that registering *flags* is also changed from "Standards Action" to "RFC Required".  While the algorithm space is rather large, that certainly doesn't apply to the NSEC3 and NSEC3PARAM flags (only 7 remain free). --Vladim

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-iana-cons-00.txt

On 3/11/21 4:38 PM, Paul Hoffman wrote: I'm quite surprised that the IANA section of the draft includes that registering*flags* is also changed from "Standards Action" to "RFC Required". While the algorithm space is rather large, that certainly doesn't apply to the NSEC3 and NSEC3PARAM flags

Re: [DNSOP] New version of draft-ietf-dnsop-rfc7816bis after WG last call

We're looking for comments before Monday April 26th. I'm sorry.  Better slightly late than never, I suppose.  The whole text seems good to me, except for a small issue: In step (6) of the algorithm it might better be noted that in case xNAME is in ANSWER, the RCODE is irrelevant.  Now the re

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

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 (if from the same zone), I really dislike the implications of them being

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

I like the document, but the section on validators recommends not to follow requirements from RFC 5155, so I don't expect that best-practice track is sufficient.  And I do think we need a similar update to 5155, be it in this document or a separate one. I'd also expect something on limits acce

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

On 11. 05. 21 1:59, Brian Dickson wrote: IMNSHO, it'll be faster to discard any existing parsing code, and embrace this as the Zone File format (and wire format) going forward. I think that would imply burning the currently allocated RRtype code pair and requesting a new pair from IANA.  Not u

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

On 11/05/2021 18.17, Wes Hardaker wrote: I'd also expect something on limits accepted by secondaries.  And some details are probably up to further discussion (e.g. particular numbers and SERVFAIL), but I don't think such details would block adoption. That's certainly an interesting thing to thin

Re: [DNSOP] IETF meeting prep and what

On 18/06/2021 19.40, Peter van Dijk wrote: aname can go; I trust the WG feels SVCB will supersede it. Yes, please. 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 t

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

Hello, I support the draft.  (as I wrote in November)  I re-read the current text, though I admit I could miss details relatively easily in process matters. --Vladimir | knot-resolver.cz ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/ma

Re: [DNSOP] NSEC3 Guidance - zone size impact of opt-out

On 03/09/2021 09.32, Paul Wouters wrote: I guess with aggressive nsec, you might even gain some CPU cycles back for that extra memory used, and receive less queries too? Saving you some money? I think these savings won't be significant in delegation-centric zones that are huge enough to consi

Re: [DNSOP] NSEC3 Guidance - zone size impact of opt-out

On 03/09/2021 09.48, Vladimír Čunát wrote: you can't expect them[resolvers] to keep a significant fraction of huge zones in cache That being said, if a zone with (only) a couple million entries is *attacked*, it can be realistically protected by aggressive caching.  A cache of a coup

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

For the limit on total number of connections: "Absent any other information, 150 is a reasonable value for this limit in most cases." [...] Maybe this could use a clarification that 150 is good advice only if you _don't_ have any "TCP-only" clients, like e.g. DoT stubs? I would not be so sure

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

On 15/09/2021 16.41, Daniel Migault wrote: Outside experimentation, especially for national algorithms, this will lead to nations having their algorithms qualified as standard while other nations having their algorithms qualified as non standard. I would like to understand why this cannot be a

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

On 15/09/2021 23.51, Daniel Migault wrote: I do not have any specific example in mind and as far as I know GOST is standard [1] - This was already the case during the call for adoption and I suppose it was mentioned as an example. To clarify, that DNSSEC-standard GOST only uses crypto that's b

Re: [DNSOP] Bailiwick discussion for draft-ietf-dnsop-rfc8499bis

On 12/10/2021, Tony Finch wrote: I view the term "in-bailiwick" as no longer suitable for use in careful writing because its meaning has become thorougly confused and muddled. I agree that without further qualification the meaning of "in-bailiwick" isn't clear.  And I'm personally not convince

Re: [DNSOP] wrapping up draft-ietf-dnsop-nsec3-guidance

On 21/10/2021 13.22, Peter van Dijk wrote: Editorial nit, already hinted at above: the text currently has "Validating resolvers MAY return SERVFAIL when processing NSEC3 records with iterations larger than 500." - I suggest changing this to "validating resolvers MAY ignore NSEC3 records with it

Re: [DNSOP] wrapping up draft-ietf-dnsop-nsec3-guidance

On 21/10/2021 23.20, Viktor Dukhovni wrote: 2. Resolvers could still cope with such numbers pretty confidently. This is where I'm looking for experienced feedback from resolver maintainers and operators. I don't think that NSEC3 hashing could consume significant resources in *normal* traffic.

Re: [DNSOP] draft-hardaker-dnsop-intentionally-temporary-insec-01.txt

On 21/10/2021 18.55, Wes Hardaker wrote: It adds a new section using multiple authoritative servers with different data to get around algorithm roll difficulties. I'm also not convinced that it's a good recommendation, meaning I can't predict if it will behave relatively reliably.  Perhaps if

  1   2   >