[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

Hi all, On the other hand, couldn't it actually be beneficial if the signalling zone name is generic enough, and if (in theory on the future) it is shared with possibly completely different signals, possibly unrelated to DNSSEC? With this in mind, I support the signalling label _signal.

Re: [DNSOP] [Ext] About key tags

Hi John, Dne 27. 02. 24 v 21:24 John Levine napsal(a): The total number of domains where I found duplicate tags was 105. As I said earlier, is while I appreciate such research, I warn against misinterpreting it. The main point isn't about the zones that are currently experiencing a

Re: [DNSOP] [Ext] About key tags

Hi all, let me speak up as an open-source authoritative server (Knot DNS) implementer. Since long time, we do care when generating keys to avoid keytag conflict. Yes, this was motivated purely by easing key management. However, in the Offline KSK and multi-signer scenarios, keytag

Re: [DNSOP] New Version Notification for draft-homburg-dnsop-igadp-00.txt

Hi Philip, I don't really want to discourage you, but I think this is in general a bad idea: optimizing for the best case, but no benefit -- or even twice(?) as more resources consumption -- under a random-subdomain attack. It looks even weirder to me when I see you argumenting with DDoS

Re: [DNSOP] NOTIFY: How to locate the target

Hi, i think this issue shall be considered in two split cases: a) when the *registry* is to be notified. I think this can be achieved easily, the registry only creates a single target for child notifies. I'm not sure if current specs allow to do it safely (so that that target is separated

Re: [DNSOP] Automated delegation management via DDNS

Hi, I'm not sure if this helps the discussion, but Knot DNS implements "DS push", an automated DDNS update updating the DS (not NS) at parent. It's mostly intended for single-organization parent-child relations, where TSIG (or soon DDNSoQ) can be configured easily. Libor Dne 25. 10. 23 v

Re: [DNSOP] Fwd: New Version Notification for draft-peltan-edns-presentation-format-01.txt

ith existing systems. --Ben Schwartz ---- *From:* DNSOP on behalf of libor.peltan *Sent:* Wednesday, May 31, 2023 4:33 AM *To:* dnsop *Subject:* [DNSOP] Fwd: New Version Notification for draft-peltan-edns-presentation-for

Re: [DNSOP] I-D Action: draft-bellis-dnsop-qdcount-is-one-01.txt

I would even rather see a recommendation that firewalls and middleboxes don't do any kind of DNS packet handling. Why should they? DNS traffic is for DNS servers and they are the most capable entity for handling them, including FORMERR responses on wrongly formatted queries. Libor Dne 29.

Re: [DNSOP] Cache refreshes like in DNS over CoAP

Hi, I have also difficulties finding any benefit of such feature. Shall it help lowering bandwidth usage for authoritatives or for recursives? I'd say that for authoritatives in general, legitimate traffic is the minority, so reducing that would not help much. I'd oppose the idea of having

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

Dne 17. 07. 23 v 21:41 Brian Dickson napsal(a): TCP traffic is several orders of magnitude more expensive than UDP. This might be true, but it must be carefully considered. Yes, a performant authoritative server is able to answer (for example) 10 Mqps over UDP or 10 kqps over TCP. One

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

Hi Peter, Dne 23. 06. 23 v 19:29 Peter Thomassen napsal(a): On 6/23/23 17:21, libor.peltan wrote: I would expect the combination of a nameserver not being reachable and the other party being malicious to be quite a rare event. A combination of a nameserver being unreachable and an other one

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

Hi Peter, Dne 22. 06. 23 v 18:10 Peter Thomassen napsal(a): I would expect the combination of a nameserver not being reachable and the other party being malicious to be quite a rare event. A combination of a nameserver being unreachable and an other one being misconfigured e.g. in the sense of

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

Hi, here are my comments to draft-thomassen-dnsop-cds-consistency-03. "In all cases, consistency is REQUIRED across received responses only. Nameservers that appear to be unavailable SHOULD be disregarded as if they were not part of the NS record set." I don't feel confident about the

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

Hi, I like the ideas in this document and I support its adoption, willing to comment its contents. Libor Dne 07. 06. 23 v 17:52 Tim Wicinski napsal(a): All, We've had this document in DNSOP for a bit and Peter has presented three different meetings. When I went back and looked at the

[DNSOP] Fwd: New Version Notification for draft-peltan-edns-presentation-format-01.txt

Hi dsnop, we'd like to turn your attention again to our draft https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html We believe this document shall fill a missing gap in specifications, and help interoperability of DNS tools. Therefore, we think it'd make sense if

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

Hi Paul, if you really ask for opinions, here is mine. Considering the recent voluminous discussion about the meaning of Lame delegation, it seems to me that there are at least several people being more-or-less sure what the term means, with the issue that everyone thinks something slightly

Re: [DNSOP] Subject: request for adoption: draft-edns-presentation

Hi Pieter, Dne 24. 11. 22 v 11:41 Pieter Lexis napsal(a): I wonder if it should update RFC 6891 and all related OPTION RFCs as well. I'm not sure as well. I also wonder if it could make sense to add guidance on how to choose the correct presentation format for newly drafted EDNS options so

[DNSOP] Subject: request for adoption: draft-edns-presentation

Hi DNSOP, we have prepared a specification document (see below), which fills a gap that appears to be missing currently — The EDNS(0) textual and JSON format. It also fixes a "specification bug" in an existing and related RFC. We believe this draft is pretty much complete and have a first PoC

Re: [DNSOP] .alt filtering in recursive servers

Dne 11. 11. 22 v 10:48 Wessels, Duane napsal(a): 5. Authoritative DNS Servers: Authoritative servers MUST respond to queries for .alt names with NXDOMAIN. I don't like to repeat myself, but I still consider this requirement proposal inproper and I disagree with it. The

Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on glue definition

Hi, regarding the question of "necessary" versus "useful". I apologize, but I must kind-of undermine the question. Imagine that a delegation is supplemented with an SVCB record that describes how to connect securely (with TLS) to the delegated nameserver. (Dunno if this really can happen

Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on historical definition of bailiwick

Hi, I'm trying to understand this, but not sure if I do. What I see is: "The definition of bailiwick (in-b, out-of-b) is messed up and any further use of it in normative documents will probably lead to ambiguities. The proposed tactic is to stop using it and define a new term (in-domain)

Re: [DNSOP] [Ext] root crud, Possible alt-tld last call?

Dne 26. 10. 22 v 19:02 Klaus Frank napsal(a): I don't quite understand what the controversial part with this is, but why not just copy RFC7686 (onion special use domain name) for .ALT? Please don't. RFC7686 requires that all DNS software, both recursive and authoritative, treats .onion in

Re: [DNSOP] [Ext] Possible alt-tld last call?

Dne 24. 10. 22 v 20:18 David Conrad napsal(a): Libor, On Oct 24, 2022, at 9:11 AM, libor.peltan wrote: The root of the DNS is a commons, supported by volunteers who are paying out of their own pocket to provision a global infrastructure. I’m personally not comfortable recommending

Re: [DNSOP] [Ext] Possible alt-tld last call?

Hi, Dne 23. 10. 22 v 21:00 David Conrad napsal(a): The root of the DNS is a commons, supported by volunteers who are paying out of their own pocket to provision a global infrastructure. I’m personally not comfortable recommending techniques that can add undefined (could be minimal, might

Re: [DNSOP] Representing DNS Messages in JSON (RFC 8427): ugly EDNS

Hi, Dne 13. 09. 22 v 18:21 Viktor Dukhovni napsal(a): The "OPT-RR" is message metadata, and so should not be confused with other sorts of additional records. (TSIG would also fall into that bucket). Thank you for this point. So we should invent a way how to convert OPT record into

[DNSOP] Representing DNS Messages in JSON (RFC 8427): ugly EDNS

Hi all, especially Paul, while implementing RFC 8427 in Knot DNS, we found that this RFC does not say anything about EDNS option. This results in general rules for RR being applied, resulting in very ugly:   "additionalRRs": [     {   "NAME": ".",   "TYPE": 41,   "TYPEname":

Re: [DNSOP] New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-01.txt

Hi Willem, Yorgos, Roy, dnsop, I dare to repeat my support for the ideas in dry-run-dnssec draft. However, I still don't like the suggested format of dry-run DS record. Another alternative idea: how about putting the Digest Type into the first octet of Digest field like in the draft, but

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

Hi Peter, Nils, DNSOP, In general, I very much like the Bootstrapping idea, and the draft. I also like that it now allows in-bailiwick NS (unless in-bailiwick-only). However, I'd like to discuss if it really should *replace* RFC8078, Section 3 whatsoever. Sure, it's definitely more secure

[DNSOP] draft-yorgos-dnsop-dry-run-dnssec-00 and DS digest field

Hi dnsop, Yorgos, Willem, Roy, I really like this idea of dry-run DNSSEC. I think it could really help new DNSSEC adopters. The evidently weird thing of the proposal is the displacement of DS digest field into the first byte of DS hash field, in order to free up space for dry-run signalling.

Re: [DNSOP] On removing a pargraph in RFC4035

d at scale if this rule were in place. On Sun, Mar 20, 2022 at 4:42 PM libor.peltan wrote: Hi Ulrich, dnsop, thank you for your effort in improving DNS. This is a follow-up to your proposal on easing the requirements by RFC4035, which say, in short, that if there's a DS of an

[DNSOP] On removing a pargraph in RFC4035

Hi Ulrich, dnsop, thank you for your effort in improving DNS. This is a follow-up to your proposal on easing the requirements by RFC4035, which say, in short, that if there's a DS of an algorithm, there must be a complete DNSKEY set of that algorithm, and if there is a DNSKEY of an algorithm,

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

Hi Philip, Dne 01. 12. 21 v 11:46 Philip Homburg napsal(a): qqq.slackexperts.com. 2370IN NSEC\000.qqq.slackexperts.com. RRSIG NSEC This is returned in response to a query. The intent was that the NSEC record should have the 'A' bit as well. What exactly do Knot and

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

Hi Paul, for any non-root server, an RD=0 question for example.onion should be answered with SERVFAIL. this is a condition signal, and the condition is "since i'm hearing this query, someone thinks i'm holding a delegation, and i'm not, so i might be lame for some zone, so the server (me,

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

Hi John, If a query for a special use name, whether it's foo.onion or 7.8.9.10.in-addr.arpa, leaks to an authoritative server, NXDOMAIN is the right answer. not really. First of all, in-addr.arpa. zone is normal part of DNS tree and various authoritative (depends for which zone) servers

Re: [DNSOP] Status of draft-ietf-dnsop-dns-error-reporting

Hi Roy, Change 2) There was an observation by developers that some authoritative servers do not parse (unknown) EDNS0 options correctly, leading to an additional roundtrip by the resolver. It was suggested that authoritative servers could return the new EDNS0 option “unsolicited”. This is

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

Hi, I'm just not sure if this requested SHOULD->MUST change would actually have any consequences. It still doesn't say anything about what authoritative, and recursive servers should do. The draft's sections about authoritative server behavior are somewhat brief, but that may be OK. In

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

Hi all, although for me, as an implementer of an auth server, it's not too important, I'd like to ask for clarification regarding the foreseen reporting domain(s) setup in the (usual) case of many secondary auth servers. The draft says: "Each authoritative server SHOULD be configured with a

Re: [DNSOP] The DNSOP WG has placed draft-salgado-dnsop-rrserial in state "Call For Adoption By WG Issued"

Hi, just an idea: I don't know how important the amplification factor is. If it is, the proposed EDNS option would have the advantage of practically no answer:query amplification, unlike multi-query or additional SOA. Libor Dne 28. 05. 21 v 21:27 Peter Thomassen napsal(a): Hi, I like the

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

Hi all, just my comment: Perhaps complexity is subjective.  The important thing is that the standard be reasonably implementable.  I hope that the list of published implementations [3] will serve as convincing evidence that the current draft is sufficient in that regard. --Ben I agree

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

Hi Ben, Dne 11. 05. 21 v 18:08 Ben Schwartz napsal(a): On Tue, May 11, 2021 at 3:31 AM libor.peltan <mailto:libor.pel...@nic.cz>> wrote: If there really is a strong reason for putting multiple key-value records into one RData (instead of one RRSet), it should be

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

Hi all, this is actually not the first time someone has come with this issue: https://mailarchive.ietf.org/arch/browse/dnsop/?gbt=1=WxZLxeJF3vSHiOG0jGm8kek5ajI If there really is a strong reason for putting multiple key-value records into one RData (instead of one RRSet), it should be

Re: [DNSOP] NXDOMAIN and RFC 8020

Hi Murray, if foo.example does not exist and DNSSEC is in place, than the resolver actually, even with the queries "in reverse order", obtains and NSEC(3), proving non-existence for much more. For example, the query is bar.foo.example, and the authoritative returns an NSEC proving that

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

FYI in Knot DNS, the implementation is at exactly the same state: an existing merge request. For us, it's technically no issue if the presentation/wire format changes during next few weeks. I'm saying nothing about ideological consequences of such approach. /Libor Dne 19. 03. 21 v 0:05 Mark

Re: [DNSOP] [Ext] DNSSEC Strict Mode

Hi Ben, Dne 25. 02. 21 v 1:50 Ben Schwartz napsal(a): On Wed, Feb 24, 2021 at 6:57 PM Brian Dickson mailto:brian.peter.dick...@gmail.com>> wrote: That's not possible. The DS records are on the parent side (TLD) and the TTL is set by the TLD per whatever their standard policy

Re: [DNSOP] [Ext] DNSSEC Strict Mode

Hi Ulrich, please see below.. Libor Dne 24. 02. 21 v 16:01 Ulrich Wisser napsal(a): On 23 Feb 2021, at 17:49, Ben Schwartz > wrote: On Tue, Feb 23, 2021 at 11:21 AM Samuel Weiler > wrote: ... Recognizing that I'm

Re: [DNSOP] DNSSEC Strict Mode

t to enforce this rule then we need a signal (or we need to update RFC 6840). On Tue, Feb 23, 2021 at 10:17 AM libor.peltan <mailto:libor.pel...@nic.cz>> wrote: Hi Ben, could you please briefly summarize how this relates to last paragraph of https://tools.ietf.org/html

Re: [DNSOP] DNSSEC Strict Mode

Hi Ben, could you please briefly summarize how this relates to last paragraph of https://tools.ietf.org/html/rfc4035#section-2.2 ? The way how I understand it, each DNSKEY already must be treated as the proposed "strict" mode, thus this proposal is completely useless. Thanks, Libor Dne

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

Hi Ben, all, i'd like to ask for some clarification of expected Authoritative server behaviour around Alias SVCB records: 1) when there are multiple Alias SVCB records for an owner name, should the Authoritative server put targeted records into Additionals for all of them, or just pick one?

[DNSOP] Additional EDE codes for resource limits

Hi all, I just suggest a discussion about some more error codes for EDNS Extended Errcode (EDE). In some cases, a server (authoritative or recursive) is not able/willing to answer the query, because: 1) it lacks resources 2) rate-limiting was applied Do you think it would be useful to have

Re: [DNSOP] zone contents digest and DNSSEC stuff

Hi Joe, Dne 29.09.20 v 15:03 Joe Abley napsal(a): The other use case I seem to think you're implying is that a consumer of the signed zone could verify that it was intact using the signed-zone ZONEMD, then strip the DNSSEC RRs and retain the ability to verify that the result was an accurate

[DNSOP] zone contents digest and DNSSEC stuff

Hi, I don't fully know the background of this topic, so my question might be dumb. 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

Re: [DNSOP] Authoritative servers announcing capabilities

Let me leave some personal opnion/comments on this AUTHINFO idea, although I don't know the background here. There are multiple kinds of "capabilities" of an authoritative server. Some of them are properties of the zone, some are properties of the DNS server implementation, some are

Re: [DNSOP] Question regarding RFC 8499

Hi, just a factual comment. While primary/secondary = master/slave is indeed a recent transition of terms among DNS community, and I agree that this should be handled carefully when writing new RFCs, parent/child is a different relation: `com.` domain is the parent of `example.com.`. I

[DNSOP] Comments on draft-ietf-dnsop-svcb-https

Hi all, i'm a developer of Knot DNS authoritative server. I have some comments on the SVCB draft and some suggestions for improvements. Just consider my thoughts and then do whatever is best. (1) The format of SVCB (and HTTPS) RR is too complicated, especially for parsing presentation