[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

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.

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,

[DNSOP] Dnsdir telechat review of draft-ietf-dnsop-avoid-fragmentation-16

Reviewer: Vladimír Čunát Review result: Ready Yes. I like those reformulations in 16 since 15; I think they do make the text clearer. So, I still see nothing wrong with the current version and like the document overall. ___ DNSOP mailing list DNSOP

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

[DNSOP] Dnsdir last call review of draft-ietf-dnsop-avoid-fragmentation-15

Reviewer: Vladimír Čunát Review result: Ready I've already posted about -15, though not with dnsdir hat. So, I see nothing wrong with the current version. (The complaint about DF=1 in current implementations has been addressed.) ___ DNSOP mailing

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

[DNSOP] Dnsdir last call review of draft-ietf-dnsop-avoid-fragmentation-13

Reviewer: Vladimír Čunát Review result: Ready (assigned review) I re-read the whole text, and noticed nothing that I'd consider wrong or missing. (I didn't review implementation section; except Knot's is basically my text.) I think the current text is a quite nice reference for DNS

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

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

[DNSOP] Dnsdir telechat review of draft-ietf-dnsop-alt-tld-23

Reviewer: Vladimír Čunát Review result: Ready There've only been nits between -22 and -23; certainly no objections there and thus nothing new for me to say. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

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

[DNSOP] Dnsdir last call review of draft-ietf-dnsop-alt-tld-22

Reviewer: Vladimír Čunát Review result: Ready It feels a bit weird, but dnsdir assigns reviewers for this alt-tld LC, too. I took this as an opportunity to read the current text more carefully and also read more of the lengthy discussion history. I'm very happy with how the rules for handling

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

[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] 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

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

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). 

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] 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

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

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:

[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.

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

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

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

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

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

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.

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. 

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] [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

Re: [DNSOP] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp

Hello. This line is misleading, I believe: - RFC8198 describes how a validating resolver can emit fewer queries in signed zones that use NSEC for negative caching. That RFC describes aggressive caching also for NSEC3 and (positive) wildcards.  (Of course, opt-out NSEC3 records are

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

On 02/08/2022 13.53, Martin Schanzenbach wrote: This is not an oversight (altough I have to admin it did not occur to me that this a valid DNS TLD at the time of writing). [...] Oh, I understood that this DNSOP thread - notably the first post - originated as an attempt to reduce collisions

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

Interesting bit: the current -gns draft even uses the .pet TLD in an example, which is a TLD that actually exists in the official global DNS.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-09.txt

The long addition in "Flags" section broke the sentence into which it was inserted (by mistake?).  I also can't see that change in the newest git. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)

On 10/05/2022 21.55, Murray Kucherawy via Datatracker wrote: Regarding the SHOULD in Section 3.2, what other action might a resolver legitimately return, and why? Extended errors (RFC8914) generally aren't "mandatory", so they may return none.  In practice I also see quite some leeway in

Re: [DNSOP] [Ext] More private algorithms for DNSSEC

On 22/03/2022 09.56, Nils Wisiol wrote: There was some internal discussion about using 17 vs 253, with the main argument for 253 being that this is the intended use case for 253 and the main argument for 17 being that worry that some resolver implementations could have special treatment for

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

On 07/03/2022 19.06, Wes Hardaker wrote: The -05 version sounds clearer here than -04 ("not respond" above) or -03.  Thanks. You should check -06 too -- I restructured it to read better (IMHO) Right, I agree that -06 is better. ___ DNSOP mailing

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

On 26/02/2022 00.30, Wes Hardaker wrote: Validating resolvers MAY choose to not respond to NSEC3 records with iterations larger than 0. The -05 version sounds clearer here than -04 ("not respond" above) or -03.  Thanks. --Vladimir ___ DNSOP

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

On 22/02/2022 20.02, Geoff Huston wrote: I’m not sure I follow that latter comment relating to "a validating resolver returning an insecure response" - Do you mean: a) - a DNSSEC-validation capable resolver responding to a query that had the CD bit set? b) - a DNSSEC-validation capable

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

On 09/02/2022 22.41, Wes Hardaker wrote: So I've re-arranged things a bit to hopefully address the flow better. Let em know if you think further improvements are warranted. I'd still probably suggest at least a minimalist change like: -Note that a validating resolver MUST still validate the

Re: [DNSOP] I-D An Extension to DNS64 for Sender Policy Framework SPF Awareness

Hello. To me, the proposed "MUST rewrite [the SPF record]" certainly feels too strong.  I also wonder if there are some other problematic cases, as SPF certainly isn't the only common DNS record that can embed IPv4 address(es). --Vladimir ___

Re: [DNSOP] Neither authenticated nor SERVFAIL

On 09/12/2021 18.16, Mats Dufberg wrote: If you query for something that matches that wildcard, e.g. "x.lindforslaw.se A", then AD is not set, but it is not SERVFAIL. The wildcard proof involves an opt-out NSEC3 record in this case.  That means a delegation might exist instead of the

Re: [DNSOP] How Slack didn't turn on DNSSEC

On 01/12/2021 15.49, Mark Andrews wrote: Black lies is “QNAME NSEC \000.QNAME NSEC RRSIG”. There is no churn for "black lies”. Black lies turns NXDOMAIN into NODATA. "DNS Shotgun" can produce churn of NSEC if you ask for a type that is listed as existing but it doesn’t actually exist. The

Re: [DNSOP] How Slack didn't turn on DNSSEC

On 01/12/2021 13.43, Mark Andrews wrote: Accepting 'QNAME NSEC \000.QNAME NSEC RRSIG’ (and other type maps) protects you from random QTYPE attacks. It also makes 'black lies' work as intended. Black lies got bad caching if Knot Resolver accepted this aggressively.  Asking two different

Re: [DNSOP] How Slack didn't turn on DNSSEC

On 01/12/2021 09.35, Mark Andrews wrote: Also stop hiding this breakage. Knot and unbound ignore the NSEC records which trigger this when synthesising. Knot Resolver stopped treating minimally-covering NSEC* aggressively, but there are *two* different reasons. 1) breakages like this.  We

Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

On 26/11/2021 12.32, Petr Špaček wrote: You are right right, I did not consider "crack names which do not exist yet" scenario and focused only on dictionary reuse across zones. Do you have specific proposals for draft text? No, I don't have any ideas for improvements.  The current salt

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

I like the text and how it's improving. Note that a validating resolver MUST still validate the signature over the NSEC3 record to ensure the iteration count was not altered since record publication (see {{RFC5155}} section 10.3). It might be better to clarify that this "MUST" does not

Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

On 25/11/2021 13.00, Petr Špaček wrote: IMHO in the context of NSEC3 the salt would make sense _only_ if it were rotated faster than attacker was able to walk the zone. Once attacker has list of hashes available for offline cracking the salt does not do anything useful anymore. I disagree;

Re: [DNSOP] Filtering and DNSSEC

Hello, I realize this is tangential, but I believe it's important over the long term. Any modification of DNS will break *later* DNSSEC validation.  As filtering seems almost always done by DNS modification (e.g. NXDOMAIN), and I see significant trends in doing filtering as a service,

Re: [DNSOP] nsec3-parameters opinions gathered

On 04/11/2021 23.44, Wes Hardaker wrote: The most important sticking point is there are 4 implementations (thank you for the links Matthijs) that have implemented 150. Since DNSOP strives for implementations of specs, I think this is the number we should publish*unless the vendors speak up and

Re: [DNSOP] SVCB/HTTPS weasel words are dangerous.

On 01/11/2021 18.29, Michael StJohns wrote: Section 2 - "their definition should specify..." - this is obviously a must and is guidance to the IANA for interpreting registrations.  E.g. lack of this data has to result in a rejected registration request. Section 2.1 - "Key names should

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

On 26/10/2021 12.10, Roy Arends wrote: I have a slide ready to discuss the issue that DNS Query Name Minimization brings… A minimised query can’t be distinguished from a full query, so it may not be clear what name caused an issue. The current thinking (but will be discussed later today) is to

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

On 26/10/2021 12.02, Petr Špaček wrote: We need to consider & document interaction between Query Name Minimization and NXDOMAIN processing as per RFC 8020. If minimization & RFC 8020 are on default then it might very easily happen that most of _er subtrees (which are presumably empty) will be

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

Hello. DNS Error reporting SHOULD be done using DNS Query Name Minimization [RFC7816 ] to improve privacy. It's just a detail and "SHOULD" isn't strong, but I expect it might be worth elaborating here.  The name used in the reporting query adds

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

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*

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

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

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

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] 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

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 couple GB

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

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

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

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

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

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

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] 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: [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] 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).

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

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] 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.

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)

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

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] 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

[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

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.

[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

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

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

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

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] 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.

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"

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] 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] 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] 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

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

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. 

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: >

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

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/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

  1   2   >