> On 29 Nov 2023, at 1:14 pm, Ben Schwartz wrote:
>
> This draft is essentially identical to -02 except for the new Appendix A,
> which discuss the impact of Unknown Key-Share Attacks:
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-dane-03#name-unknown-key-share-attacks
>
> I
On Mon, Aug 07, 2023 at 08:51:36PM -0400, Shumon Huque wrote:
> Paging this thread back in after a break ...
>
> > For ENTs, there is no inconsistency, the nameserver can return a signed
> > answer with an empty RDATA for the ENTHERE (TBD) rtype.
> >
> > ; QUESTION:
> > ent.example. IN
On Thu, Jul 27, 2023 at 03:04:37AM +, Edward Lewis wrote:
> >2. That said, there are multiple ways to *distinguish* ENT vs. NXDOMAIN
> >responses:
> >
> >a. Sentinel RTYPE for NXDOMAIN with just NSEC + RRSIG for ENT.
> >b. Sentinel RTYPE for ENT with
On Tue, Jul 25, 2023 at 03:39:01PM -0700, Shumon Huque wrote:
> Viktor - your original suggestion was to only define the ENT sentinel
> instead of NXNAME. How would that solve the problem of systems and
> applications needing to precisely obtain the NXDOMAIN signal. Resolvers
> won't then be able
On Thu, Jul 27, 2023 at 09:11:33AM +1000, George Michaelson wrote:
> if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in
> the header.
We don't actually have that freedom. There's no mechanism to make those
bits mean something other than a larger (invalid QDCOUNT) for a normal
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).
Sadly, this reports that the CNAME *target* does not
On Tue, Jul 25, 2023 at 03:39:01PM -0700, Shumon Huque wrote:
> Viktor - your original suggestion was to only define the ENT sentinel
> instead of NXNAME. How would that solve the problem of systems and
> applications needing to precisely obtain the NXDOMAIN signal. Resolvers
> won't then be able
On Tue, Jul 25, 2023 at 10:43:25AM -0700, Shumon Huque wrote:
> Ok, yes, I understand now, thanks. An NXNAME ignorant validator
> will treat a response to a query for the NXNAME type specifically
> as bogus, and could spray a bunch of follow-on queries to other
> servers for the zone before
On Tue, Jul 25, 2023 at 07:35:41AM -0700, Shumon Huque wrote:
> > 2. That said, there are multiple ways to *distinguish* ENT vs. NXDOMAIN
> > responses:
> >
> > a. Sentinel RTYPE for NXDOMAIN with just NSEC + RRSIG for ENT.
> > b. Sentinel RTYPE for ENT with just NSEC +
On Mon, Jul 24, 2023 at 07:08:29PM -0700, Brian Dickson wrote:
> I believe there are three potential query/answer things that on-line
> signers want to compactly respond to:
>
>1. Name exists, other types exist, queried type does not exist
>2. Name exists, no types exist (ENT), queried
In today's session we had some discussion of the choice of sentinel
RTYPEs for ENTs vs. NXDOMAIN.
There isn't much in the meeting to cover the fine details of various
alternatives, so I hope a followup message will make my comments more
clear.
1. I am all in favour of distinguishing NXDOMAIN
[ I hope a brief "public announcement" is not out of place.
The same post will shortly also be sent to dns-operations. ]
Google Public DNS (also "dns.google", or, colloquially, "Quad8") now
includes EDEs in most error responses. For details see:
On Tue, Jul 11, 2023 at 07:06:49PM +, Hollenbeck, Scott wrote:
> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/
>
> The draft includes descriptions of current known practices and
> suggests that some should be avoided, some are candidates for "best",
> and there are
On Sun, Jul 16, 2023 at 03:06:35PM -0400, Viktor Dukhovni wrote:
> I see that draft-dnsop-dnssec-extension-pkix is included on the IETF117 dnsop
> agenda.
>
> https://datatracker.ietf.org/doc/draft-dnsop-dnssec-extension-pkix/
>
> I haven't seen prior discussion of thi
I see that draft-dnsop-dnssec-extension-pkix is included on the IETF117 dnsop
agenda.
https://datatracker.ietf.org/doc/draft-dnsop-dnssec-extension-pkix/
I haven't seen prior discussion of this item on the list, and,
personally, rather suspect it unlikely to gain meaningful support from
the
On Mon, Jul 10, 2023 at 03:48:34PM -0700, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Domain Name
> System Operations (DNSOP) WG of the IETF.
>
>Title : DNS Error
On Mon, Jul 10, 2023 at 10:27:45PM +0100, Roy Arends wrote:
> > Right, but surely the monitoring agent can decide whether to solicit
> > such a prefix label or not. That is whether an "_er" prefix label is
> > signalled is a *local matter* betweent the authoritative server
> > signalling the
On Wed, Jul 05, 2023 at 12:17:34PM +0100, Roy Arends wrote:
> > I would prefer to require resolvers to be more tolerant of unexpected
> > options, and would have servers report the channel without explicit
> > solicitation.
>
> That is indeed the plan. I shall make that explicit in the new
Ben Schwartz writes:
> I wanted to remind DNSOP to take another look at
> draft-ietf-dnsop-svcb-dane [1], which is intended as a straightforward
> clarification of how DANE interacts with SVCB/HTTPS records (and
> QUIC/HTTP/3). I don't think this document is controversial, and I'd
> like to
On Mon, Jul 03, 2023 at 08:25:08PM +0200, Peter Thomassen wrote:
> Now, assume a multi-signer setup of, say, algorithms 7 and 13. This is
> not an uncommon transition (ietf.org did it last month, except that
> they went unsigned). In such a scenario, a resolver on Red Hat would
> only consider
On Thu, Jun 08, 2023 at 11:59:59AM +0200, Benno Overeinder wrote:
> This starts a two week Working Group Last Call process, and ends on:
> June 22nd, 2023.
I hope my feedback is not too late. There are a few important elements
of the draft that could use some changes.
On Tue, Jun 20, 2023 at
On Wed, Jun 14, 2023 at 12:09:23PM -0400, Peter Thomassen wrote:
> > But the focus changes. For example, if we consider that "spoofing by
> > recursive server" is a threat, then having the recursive set bits to
> > affirm that the response is verified is not much of a protection --
> > the
On Wed, Oct 19, 2022 at 03:21:27PM -0400, Tim Wicinski wrote:
> This starts a Working Group Last Call for
> draft-ietf-dnsop-dnssec-validator-requirements
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-validator-requirements/
>
>
> Recommendations for DNSSEC Resolvers Operators
>draft-ietf-dnsop-dnssec-validator-requirements-04
Before I dive into some paragraph-by-paragraph details, and bury the
lede, my main high-level issue is with sections 9, primarily on
substance, but also for IMHO notably
Though this is in fact implicit in RFC4035 Section 6.2, it is perhaps
worth reminding any implementors reading this post (and though absurdly
late, perhaps even adding yet another minor tweak to the document) that
the target name of a SVCB or HTTPS record, though a domain name, MUST
NOT be
> On 11 Apr 2023, at 9:57 am, Edward Lewis wrote:
>
> Sure, the cost of replacing NSEC and NSEC3 would be another resource record
> type code roll
> (such as 5->8, RSA-SHA1 vs RSA-SHA1-NSEC3). But a new on-the-fly denial of
> existence might
> prove to be worth it in operations.
No such
On Mon, Apr 10, 2023 at 01:39:21PM +, Wessels, Duane wrote:
> Perhaps:
>
> "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".
This is a decent definition of the
On Thu, Apr 06, 2023 at 11:13:32PM +0200, Havard Eidnes wrote:
> > Well, one would, in fact, expect a delegation to be a non-authoritative
> > answer:
>
> Yes, but one would presume that before any of the two above
> queries were sent, the recursive resolver already have cached the
> delegation
On Tue, Apr 04, 2023 at 10:48:11PM +0200, Havard Eidnes wrote:
> > At the time such a delegation response is being processed by a resolver,
> > it looks just fine. Nothing to see here, move along (down the tree)...
>
> I disagree. If either ns1.provider.net or ns2.provider.net is not
>
On Tue, Apr 04, 2023 at 06:40:55PM +0200, Havard Eidnes wrote:
> > ; ANSWER
> > ; AUTHORITY
> > example.com. IN NS ns1.provider.net.
> > example.com. IN NS ns2.provider.net.
> >
> > is a valid delegation response (and so not from this perspective a LAME
> > delegation), whether or
On Mon, Apr 03, 2023 at 05:44:04PM -0400, Viktor Dukhovni wrote:
> I believe that the most natural perspective is from the view point of a
> resolver attempting to classify a (non?)response to a query sent to an
> authoritative server.
Another way of thinking about this perspective is
On Mon, Apr 03, 2023 at 08:02:16PM +, Wessels, Duane wrote:
> 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.
[ Multi-response to four upthread messages. ]
---
On Fri, Mar 03, 2023 at 06:23:11PM -0500, Shumon Huque wrote:
> Thanks for your comments. We've posted an updated draft (-01):
>
> https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01
[ Copied from today's
On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> > These “rare” cases where the domain is not resolvable when a glue is not
> > present are the ones this draft is done for. So did you look how rare
> > they were in your dataset? Being able to resolve instead of not resolving
> >
On Fri, Feb 17, 2023 at 01:55:40PM +0900, Masataka Ohta wrote:
> Viktor Dukhovni wrote:
>
> > The draft states that in rare cases sibling glue could be useful, as a
> > result of cyclic dependency loops.
>
> Interesting. Such dependency existed between two TLDs (II
On Tue, Feb 21, 2023 at 11:49:40AM +0100, Ralf Weber wrote:
> > This leaves 6,466 cases to examine more closely:
> >
> >1. 3,773 are in complete agreement with the authoritative A/
> > records.
> >
> >2. 1,447 have authoritative A/ records completely distinct
> > from
On Thu, Feb 16, 2023 at 09:15:35PM -0500, Viktor Dukhovni wrote:
> There are many more. We see a steady stream of sibling-glue-related
> lookup failures, that are only resolved after going to the authoritative
> source for the actual IP addresses of the nameservers in question.
I
On Thu, Feb 16, 2023 at 09:15:35PM -0500, Viktor Dukhovni wrote:
> Perhaps we'll find that we can't distinguish sibling glue from still
> required "orphan glue" (mention of which I see got removed from
> draft-02), and need the sibling glue as a last resort when the forward
On Mon, Oct 10, 2022 at 07:57:45AM -0700, internet-dra...@ietf.org wrote:
> This draft is a work item of the Domain Name System Operations WG of the IETF.
>
> Filename: draft-ietf-dnsop-dnssec-bcp-05.txt
> [...]
> A diff from the previous version is available at:
>
On Sun, Sep 25, 2022 at 08:27:19PM +, Paul Hoffman wrote:
> > In:
> >
> >3. Additional Cryptographic Algorithms and DNSSEC
> >
> > [...]
> > The GOST signing algorithm [RFC5933] was also adopted, but has seen
> > very limited use, likely because it is a national
On Sun, Sep 25, 2022 at 11:11:44AM -0700, Gyan Mishra via Datatracker wrote:
> The document reads well and is ready for publication.
>
> I do not see any issues with the draft.
I largely concur, but do have a few comments:
In the final two sentences of:
1. Introduction
[...]
On Wed, Sep 14, 2022 at 10:42:26AM +0200, libor.peltan wrote:
> 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
&g
On Tue, Sep 13, 2022 at 10:33:44AM +0200, libor.peltan wrote:
> while implementing RFC 8427 in Knot DNS, we found that this RFC does not
> say anything about EDNS option.
One might the case that the EDNS(0) OPT-RR is a "pseudo-RR", and so does
not follow general RR presentation format. Indeed,
On Thu, Sep 08, 2022 at 03:06:45PM +, Paul Hoffman wrote:
> > If no AliasMode record was processed, then $QNAME would be the
> > origin name PLUS the prefix(es) of type attrleaf ( underscore
> > thingies). Those won't be legitimate A/ owner names (and
> > shouldn't exist), and if a client
On Thu, Sep 08, 2022 at 02:08:27PM +1000, Martin Thomson wrote:
> On Thu, Sep 8, 2022, at 13:29, Brian Dickson wrote:
> > If no AliasMode record was processed, then $QNAME would be the origin
> > name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those
> > won't be legitimate
> Yes, and catching COVID on Friday didn't help. Will attempt to send a
> pull request for just the $QNAME fix shortly.
Making a pull request does not preclude also Cc'ing the list. Which
is what I'm doing now and was planning to do in any case:
On Wed, Sep 07, 2022 at 03:36:16PM -0700, Warren Kumari wrote:
> I chatted with Viktor Dukhovni late last week, and he promised us a
> sentence to solve all that ails us… or, at least, a simple, clear, concise
> sentence which only clarifies what appears to have been intended.
>
On Wed, Aug 31, 2022 at 01:39:32AM -0700, Brian Dickson wrote:
> Here are some proposed text changes, per Warren's invitation to send text:
>
> In section 1.2, change:
>
> 2. TargetName: The domain name of either the alias target (for
>AliasMode) or the alternative endpoint (for
On Mon, Aug 29, 2022 at 09:32:24PM +, Warren Kumari wrote:
> > * For the rfc1123 section 2 topic, it may make sense to clarify the text
> > to say "domain name" rather than "hostname":
> >> An "alternative endpoint" is a hostname, port number, and other
> >> associated instructions
On Mon, Aug 29, 2022 at 12:33:55PM -0400, Erik Nygren wrote:
> On paths forward on the draft as it stands to clarify without making
> significant technical changes (which I don't think are necessary):
>
> * Are there particular clarifications we can/should add to help make
> the current behavior
On Thu, Aug 25, 2022 at 09:01:39PM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC9276,
> "Guidance for NSEC3 Parameter Settings".
>
> --
> You may review the report below and at:
>
On Fri, Aug 26, 2022 at 07:29:06AM -0400, Ben Schwartz wrote:
> > I also noted an issue around the initial $QNAME having prefix labels (in
> > the case of SVCB rather than HTTPS), and so this is likely not the name
> > you want appended as a fallback to the target list.
> >
>
> Indeed, I think
On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:
> Relatedly, the results presented by EKR [1] at the most recent DNSOP
> meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS
> records through their local resolver. To me, this implies that functional
> origin
On Wed, Aug 24, 2022 at 07:11:16PM -0400, Eric Orth wrote:
> > Regarless, once AliasMode records are found, these MUST be used and
> > partial lookup failure along a non-empty (so far) alias chain needs
> > to be fatal.
>
> This would be a big non-editorial change from the current draft, and I
>
On Tue, Aug 23, 2022 at 02:51:33PM -0700, Brian Dickson wrote:
>- The problem is whether/when/how the DNS queries are considered
>failures, and whether/when/how some sort of fall-back procedure is followed
>in those cases.
Indeed "failure" may not be consistently defined.
- On the
On Thu, Aug 18, 2022 at 09:12:33AM +1000, Mark Andrews wrote:
> Well anyone using RedHat Enterprise Linux 9 / Oracle Linux 9 already
> has RSASHA1 / NSEC3RSASHA1 disabled.
>
> BIND will automatically disable these algorithms as of the September
> releases if they are not supported by the crypto
On Tue, Aug 16, 2022 at 02:55:35PM +, Paul Hoffman wrote:
> Another way to look at this is not from all signed delegations
> anywhere, but for web sites that are most popular. Using the Tranco
> list, choosing from the top 100,000 names, 6,389 are signed; of those,
> 349 sign with algorithm 5
On Sat, Aug 13, 2022 at 10:48:59PM +1000, Mark Andrews wrote:
> So you are ready to replace SHA1 in NSEC3 and do a second algorithm
> renumber which is what is required to actually get rid of SHA1 or do
> you mean retire RSA-SHA1.
No. Please let's NOT deprecate SHA-1 in NSEC3. The use of
On Mon, Aug 15, 2022 at 09:29:28AM -0400, Paul Wouters wrote:
> I think our decision should be based on the deplyment statistics of SHA1
> based zones and keys. I'd love to see the trending statistics from
> Viktor to guide us here. Last time we looked it was still in the order
> of 40% or so ?
>
On Mon, Aug 15, 2022 at 09:29:28AM -0400, Paul Wouters wrote:
> I think our decision should be based on the deplyment statistics of SHA1
> based zones and keys. I'd love to see the trending statistics from
> Viktor to guide us here. Last time we looked it was still in the order
> of 40% or so ?
On Fri, Jun 24, 2022 at 05:31:28PM +, Eric Vyncke (evyncke) wrote:
> Dear DNSOP,
>
> As this ADD WG document relies on draft-ietf-dnsop-svcb-https from the
> DNSOP WG, as the responsible AD for the ADD WG, I will appreciate your
> review of this short IETF draft.
>
> Abstract
>
>
Is anyone aware of better descriptions of cooperating DNS operator DNS
provider migrations than are found in RFC 6781 section 4.3.5.1
https://datatracker.ietf.org/doc/html/rfc6781#section-4.3.5.1
and Appendix D:
https://datatracker.ietf.org/doc/html/rfc6781#appendix-D
Both descriptions
On Wed, Apr 13, 2022 at 09:37:35AM -0700, Warren Kumari wrote:
>
> Abstract:
> "NSEC3 is a DNSSEC mechanism providing proof of non-existence by promising
> there are no names that exist between two domainnames within a zone."
>
> The "promising" in this feels
On Thu, Mar 10, 2022 at 06:54:07PM +, Paul Hoffman wrote:
> Greetings again. My motivation here is kinda trivial, but I've heard
> it is a common complaint. When writing a about DNSSEC, I need to
> reference the RFC. But it's three RFCs (4033, 4034, and 4035), and
> possibly another (6840).
On Mon, Feb 28, 2022 at 03:43:59PM +0100, Petr Špaček wrote:
> Keep this:
> >>> 3.2. Recommendation for validating resolvers
> >>> Note that a validating resolver MUST still validate the signature
> >>> over the NSEC3 record to ensure the iteration count was not altered
> >>>
On Wed, Dec 22, 2021 at 03:52:22PM -0500, Ben Schwartz wrote:
[ Sorry about the delayed response, on the road since Dec 24th... ]
> I don't want this draft to become an omnibus update to RFC 7671. My goal
> is to produce a short draft that is basically parallel to RFC 7673.
>
> If you want to
On Mon, Dec 13, 2021 at 10:04:55AM -0500, Ben Schwartz wrote:
> >
> > 1. While DANE certificate validation as described in RFCs 7671,7672 and
> > 7673
> > is fine in SMTP, IMAP, XMPP, ... for HTTP (and perhaps some other
> > applications)
> > skipping validation of the target name with
On Sun, Dec 12, 2021 at 09:49:57AM +0100, Philip Homburg wrote:
> >> There is something I don't understand about this draft.
> >
> >The main thing to understand is that complex applications like browsers
> >allow data retrieved from one endpoint to script interaction with a
> >*different*
On Sat, Dec 11, 2021 at 12:24:13PM +0100, Philip Homburg wrote:
> > https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00
> >
> > Thus, unless "UKS" is known to not be a concern, applications
> > should also validate the target name against the server
> > certificate
> On 9 Dec 2021, at 5:32 pm, Ben Schwartz wrote:
>
> This is a very small draft explaining how to do DANE with SVCB, mostly
> following the pattern of DANE-SRV. It also updates DANE for use with QUIC.
>
> Please review.
Initial observations:
1. While DANE certificate validation as
> On 1 Dec 2021, at 4:19 pm, Paul Vixie wrote:
>
> ... but if you're Slack or similar (cloud provider, ISP, MSSP, social network,
> xAAS provider), no automation will ever be good enough by itself (wizards will
> be needed.)
With that qualification, I think we're much less far apart. Yes,
the
> On 1 Dec 2021, at 2:37 pm, Jim Reid wrote:
>
>> Wouldn't that create a vicious circle in which the only way to start
>> operating DNSSEC is already to have operated DNSSEC?
>
> I think we’ve been in that vicious circle (or downward spiral) for several
> years now.
The graph at:
> On 30 Nov 2021, at 1:38 pm, John Levine wrote:
>
> Can or should we offer advice on how to do this better, sort of like
> RFC 8901 but one level of DNS expertise down?
The main advice that comes to mind is to use a DNS hosting provider
with a proven (multi-year) record of doing DNSSEC
> On 29 Nov 2021, at 7:55 am, Michael Bauland wrote:
>
>> The iteration count distribution for the TLDs is presently:
>> # TLDs NSEC3 iterations
>> --
>> 147 0
>> 458 1
>> 1 2
>> 14 3
>> 112 5
>> 4 8
>> 545 10
>> 29 12
>> 1 13
On Fri, Nov 26, 2021 at 12:32:19PM +0100, Petr Špaček wrote:
> Also, when we are theorizing, we can also consider that resalting
> thwarts simple correlation: After a resalt attacker cannot tell if a set
> of names has changed or not. With a constant salt attacker can detect
> new and removed
> On 9 Nov 2021, at 4:11 am, Petr Špaček wrote:
>
> I don't see need to specify _a_ value here. I think better approach is
> acknowledge current state of things. What about something like this?
>
> ---
> As for November 2021, the limit of 150 iterations for treating answer as
> insecure is
> On 8 Nov 2021, at 12:55 pm, A. Schulze wrote:
>
> sorry for maybe asking an already answered question,
> but why is NSEC3 considered to have no benefit at all?
My take is that NSEC3 provides little benefit beyond the initial
(0th) iteration.
> I'm still on "NSEC allow zone-walks while NSEC3
> On 8 Nov 2021, at 6:07 am, Petr Špaček wrote:
>
> TL;DR
> I say we should go for 0 and acknowledge in the text we are not there yet.
This means reaching out to the TLD operators again... They were quite
cooperative ~6 months back, but I wouldn't want to take them for granted
and keep asking
> On 5 Nov 2021, at 3:19 pm, Olafur Gudmundsson wrote:
>
> Publishing iteration count higher than 10 is reckless as that affects the
> performance of recursive resolvers in particular the ones that run on small
> CPE equipment.
>
> The document should strongly discourage any use of NSEC3
>
was 531,146, that seems to be
the lowest realistic limit we can impose, if we're willing to apply enough
pressure to also get the ~66k zones between 21 and 50 to make changes.
> On 4 Nov 2021, at 4:46 pm, Viktor Dukhovni wrote:
>
> Just in case further reductions occurred since mid-Octob
> On 18 Oct 2021, at 12:43 am, Viktor Dukhovni wrote:
>
> We were waiting for TransIP to complete the migration of their managed
> DNS domains from 100 iterations to 0, before collecting fresh NSEC3
> iteration count deployment statistics.
>
> That has now been done, and
On Wed, Oct 27, 2021 at 04:09:01PM -0700, Joey Deng wrote:
> Thanks for the detailed response. I think the 'closest encloser’ proof
> is what I am missing here. It is weird that none of the DNSSEC RFCs
> talk about the closest encloser of NSEC (or maybe I am not aware about
> it).
Perhaps it was
On Tue, Oct 26, 2021 at 10:21:29PM -0700, Joey Deng wrote:
> If the question name appears in-between the current owner name and the
> next owner name of the NSEC record, which means that there is no exact
> name matching: We should prove that no possible wildcard RRset exists
> that could have
> On 22 Oct 2021, at 4:48 am, Vladimír Čunát wrote:
>
> Example micro-benchmark doing just the NSEC3 hashing shows that even quite
> long 32B salt has little effect but 255B adds a noticeable multiplicative
> factor. Therefore I'd suggest that NSEC3 records with salt > 32B may be
> ignored
On Wed, Oct 20, 2021 at 11:24:47AM -0700, Wes Hardaker wrote:
> But, as Viktor indicated in his posts, we could move even lower (100
> being the next obvious step, but even lower is possible to still retain
> a reasonable percentage). But there is of course a risk of we'll never
> get to a
On Mon, Oct 18, 2021 at 12:43:51AM -0400, Viktor Dukhovni wrote:
> On Fri, Oct 15, 2021 at 04:30:37PM -0700, internet-dra...@ietf.org wrote:
>
> > Filename: draft-ietf-dnsop-nsec3-guidance-01.txt
> >
> > Abstract:
> >NSEC3 is a DNSSEC mechanism pr
On Fri, Oct 15, 2021 at 04:30:37PM -0700, internet-dra...@ietf.org wrote:
> Filename: draft-ietf-dnsop-nsec3-guidance-01.txt
>
> Abstract:
>NSEC3 is a DNSSEC mechanism providing proof of non-existence by
>promising there are no names that exist between two domainnames
>
On Sat, Oct 09, 2021 at 07:18:58AM +1100, Mark Andrews wrote:
> Yes it will be unfiltered but the point of DNSSEC is to filter out bad
> answers (that is what the ignore bogus responses achieves) and if you
> are behind a recursive server you need it to do the filtering of the
> answers it gets
On Thu, Sep 09, 2021 at 11:28:04AM -0400, Paul Wouters wrote:
> Looks like for arpa., the DS records are:
>
> arpa. 27247 IN DS 42581 8 1
> 778606D9623F843F156E7D11ACBF815EB67AB516
> arpa. 27247 IN DS 42581 8 2
>
On Fri, Sep 03, 2021 at 09:48:56AM +0200, Vladimír Čunát wrote:
> 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
On Tue, Aug 24, 2021 at 05:23:31AM -0700, Éric Vyncke via Datatracker wrote:
> -- Section 2.1 --
> I support Erik Kline's COMMENT on this and am raising it to a blocking
> DISCUSS.
>
> A/ in all the discussion in the last §, a would have the same benefit
> when
> compared to a NS QTYPE.
> On 13 Jul 2021, at 11:13 pm, Brian Dickson
> wrote:
>
> For example, in evaluating the break-points when partitioning the labels to
> limit the total number of queries, the sequence COULD treat any contiguous
> sequence of underscore labels as if it were a single label, and then do its
>
> On 13 Jul 2021, at 6:22 am, Petr Špaček wrote:
>
> As Viktor pointed out in
> https://mailarchive.ietf.org/arch/msg/dnsop/w7JBD4czpGKr46v-DlycGbOv9zs/ , it
> seems that this problem plagues roughly tens out of 150k domains he surveyed.
> I think this makes further discussion about
[ Resending complete message, previous draft was incomplete... ]
> On 12 Jul 2021, at 11:18 am, Paul Hoffman wrote:
>
> The current text is sufficient to tell resolver developers, and resolver
> operators, why they should even think about underscore labels when they
> create a QNAME
> On 12 Jul 2021, at 11:18 am, Paul Hoffman wrote:
>
> The current text is sufficient to tell resolver developers, and resolver
> operators, why they should even think about underscore labels when they
> create a QNAME minimisation strategy. Elevating such a strategy to a SHOULD
> as a
> On 8 Jul 2021, at 10:28 am, Petr Špaček wrote:
>
> With my implementer hat on, I say "no", I don't see a compelling reason to
> "mandate" it. Keep it at MAY/optional level and leave it to implementers to
> decide what's best for their implementation and use-cases.
Just wanted to check what
On Wed, Jul 07, 2021 at 08:46:17PM +0200, Peter Thomassen wrote:
> Especially because of the last reason above, I tend towards MAY.
>
> However, I would endorse SHOULD / RECOMMENDED if the wording is
> changed such that "skipping a split" is done "up to the lowest-level"
> underscore label. In
On Wed, Jul 07, 2021 at 01:54:37PM -0400, Warren Kumari wrote:
> Viktor is suggesting that QNAME Minimization should be stopped when
> you run into an underscore ("_") label, instead of this being worded
> as a potential, optional mechanism.
>
> Obviously there is a tradeoff here -- privacy vs
On Fri, May 28, 2021 at 08:55:16PM -0700, Qin Wu via Datatracker wrote:
> Reviewer: Qin Wu
> Review result: Ready
>
> This draft defines DNS Query Name Minimisation mechanism, it is motivated by
> QNAME minimisation implementation lesson and experience and well documented. I
> believe it is
On Mon, Mar 15, 2021 at 05:38:40PM +, Jim Reid wrote:
> > However, operators of DNS servers SHOULD measure their path MTU to
> > well-known locations on the Internet, such as [a-m].root-servers.net
> > or [a-m].gtld-servers.net at setting up the servers.
>
> I think it would be better to
1 - 100 of 231 matches
Mail list logo
