Re: [DNSOP] [Ext] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9

On Fri Jan 20, 2023 at 6:53 PM UTC, Paul Wouters wrote: > It seems there should be more discussion which hopefully would lead to > a converging BCP before moving forward. Hearing from other main > implementations would be extremely helpful here. i have always been a fan of ISC's work, but i agree

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

thanks for this. can you propose new text? educating the authors to the point where they can speak for your experience may be error prone. re: Vladimír Čunát wrote on 2023-01-28 09:42: With Knot Resolver + Knot DNS the fragmentation issues are currently being addressed quite simply: *

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

Joe Abley wrote on 2022-11-07 13:38: ... I continue to think the necessary/useful debate is a silly one. In the context of a referral response, glue means additional-section records that the sender of the referral imagines might possibly be helpful to the receiver (which in turn means it

Re: [DNSOP] Updated: Compact Denial of Existence

Shumon Huque wrote on 2023-03-14 09:05: ... So, I think the only way we could safely do RCODE replacement for signed responses is by the use of an EDNS signal. sadly, +1. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC

Florian Obser wrote on 2023-03-01 22:42: I might not be caffeinated enough yet, but I think the next domain name in section 5 should be \000.ent1.example.net: ent1.example.net. 3600 IN NSEC \000.ent1.example.net. RRSIG NSEC ENT In section 6, calling getaddrinfo() return values

Re: [DNSOP] Updated: Compact Denial of Existence

Peter Thomassen wrote on 2023-03-05 14:56: (Compact NSEC answers prevent zone enumeration just as well, if not better.) that makes it even cooler, and it was already cool. (so long as the nxdomain signal is not suppressed as in the cloudflare prototype.) -- P Vixie

[DNSOP] can someone forward this to benno?

i don't know why it was rejected as spam but his sysadmin might. --- Begin Message --- This is the mail system at host ietfa.amsl.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send

Re: [DNSOP] Call for Adoption: Compact Denial of Existence in DNSSEC

Shumon Huque wrote on 2023-04-26 08:43: I support adoption too. As I've mentioned earlier, this mechanism is widely deployed and needs a published specification. Adopting the work will also allow us to formally specify an accurate NXDOMAIN signal (and work out its related details more

Re: [DNSOP] [Ext] Meaning of lame delegation

Peter Thomassen wrote on 2023-04-15 10:13: On 4/10/23 15:39, Wessels, Duane wrote: “A lame delegation is said to exist when one or more authoritative servers designated by the delegating NS rrset or by the apex NS rrset answers non-authoritatively for a zone”. ... or by the *child's*

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

Joe Abley wrote on 2023-05-01 14:15:> Yes -- some people (not me) would evidently describe a server that they didn't receive a response from as lame. Such a situation could be a result of a bad configuration but also any number of other things, such as a network problem or a misconfigured

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

Wes Hardaker wrote on 2023-05-01 14:57: Paul Vixie writes: if we need more terms let's invent. but this term has established meaning. There I fixed it for you: that's a meme, right? If we need more terms let's invent. But this term has established meaning*s*. the first use is still

Re: [DNSOP] [Ext] Meaning of lame delegation

Wessels, Duane wrote on 2023-04-10 06:39: I think Paul’s definition is good and matches the way I think of a lame delegation. My one quibble would be with the ending part that says “that zone is said to have…” This is somewhat confusing because the definition combines both a parent-child

Re: [DNSOP] Updated: Compact Denial of Existence

Joe Abley wrote on 2023-03-29 01:56: Hi Paul, On Tue, Mar 28, 2023 at 14:51, Paul Vixie ... for perspective, no root name server has deployed this alternative form of Denial of Existence, ... Root servers don't do online signing; they serve a pre-signed zone. They don't have

Re: [DNSOP] Updated: Compact Denial of Existence

Christian Elmerot wrote on 2023-03-29 08:24: On 2023-03-29 15:45, Paul Vixie wrote: however, olafur's original CF blog post about CDoE also talked about packet size (desiring explicitly to fit in 512b). justification was about fragmentation avoidance, not CPU time needed to construct

Re: [DNSOP] Meaning of lame delegation

Joe Abley wrote on 2023-04-04 09:14: > ... I think it's pretty common to talk about one nameserver for a zone being lame and another nameserver for the same zone not. Certainly that's not an uncommon configuration to find in the wild. I have always used "lame delegation" to refer to the

Re: [DNSOP] Updated: Compact Denial of Existence

see inline. Viktor Dukhovni wrote on 2023-03-27 18:00: [ Multi-response to four upthread messages. ] --- ... A possibly inconvenient question, just to make sure we're not ignoring the obvious sceptical position: * How compelling is compact DoE? that may depend on the beholder's eye.

Re: [DNSOP] draft-dulaunoy-dnsop-passive-dns-cof

Robert Edmonds wrote on 2023-06-29 14:58: Tim Wicinski wrote: ... Feedback Welcome tim ... I originally developed one of the implementations named in this draft [1] and if I recall correctly it did not occur to me that the API I was developing should ever be standardized, let alone the

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

Joe Abley wrote on 2023-07-17 12:50: On Mon, Jul 17, 2023 at 21:41, Brian Dickson > wrote: TCP traffic is several orders of magnitude more expensive than UDP. Anything that bumps up the proportion of TCP

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

John R. Levine wrote on 2023-07-17 18:22: On Mon, 17 Jul 2023, Shumon Huque wrote: ... This is not a new issue. It is the well known record subtyping problem that was advised against in RFC 5507 (IAB; "Design Choices When Expanding the DNS"). That advice was targeted to new RR type design,

Re: [DNSOP] should all ccTLD be on the Public Suffix list?

George Michaelson wrote on 2023-07-18 17:42: I know, I could submit these to the PSL website directly. I am asking a meta question: do we think that operationally, if a PSL exists, that all ccTLD and TLD should be on it? no. as we learned from delegation-only, some TLDs don't. i see ~36mil

Re: [DNSOP] should all ccTLD be on the Public Suffix list?

George Michaelson wrote on 2023-07-18 22:41: ... my concerns with the PSL governance aren't relevant either. I am sure it was purposeful. I don't have to like things for them to provide upsides. when we've tried to talk about solving the PSL's original problem differently, we've run into

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

John Levine wrote on 2023-07-19 14:43: It appears that Paul Wouters said: On Jul 17, 2023, at 22:50, Paul Vixie wrote: ... RFC 4408 was folly. ... The IETF did make a mistake there for sure. I wouldn't disagree, but you can barely see the spots in the dirt where the barn was before

Re: [DNSOP] Compact DoE sentinel choice

on "mollify". Viktor Dukhovni wrote on 2023-07-25 22:59: On Tue, Jul 25, 2023 at 08:19:21PM -0700, Brian Dickson wrote: At the name that does not exist, generate and sign (on the fly) a CNAME record with RDATA of something like "nxname.empty.as112.arpa" (or something functionally equivalent).

Re: [DNSOP] Clarifying motivation for Compact DoE

see inline. Shumon Huque wrote on 2023-08-08 12:13: At any rate, as I've remarked before, I'm not convinced that the optimizations offered in Compact DoE were actually necessary as an operational matter. But I'll leave it to our colleagues at Cloudflare to argue that case. My interest in

Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?

George Michaelson wrote on 2023-07-26 16:11: ... maybe the truth is, we've got 15 bits of zero in the header forever, amen. that's how i treated it when i crafted EDNS0. we'd have to negotiate any new use, and we've since learned that billions of middleboxes will treat that as a 16-bit

Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-avoid-fragmentation-16: (with COMMENT)

Paul Wouters via Datatracker wrote on 2023-12-29 11:37: Paul Wouters has entered the following ballot position for draft-ietf-dnsop-avoid-fragmentation-16: Yes -- COMMENT:

Re: [DNSOP] Artart telechat review of draft-ietf-dnsop-avoid-fragmentation-16

Barry Leiba via Datatracker wrote on 2023-12-29 19:40: Reviewer: Barry Leiba Review result: Ready with Nits Thanks for addressing most comments from my earlier review. One remains, and I didn’t see an email response about it, so I don’t know whether there was a reason not to make a change or

Re: [DNSOP] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt

zuop...@cnnic.cn wrote on 2024-01-06 22:59: ... Aggressive NSEC (RFC 8198) is useful against to NXNSAttack –like attack, because it allows a DNSSEC-validating resolver to generate negative answers within a range. ... have you looked at dns rrl? ... But if a NSEC3 RR has an Opt-Out flag,

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-explicit-forged-answer-signal-00.txt

i think you mean RPZ here. Paul Wouters wrote on 2024-01-10 07:01: On Wed, 10 Jan 2024, Lanlan Pan wrote: I have submitted a new draft to discuss the faked answer returned from the recursive resolver. Your comments are appreciated. As I've said during the discussions on RBL and an updated

[DNSOP] PolarDNS

saw this today, looks damned useful. https://www.helpnetsecurity.com/2023/11/21/polardns-open-source-dns-server/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Documenting DELEG design trade-offs

i do not foresee a time when any dns protocol agent won't need NS support any more, nor also UDP/53 support. so DELEG can at best add features for its adopters at the expense of permanent added complexity for the specification and for the system. i realize that in today's client/server model

Re: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS)

thanks rob for your long service. we'll do as you suggest. Rob Wilton (rwilton) wrote on 2024-01-29 02:48: Hi Authors, Just a note/reminder that I am stepping down as an AD in March.  I don’t think that I’ve seen any reply to my DISCUSS comments (perhaps the authors and/or WG are still

Re: [DNSOP] BoF: New DNS Delegation, was DELEG Capabilities BoF

Thanks Roy. Would a new working group be open to skeptics? I remain concerned about gradually increasing systemic complexity, and I have some ideas about how some stated goals of the DELEG proposal could have complexity increase precisely linear to new functionality -- so, extending beyond but

Re: [DNSOP] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt

d, propose corresponding solutions that can be achieved through extending DNS, or assuming DNSSEC and simpler optimizations based on DNSSEC. BR, Zhiwei 在 2024/1/7 18:01, Paul Vixie 写道: zuop...@cnnic.cn wrote on 2024-01-06 22:59: ... Aggressive NSEC (RFC 8198) is useful against to NXNSAttack –li

Re: [DNSOP] unrelated name server name recommendation

Paul Wouters wrote on 2024-03-04 11:14: On Mar 4, 2024, at 14:04, Paul Vixie wrote: this means a zone will always be reachable through at least one in-zone data path (name server name and associated address records.) the result would be that a full resolver would never have to pause its

Re: [DNSOP] unrelated name server name recommendation

Ben Schwartz wrote on 2024-03-04 07:20: To rephrase, it sounds like you are proposing a rule that zones should be configured to use at most one glueless delegation step. i think it's the inverse. according to fujiwara-san's comments each zone must have at least one in-zone name server

Re: [DNSOP] Do we need new draft that recommends number limits ?

<> +1. p vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

<    5   6   7   8   9   10