[DNSOP] Re: [dd] Root DS/DELEG query

> On Jul 22, 2025, at 6:11 PM, Petr Špaček wrote: > > Hi all. > > I wonder how to interpret '. DS'/'. DELEG' queries and welcome opinions! > ... > With strict interpretation of 'DS lives at parent' I would argue '. DS' > should result in SERVFAIL: No parent for . can be contacted. > ... > Nee

[DNSOP] Re: Fw: New Version Notification for draft-ubbink-zoneversion-extended-00.txt

Hi Stefan! I read through your draft and have the following comments and suggestions: I understand the idea is to define a new ZONEVERSION type. Whereas the SOA-SERIAL type copies the SOA SERIAL number into the zone version option, this one would would copy a value from a TXT RR with a well-kn

[DNSOP] Re: Call for Adoption: draft-davies-internal-tld

> On Apr 18, 2025, at 1:24 AM, Philip Homburg > wrote: > > > The current draft contains the following text: > DNSSEC validating resolvers will fail to resolve names ending in "internal". > That sentence doesn’t sit very well with me. I configured .internal as an auth-zone in my instance of

[DNSOP] Re: Call for Adoption: draft-davies-internal-tld

> On Apr 17, 2025, at 12:00 PM, Jim Reid wrote: > > > > >> On 17 Apr 2025, at 08:39, Joe Abley wrote: >> >> Whether or not people use INTERNAL is an entirely untested question. Perhaps >> if we had statistically-significant data that showed leaked INTERNAL queries >> actually existed and

[DNSOP] Re: Call for Adoption: draft-davies-internal-tld

> On Apr 17, 2025, at 11:22 AM, Jim Reid wrote: > > > Well there is the cost of setting up and maintaining some sort of registry > which fully documents these special TLDs.* And the layer-9+ bickering over > what does and doesn't go into this registry, who gets to decide, defining the > cri

[DNSOP] Re: Call for Adoption: draft-davies-internal-tld

I am in favor of adopting this document. DW > On Apr 15, 2025, at 1:38 AM, Benno Overeinder wrote: > > All, > > At IETF 122, there appeared to be some agreement to adopt this work within > DNSOP. > > Below are the relevant meeting minutes and a link to the presentation from > the session:

[DNSOP] Re: New Draft: Standardized Query Name for DNS Resolver Reachability Probes

> On Feb 19, 2025, at 8:00 PM, Ben Schwartz > wrote: > > Hi DNSOP, > > John Todd, Puneet Sood, and myself have just posted a new draft [1] with a > very simple premise: if you're sending queries to a resolver just to see if > you get a response, query "probe.resolver.arpa". This name is (p

[DNSOP] Re: Is .INTERNAL a special use domain name?

> On Feb 13, 2025, at 5:39 PM, Warren Kumari wrote: > > > >> On Wed, Feb 05, 2025 at 9:39 AM, Duane Wessels >> wrote: >> >> >> The text for RFC 6761 consideration 4 should be similar to those others, >> e.g.: >> 4. Caching DNS servers SHOULD, by default, recognize .internal >> names as

[DNSOP] Re: [Ext] Re: Speaking of names that don't exist

> On Feb 11, 2025, at 9:11 AM, Paul Hoffman wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > On Feb 11, 2025, at 08:46, John Levine wrote: >> >> It appears

[DNSOP] Re: Is .INTERNAL a special use domain name?

> On Feb 4, 2025, at 4:49 PM, Kim Davies wrote: > > > Hi folks, > > We have published a new version of the draft intended to document the > .internal top-level domain. > (https://datatracker.ietf.org/doc/draft-davies-internal-tld/ >

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

Thanks for considering my various suggestions. > On Jan 30, 2025, at 7:39 PM, Shumon Huque wrote: > > > >Additional validation queries for the "glue" address RRs of referral > >responses (if not already authoritatively present in cache) SHOULD be > > I found this a little confusing at

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

Willem/Shumon/Paul, Here’s some comments on draft-ietf-dnsop-ns-revalidation-08.txt >Resolvers should also periodically revalidate the >child delegation by re-querying the parent zone at the expiration of >the TTL of the parent side NS RRset. The TTL for delegation revalidation is t

[DNSOP] Re: Idea for extending ZONEVERSION

> On Nov 7, 2024, at 8:38 PM, Stefan Ubbink > wrote: > > On 7 Nov 2024 18:36:34 + > "John Levine" wrote: > >> It appears that Shane Kerr said: >> Since I noticed the ZONEVERSION RFC 9660, I was thinking that >> this could be extended to include a version at the database.

[DNSOP] Re: Fwd: New Version Notification for draft-ietf-dnsop-zoneversion-10.txt

> On Jul 18, 2024, at 11:03 AM, Petr Špaček wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > On 18. 07. 24 17:28, Shane Kerr wrote: >> Petr, >> On 18/07/2024 17.

[DNSOP] Re: Fwd: New Version Notification for draft-ietf-dnsop-zoneversion-10.txt

Hi Philip, thanks for the feedback. > On Jul 16, 2024, at 1:46 AM, Philip Homburg > wrote: > >> the changes from draft-ietf-dnsop-zoneversion-09 to -10 address or >> incorporate the following points recently raised: > > Sorry for the late response. I didn't pay much attention to the actual > w

[DNSOP] Re: Dnsdir last call review of draft-ietf-dnsop-zoneversion-10

> On Jul 10, 2024, at 3:09 AM, Nicolai Leymann via Datatracker > wrote: > > The draft is going to be published as Informational RFC. The document is well > written and defines an EDNS option which can be used for debugging purposes. Thank you for the review! Note that as of -09 the intended

[DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-domain-verification-techniques-05.txt

I read through draft-ietf-dnsop-domain-verification-techniques-05 and have a few minor comments / suggestions. > this may result in IP fragmentation, which often does not work While it’s true we have come to agree that fragmentation is bad for DNS, I think “often does not work” overstates the

[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-zoneversion-10.txt

All, the changes from draft-ietf-dnsop-zoneversion-09 to -10 address or incorporate the following points recently raised: - Removed from abstract (Roman Danyliw) - RFC 8499 -> RFC 9499 (Roman Danyliw) - Incorporated Joe Abley's proposed text for "enclosing zone" - Instruct responders to return

[DNSOP] Re: Last Call: (The DNS Zone Version (ZONEVERSION) Option) to Informational RFC

> On Jul 4, 2024, at 1:55 AM, Petr Špaček wrote: > > > Unrelated thoughts: > > ### OPCODE > Currently the document sorta implicitly talks about DNS queries - mainly > implied by the structure of section 3.2 and listed possible answer types and > RCODEs. > > Should the document be explicitl

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

Hi Murray, I don’t believe your comments have been addressed yet. My apologies for the delay. > On Jun 19, 2024, at 10:13 PM, Murray Kucherawy via Datatracker > wrote: > > > -- > COMMENT: >

[DNSOP] Re: Roman Danyliw's No Objection on draft-ietf-dnsop-zoneversion-08: (with COMMENT)

Hi Roman, I wanted to let you know that we’ve incorporated these changes into the document, even though they weren’t reflected in the -09 version that was posted just the other day. DW > On Jun 18, 2024, at 11:57 AM, Roman Danyliw via Datatracker > wrote: > > > >

[DNSOP] Re: [Ext] Re: Paul Wouters' Discuss on draft-ietf-dnsop-zoneversion-08: (with DISCUSS and COMMENT)

> On Jun 18, 2024, at 10:49 AM, Paul Hoffman wrote: > > Responding to one bit of Duane's response. > > On Jun 18, 2024, at 10:40, Wessels, Duane > wrote: > >>> What should an authoritative nameserver return as zone version if it is >>> configur

[DNSOP] Re: Paul Wouters' Discuss on draft-ietf-dnsop-zoneversion-08: (with DISCUSS and COMMENT)

Hi Paul, thanks for the review. Comments inline… > On Jun 17, 2024, at 4:23 PM, Paul Wouters via Datatracker > wrote: > > > > -- > DISCUSS: > -- > > Just

[DNSOP] Re: Artart last call review of draft-ietf-dnsop-zoneversion-07

> On Jun 9, 2024, at 7:13 AM, John Levine via Datatracker > wrote: > > > > I wonder about the paragraph "A name server MUST ignore any non-empty > ZONEVERSION payload data that might be present in the query message." It's > not > wrong, but why call out this one particular error and not ot

[DNSOP] Re: Secdir last call review of draft-ietf-dnsop-zoneversion-06

Hi Shawn, Thank you for the review and comments. We’ve fixed the editorial comments you identified. Regarding “decimal integer” — we use that phrase only when describing the presentation format (versus, say, hexadecimal) so we think it is appropriate. However, we would defer to the advice or su

[DNSOP]Re: Second (short) WGLC for draft-ietf-dnsop-zoneversion

Hi Donald, Thanks for the suggestions. We’ve implemented all your suggested changes in the source document. We’ll wait a few days for any more changes and then publish a new revision. DW > On May 12, 2024, at 1:30 AM, Donald Eastlake wrote: > > Caution: This email originated from outside

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-qdcount-is-one

I’ve reviewed qdcount-is-one-02 and find it to be ready for publication as an RFC. DW > On Mar 5, 2024, at 6:51 AM, Suzanne Woolf wrote: > > Hi, > > We're leaving this open a few more days to allow for any other comments. We'd > like to submit it for publication before IETF 119. > > > T

Re: [DNSOP] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt

Hi, some initial thoughts: RFC 2181 says "Data from a zone transfer, other than glue” but this draft doesn’t make any exceptions for glue or non-authoritative data from a zone transfer. Is that intentional? Should RFC 8767 stale data be ranked differently than fresh data? Should EDNS Client S

Re: [DNSOP] [Editorial Errata Reported] RFC9520 (7838)

This errata seems to be valid. I have no idea why the DOI reference changed, but it appears to have changed since it was added to the document in November/December last year. DW > On Mar 5, 2024, at 9:02 PM, RFC Errata System > wrote: > > Caution: This email originated from outside the orga

Re: [DNSOP] unrelated name server name recommendation

I understood Fujiwara’s proposal to be slightly different: If you are a DNS provider (hosting other zones) then the provider should use in-domain name servers. DW > On Mar 4, 2024, at 3:14 PM, Paul Wouters wrote: > > On Mar 4, 2024, at 14:04, Paul Vixie > wrote: >> >> >> >> this means a

Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis

Paul, Here is some specific proposed text to address the concern that I raised: Whereas the priming response is not a referral, and whereas root server addresses in the priming response are therefore not considered glue records, RFC 9471 does not apply to the priming response. Root servers are

Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis

> On Jan 31, 2024, at 5:57 PM, Paul Hoffman wrote: > >> As Mark just clarified. This isn't glue, so perhaps the text just needs >> updating. > > The current text is: > > If some root server addresses are omitted from the Additional section, > there is no expectation that the TC bit in the >

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

I made a pass through the document and have the following feedback. > Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034]. The > scenario used in that description, that of a recursive server that is > also authoritative, is no longer as common. Since RFC 1034 doesn't use the term "pri

Re: [DNSOP] DNS IPv6 Transport Operational Guidelines (draft-momoka-dnsop-3901bis-00)

Hi Momoka, I see that your draft often uses “in-bailiwick” or “out-of-bailiwick”. If you are not already aware, the latest version of the DNS terminology document (draft-ietf-dnsop-rfc8499bis) notes that “bailiwick” should be considered historic at this point. The preferred language is to ref

Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On Sep 20, 2023, at 2:23 PM, Paul Wouters wrote: > > >>> To prevent such unnecessary DNS traffic, security-aware resolvers >>> MUST cache DNSSEC validation failures, with some restrictions. >>> >>> What are these "some restrictions" ? >> >> Here our intention is to update this

Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On Sep 6, 2023, at 8:56 PM, Paul Wouters via Datatracker > wrote: > > > -- > COMMENT: > -- > > Thanks for this document and my apologies for being involve

Re: [DNSOP] Éric Vyncke's Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On Sep 7, 2023, at 4:08 AM, Éric Vyncke via Datatracker > wrote: > > > > -- > COMMENT: > -- > > > # Éric Vyncke, INT AD, comments for > draft-ietf-dnsop

Re: [DNSOP] Zaheduzzaman Sarker's No Objection on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On Sep 7, 2023, at 2:32 AM, Zaheduzzaman Sarker via Datatracker > wrote: > > > > -- > COMMENT: > -- > > Thanks for working on this specification. My revi

Re: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On Sep 6, 2023, at 11:46 PM, Murray Kucherawy via Datatracker > wrote: > > > -- > COMMENT: > -- > > Thanks to Barry Leiba for his ARTART review. > > I th

Re: [DNSOP] Robert Wilton's Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On Sep 5, 2023, at 3:52 AM, Robert Wilton via Datatracker > wrote: > > -- > COMMENT: > -- > > Hi, > > Thanks for working on this document - I'm not a DNS

Re: [DNSOP] Intdir telechat review of draft-ietf-dnsop-caching-resolution-failures-07

Carlos, Thank you for the suggestions. We’ve made all these changes. DW > On Sep 6, 2023, at 1:59 PM, Carlos Pignataro via Datatracker > wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and kno

Re: [DNSOP] Erik Kline's No Objection on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On Aug 27, 2023, at 3:47 PM, Erik Kline via Datatracker > wrote: > > ## Nits > > ### S1.2 > > * "only exacerbated" -> "further exacerbated"? > > Use of "only" here might be misread. > > ### S2.2 > > * s/2001:DB8:1::/2001:db8:1::/g > > in accordance with RFC 5952 section 4.3 > Than

Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-07.txt

DNSOP, This version of the draft addresses various comments from the Artart, Genart, and Dnsdir reviewers: * Artart review: minor editorial clarifications * Genart review: remove confusing and superfluous section references. * Genart review: clarify resolution failure caching t

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-caching-resolution-failures-06

> On Aug 11, 2023, at 5:36 AM, Lucas Pardue via Datatracker > wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > Reviewer: Lucas Pardue > Review result: Ready

Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-06

> On Aug 14, 2023, at 1:40 AM, Peter van Dijk via Datatracker > wrote: > > Reviewer: Peter van Dijk > Review result: Ready with Nits > > Thank you for processing my previous comments. The document is in great shape. > I have one nit: > > One of the new sections based on my earlier comments

Re: [DNSOP] Artart last call review of draft-ietf-dnsop-caching-resolution-failures-06

Thanks Barry for the good feedback. I've updated our source document with the changes you've suggested. DW On 8/9/23, 1:10 PM, "Barry Leiba via Datatracker" mailto:nore...@ietf.org>> wrote: Reviewer: Barry Leiba Review result: Ready with Nits Thanks for a well-written document. I found th

Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-06.txt

DNSOP, Based on some discussions both in person at IETF 117 and on the list, we have updated some of the requirements language for caching resolution failures. We’ve also used an excerpt of Evan’s previous email to the list in the Implementation Status section of the document. It would be nic

Re: [DNSOP] A question on values in draft-dnsop-caching-resolution-failures

Evan, > On Jul 24, 2023, at 10:34 AM, Evan Hunt wrote: > > The original text says a series of seven resolution failures would increase > the duration before a retry to five minutes: 5 seconds to 10 to 20 to 40 to > 80 to 160 to 300. Lowering the starting value to one second means it would > take

Re: [DNSOP] A question on values in draft-dnsop-caching-resolution-failures

Tim, You said you received some operational feedback. I wonder if it would be appropriate to add this operational (or implementation?) feedback to the (currently empty) Implementation Status section that Peter van Dijk suggested we add, in his DNS directorate review? I’m not necessarily oppos

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

> On Jun 30, 2023, at 2:32 PM, Joe Abley wrote: > > > > I have read -04. i like it. I think it's useful and sensible and it should be > published. Whether this particular rev is ready for publication I would say > depends on whether the authors disagree with all the pedantic nonsense that

Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-04.txt

This revision includes some changes in response to Peter van Dijk's DNS directorate review, as well as addressing the left over "for discussion" topics. Although our conversation with Peter may still be ongoing, we wanted to get this version out so that other people can review the document as a

Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-03

Hi Peter, Thank you for the detailed review. Responses from the authors are inline below. > On Jun 26, 2023, at 7:47 AM, Peter van Dijk via Datatracker > wrote: > > Reviewer: Peter van Dijk > Review result: Almost Ready > > I have been selected as the DNS Directorate reviewer for this draf

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

Thanks to all the IESG reviewers for their feedback. We've made the following updates in revision -09: - No more uppercase RFC2119 keywords in the abstract - Added a reference to the DNS terminology RFC - Added a reference to the dig command At this point the authors believe the IESG feedback h

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

My preferred definition is the one originally given by Paul Vixie, amended by myself, and further amended by Peter Thomassen: A lame delegation is said to exist when one or more authoritative servers designated by the delegating NS rrset or by the child's apex NS rrset answers non-authoritatively

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

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 delegation and an apex/self delegation. If we’

Re: [DNSOP] Meaning of lame delegation

Thank you everyone for your feedback on the meaning of lame delegation. I expected some different interpretations, although maybe not this many! I will take this feedback to the SSAC work party for discussion there about whether or not to use the term in the report (perhaps with a disclaimer).

[DNSOP] Meaning of lame delegation

Dear DNSOP, I am participating in an SSAC work party where we are writing about DNS delegations where a delegated name server might be available for registration, allowing an attacker to participate in the resolution for the domain. During report drafting we considered using the term "lame del

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

> On Mar 29, 2023, at 10:53 AM, Shumon Huque wrote: > > On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett wrote: > > On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen wrote: > > > On 3/28/23 03:14, Shumon Huque wrote: > > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni >

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

Thank you authors for the update which addressed my concern about formatting of the special use considerations as an enumerated list. Forgive me if I am being difficult, but I feel that the first sentence of the privacy section, which says “... so should not attempt to be resolved using the glo

Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

I will reiterate some of my concerns with the draft: I find the format of section 3.2 to be very strange. As a paragraph it jumbles some items together. It should be a list format like the ones in RFCs 6761 and 7686. Section 3.2 does not say how applications that do not use .alt should behave

Re: [DNSOP] .alt filtering in recursive servers

I find the latest alt-tld draft to be inconsistent when it first says “[alt names] should not be looked up in a DNS context” and "DNS stub and recursive resolvers do not need to look them up in the DNS context” but then later "Caching DNS servers will treat [alt names] just as they would any other

Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-01.txt

This draft has been updated based on recent feedback. The primary change is that the new version is less prescriptive about how the resolution failure negative cache should work. e.g., rather than saying "Resolution failures MUST be cached against the specific query tuple…” it now says "Resolv

Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-00.txt

Hi Petr, thank you for the feedback! > On Jul 28, 2022, at 5:06 AM, Petr Špaček wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > On 27. 07. 22 19:42, internet-dr

Re: [DNSOP] Call for Adoption: Survey of Domain Verification Techniques using DNS

I support the adoption of this draft. I think there is value in keeping the specific examples (with named companies, etc) but agree with John that placing them in an appendix would be better. DW > On Jul 12, 2022, at 6:29 AM, Tim Wicinski wrote: > > > > This starts a Call for Adoption for

Re: [DNSOP] Quick review of draft-dwmtwc-dnsop-caching-resolution-failures-00

Hi Mukund, > On Jul 12, 2022, at 8:24 AM, Mukund Sivaraman wrote: > > Some comments quickly browsing this draft, as we're handling a quirky > issue around NS timeouts and it looked relevant. > > Firstly, some resolver implementations do cache upstream NS timeouts in > various non-standard ways.

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

> On Apr 25, 2022, at 8:56 AM, Hugo Salgado wrote: > > Thank you very much Duane for the changes. For my part, the paragraph > on the requirements on data in zones and registries seems perfect. > > I also find the new way of mentioning glues for in-domain/sibling > domain name servers clearer.

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

There are three noteworthy changes from the previous version of this draft: 1. We no longer use the term “referral glue”. 2. Instead of introducing new (and likely confusing) terms such as “sibling glue” and “in-domain glue” we now refer to these as “glue for sibling domain name servers” and “g

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

> On Mar 22, 2022, at 6:02 AM, Ralf Weber wrote: > > Moin! > > So to follow up on my comment in the working group on registries not having > anything to do with it. I understand that this drafts is for authoritative > name server implementers, however I think that we should make clear that

Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications

Hi Eugène, I read through the draft and have a few suggestions for you to consider: 1) The CRS and CRC RDATA fields have a lot in common with TXT records. On one hand you might find some benefits from making these new RR types have the same parsing, wire format, and presentation format as TXT

Re: [DNSOP] DNS RFC Collection web site somewhere.

> On Mar 30, 2022, at 1:27 PM, Raymond Burkholder wrote: > > > Hello, > > There once was a link posted to a web site which attempted to collect/collate > all the RFCs referencing DNS. Is this the one: https://rfcs.io/dns Or is > there another? > Some others: https://powerdns.org/dns-c

Re: [DNSOP] Call for Adoption: DNSSEC as BCP: draft-hoffman-dnssec

> On Mar 24, 2022, at 4:07 PM, Tim Wicinski wrote: > > > All > > If you attended the most recent DNSOP session, you've heard Warren speak > about creating a BCP for DNSSEC, including all of the DNSSEC related RFCs, > in order to make life easier for implementers and DNS operators. > > W

Re: [DNSOP] More private algorithms for DNSSEC

Hi Paul, I think this is good. Is it in response to the DNS-OARC talk we saw about implementing PQC Falcon in PowerDNS, and they used the next unused algorithm number rather than a private algorithm? If the authors of that work are on this list I would be interested to hear from them about tha

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

Hello DNSOP, Here is a short summary of the changes between -03 and -04 of this draft: We use "referral glue" on the assumption that other types of glue may be defined in the future. Not all authors necessarily like this change but we are trying it on for size. Added an Operational Considerati

Re: [DNSOP] Fwd: New Version Notification for draft-dwmtwc-dnsop-caching-resolution-failures-00.txt

the same topic - this new one and > draft-moura-dnsop-negative-cache-loop. > > Perhaps authors could discuss if they are in agreement and could pick one? > > Petr Špaček @ Internet Systems Consortium > > > > On 14. 01. 22 19:14, Wessels, Duane wrote: >> D

[DNSOP] Fwd: New Version Notification for draft-dwmtwc-dnsop-caching-resolution-failures-00.txt

Dear DNSOP, In light of some recent events and research, we feel that it could be beneficial to strengthen the requirements around negative caching of DNS resolution failures. Please see the recently submitted Internet Draft referenced below and let us know if you have any feedback. DW Begin

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

work, perhaps similar to TsuNAME-style external delegation cycles. 2. increases response sizes, truncation probability, and amount of TCP. DW > On Oct 11, 2021, at 4:51 PM, Wessels, Duane wrote: > > Dear DNSOP, > > Changes to this draft from the previous version

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

hCFF99bFT9_oUKN8EogHEJZysGMZyiVkG-AK2oOzI9kNaghHqRWls10qqte96vadcqFsjLZtvYgr9IPUB4UMR8QrUvCZNrS4oGYTUmwWdPB1_hRkrOg5Hu6/https%3A%2F%2Fgithub.com%2Fjtkristoff%2Fdraft-ietf-dnsop-dns-tcp-requirements%2Fpull%2F11 > for some further edits to the text for discuss point (1). > > On Mon, Nov 08, 2021 at 10:35:21PM +, Wessels, Duane wr

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

> On Dec 23, 2021, at 10:28 AM, Benjamin Kaduk wrote: > > > Hi Duane, > > On Mon, Nov 29, 2021 at 11:53:48PM +0000, Wessels, Duane wrote: >> >> >>> On Oct 26, 2021, at 4:35 AM, Lars Eggert via Datatracker >>> wrote: > [...] >&g

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

> On Dec 15, 2021, at 5:31 PM, Paul Wouters wrote: > > On Dec 15, 2021, at 18:56, Wessels, Duane > wrote: >> >> For me “necessary” is an important distinction and “might be useful” is too >> broad or ambiguous. I have a hard time reconciling the idea that

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

ke this definition. However, I think it would be clearer to say "useful" > instead of "necessary". > > On Wed, Dec 15, 2021 at 1:18 PM Wessels, Duane > wrote: > Despite what the subject line says, I’d like to follow up on the discussion > about gl

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

Despite what the subject line says, I’d like to follow up on the discussion about glue from today’s interim meeting. First, I think the definition of glue given in RFC 2181 is problematic in a number of ways. It is overly broad (e.g., "any record ... that is not properly part of that zone” and

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

> On Nov 29, 2021, at 11:51 PM, Lars Eggert wrote: > > >> I dont necessarily agree that operating systems alone do a very good job >> of preventing DOS conditions. It is possible that Im not up-to-date on >> the latest and greatest in terms of operating system features, but I think >> histori

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

> On Nov 8, 2021, at 4:24 PM, Joe Abley wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > On Nov 8, 2021, at 17:35, Wessels, Duane &g

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

> On Oct 26, 2021, at 4:35 AM, Lars Eggert via Datatracker > wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > Lars Eggert has entered the following ballot p

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

Hi Ben, thank you for the detailed review. It has taken me a while to work through all of your comments and suggestions, but hopefully this addresses them sufficiently. > On Oct 25, 2021, at 3:51 PM, Benjamin Kaduk via Datatracker > wrote: > > > ---

Re: [DNSOP] John Scudder's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

John, thanks for the review. > On Oct 28, 2021, at 6:42 AM, John Scudder via Datatracker > wrote: > > > > -- > COMMENT: > -- > > Thanks for the well-writt

Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

Hi Éric, thank you for the review! > On Oct 28, 2021, at 5:33 AM, Éric Vyncke via Datatracker > wrote: > > -- > COMMENT: > -- > > Thank you for the work put

Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

> On Nov 1, 2021, at 3:29 PM, Erik Kline wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > >>> [S4.1, comment] >>> >>> * "Resolvers and other DNS clients should

Re: [DNSOP] Francesca Palombini's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

Francesca, thank you for the review. > On Oct 28, 2021, at 2:43 AM, Francesca Palombini via Datatracker > wrote: > > > > I only have one very minor comments, to take or leave as you please: > > headers are 40 bytes (versus 20 without options in IPv4). Second, it > seems as though some p

Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

Erik, thanks for the review > On Oct 26, 2021, at 1:09 PM, Erik Kline via Datatracker > wrote: > > > > -- > COMMENT: > -- > > [abstract vs. S1/S3, question]

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

Lars, thank you for the review. Some of your easier comments and suggestions have been addressed, but for some of them will require more thought and attention. I am waiting to coordinate with my coauthor, and possibly the WG chairs. > On Oct 26, 2021, at 4:35 AM, Lars Eggert via Datatracker

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

Hi Roman, thanks for the review. My responses are inline. > On Oct 25, 2021, at 3:02 PM, Roman Danyliw via Datatracker > wrote: > > > > -- > DISCUSS: > -- >

Re: [DNSOP] John Scudder's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

> On Oct 28, 2021, at 7:16 AM, Roman Danyliw wrote: > > > [snip] > >> 3. Section 6 says applications should perform “full TCP segment reassembly”. >> What does that mean? A quick google search doesn’t suggest it’s a well-known >> term of art. I'm guessing that what you mean is that the applic

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-13.txt

This version of draft-ietf-dnsop-dns-tcp-requirements includes a number of changes made in response to GENART, SECDIR, ARTART, and TSVART reviews. The notable changes are: - added RFC 1536 as a document that this one updates - new section 2.6. Reuse, Pipelining, and Out-of-Order Processing -

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

Dear DNSOP, Changes to this draft from the previous version are as follows: * Clarified scope to focus only on name server responses, and not zone/registry data. * Reorganized with section 2 as Types of Glue and section 3 as Requirements. * Removed any discussion of promo

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

> On Sep 7, 2021, at 9:42 AM, Mirja Kuehlewind wrote: > > Thanks for the updates! One quick comment below. > >> On 7. Sep 2021, at 18:23, Wessels, Duane wrote: >> >>> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker >>> wrote: >>

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

> On Sep 3, 2021, at 5:29 PM, Jean Mahoney via Datatracker > wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > Reviewer: Jean Mahoney > Review result: Ready w

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

Dan, thanks for the review. Responses are inline. > On Sep 1, 2021, at 3:12 AM, Dan Romascanu via Datatracker > wrote: > > > Minor issues: > > 1. In Section 4.1: > >> DNS clients MAY also enable TFO when possible. > > Maybe I do not fully understand the intent here, but 'MAY ... when pos

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

> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker > wrote: > > > > First a minor comment here: > "TCP connection timeout, which is often around 60-120 seconds." > I guess this value relates to an RTO of 1s and 6 SYN retries which is the > default in Linux. Maybe say that...? I a

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

> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker > wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > Reviewer: Mirja Kühlewind > Review result:

  1   2   3   >