On Thu, 16 Jan 2025, Philip Homburg wrote:
b) Is step 3b (a short RFC that points to a specific version of an
expired draft) acceptable? If not, what would be needed, given that
the original author didn't want to progress their document?
When it comes to using a cryptographic algorithm in DNSS
On Jan 13, 2025, at 16:38, Warren Kumari wrote:On Tue, Jan 07, 2025 at 1:44 PM, Paul Wouters <p...@nohats.ca> wrote:On Tue, 7 Jan 2025, Paul Hoffman wrote: draft-ietf-dnsop-must-not-sha1 This document is fine as-is, with one minor nit: Appendix C should be marked for removal by the RFC
On Tue, 7 Jan 2025, Paul Hoffman wrote:
draft-ietf-dnsop-must-not-sha1
This document is fine as-is, with one minor nit: Appendix C should be marked
for removal by the RFC Editor, similar to Appendix B.
I think the Title and Abstract are broken. It currently states:
Remove SHA-1 from
On Sun, 17 Nov 2024, Philip Homburg wrote:
[indeed a bit offtopic]
Use OPENSSL_CONF environment to point to conf file containing:
.include = /etc/ssl/openssl.cnf
[evp_properties]
rh-allow-sha1-signatures = yes
That is all needed to get SHA1 verification in DNSSEC back, without
accepting SHA1
On Mon, 4 Nov 2024, Roy Arends wrote:
While I thought this was an original idea when I heard it during the DELEG discussions,
it has been proposed by both Peter van dijk (see below) and Paul Wouters independently
(I've seen a draft for it, named "ds uplifting", though not in
On Thu, 31 Oct 2024, Ben Schwartz wrote:
This is why I wanted to raise this topic. I don't believe we have thought very
carefully about when DCV is actually safe
or appropriate, and I don't think we should be recommending a mechanism without
consensus and guidance for what this
mechanism achi
On Thu, 31 Oct 2024, Tim Wicinski wrote:
draft-ietf-dnsop-domain-verification-techniques-06.txt
I'll review it today and I now understand your reasoning a lot better.
I reviewd the text.
It makes assumptions on knowing what are valid and invalid use cases of
domain ownership verificatio
On Oct 25, 2024, at 09:25, Ben Schwartz
wrote:
>
>
> Yes. I would like to see deeper consideration of what we are trying to prove
> to whom, to help the reader decide how best to do it.
Please provide text as it is unclear to the authors what you feel is missing
for the reader.
Paul__
Ondřej Surý wrote:
I am quite confused as SHA-512 is not standardized for use in DS records:
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml
I believe this change should be rejected until (and if) SHA-512 is standardized
to use in DS records.
Indeed it should be rejected, bu
ed value.
>
> If you think this analysis is wrong, please explain the attack
> which is prevented by client-side DNSSEC validation, remembering
> that it can only be done reliably when the client already is
> using a TRR.
>
> -Ekr
>
>
> [0] DNSSEC validation at the recursive
On Mon, 7 Oct 2024, Benno Overeinder wrote:
* draft-ietf-dnsop-delegation-only
- In 2021, there was a poll on the DNSOP WG mailing list to drop the draft.
Rough consensus to drop the document was established on 24 August 2021.
- We marked the draft as Dead in the datatracker.
Still sad abou
On Mon, Oct 7, 2024 at 9:26 AM Eric Rescorla wrote:
>
>
> On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters wrote:
>
>>
>> On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote:
>>
>>> This is explicitly prohibited rfc9460 as it would provide linkability.
>
On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote:
> This is explicitly prohibited rfc9460 as it would provide linkability.
>>> See rfc9460 section 12: "Clients MUST ensure that their DNS cache is
>>> partitioned for each local network, or flushed on network changes, to
>>> prevent a local adve
[kind of off-topic here, and also speaking as just an individual]
On Fri, Oct 4, 2024 at 3:28 PM Erik Nygren wrote:
>
> On Fri, Oct 4, 2024 at 3:20 PM Stephen Farrell
> wrote:
>
>>
>> On 10/4/24 19:30, Paul Wouters wrote:
>> > Which makes me wonder if it m
>
> On Oct 4, 2024, at 15:28, Russ Housley wrote:
>
> This document is related to draft-ietf-dnsop-rfc8624-bis. We ask the DSNOP
> WG to adopt it.
The document seems like a theoretical ideal of an algorithm life cycle. There
have been many kind of considerations in play that have determine
t; --
> *From:* Eric Rescorla
> *Sent:* Friday, October 4, 2024 8:07 AM
> *To:* Salz, Rich
> *Cc:* Arnaud Taddei ; Ben Schwartz <
> bem...@meta.com>; Paul Vixie ; Paul Wouters <
> paul.wout...@aiven.io>; draft-ietf-tls-svcb-ech.auth...@i
[drifting off topic]
> On Oct 2, 2024, at 00:10, Paul Vixie
> wrote:
>
>
>
>
> i would not. much of the world now relies upon inauthentic dns responses for
> defense against bad actors.
that's a limitation of RPZ. Years ago I proposed to move the Answer to the
Authority section so you c
trusted DNS servers.
As for the RFC1034 reference, Warren suggested to maybe use: "DNS (see
RFC1034, BCP219)" (where BCP219 is the latest DNS Terminology doc).
Paul
--
> *From:* Salz, Rich
> *Sent:* Monday, September 30, 2024 1:29 PM
> *To:* Ben S
Hi,
I have done my AD review of draft-ietf-tls-svcb-ech. Some history was well
summarized by the Document
Shepherd:
Please note that the text in this I-D was initially developed in the DNSOP WG,
went through IETF LC, and IESG review. The result of the IESG review was to take
the text in this I-D
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-rfc8109bis-06: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https
On Jul 31, 2024, at 09:29, Petr Špaček wrote:
>
> On 30. 07. 24 9:41, libor.peltan wrote:
>> 2) I would still vote for allowing one keytag collision per zone (not per
>> whole chain-of-trust, like Bind does) instead of none. This would be more
>> comfortable for many older/simpler signers and
On Mon, 29 Jul 2024, Jim Reid via Datatracker wrote:
Proposed changes below are part of:
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/146
draft-ietf-dnsop-domain-verification-techniques-05
Reviewer: Jim Reid
Review result: Not Ready
I am disappoi
> On Jul 26, 2024, at 16:08, Mark Andrews wrote:
>
>
> Even if we where to go with one failure is allowed we still need to
> write down the new rules and there will be complaints that we are
> retrospectively changing the rules. This is grand fathering in the
> old rules for the old algorithm
On Jul 26, 2024, at 21:48, RFC Errata System wrote:
>
> The following errata report has been submitted for RFC7901,
> "CHAIN Query Requests in DNS".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid8053
>
>
On Jul 25, 2024, at 17:54, Shumon Huque wrote:
>
>
> The actual proposal is initially only "new" DNSKEY algorithms will have the
> no colliding key tags requirement.
Better than a flag day. But still seems to introduce new communication
requirements on the multi signer deployments which woul
On Jul 25, 2024, at 17:50, Yorgos Thessalonikefs wrote:
>
> But I do want to see a flag day for validators (either failing on the first
> or second collision) for all algorithms.
No flag days. DNS on devices shouldn’t just start failing for no good reason
other than running software from befor
On Jul 23, 2024, at 12:09, Paul Vixie wrote:
>
>
> Making TLS 1.2 available as a fallback is vital. Many secure private edge
> networks will never allow TLS 1.3 because of ECH.
You can do TLS 1.3 without ECH ?
Making a weaker version of TLS mandatory would be unwise, unless it’s to give
mor
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-zoneversion-10: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https
On Fri, 5 Jul 2024, Petr Špaček wrote:
My interpretation is that it means "if you don't know any better use
1400", but RECOMMENDED is more concise.
I read RECOMMENDED as “don’t think you are smarter than the collective
IETF”. Or maybe that’s just how I hope people will read it.
I think y
On Jul 5, 2024, at 08:14, Petr Špaček wrote:
>
> I understand why Paul Vixie does not like 1400 set in stone.
>
> Having said that I think it's in fact _not_ set in stone because the text
> says RECOMMENDED.
>
> My interpretation is that it means "if you don't know any better use 1400",
> bu
On Tue, 25 Jun 2024, Warren Kumari wrote:
This errata is correct.
Doh! Yes, it is…
Paul, would you mind being the one to mark it as Verified? I'm an author, and
while I don't really
see a much conflict of interest for an AD to mark an errata as verified, it's
probably cleaner if
some
This errata is correct.
Paul
Sent using a virtual keyboard on a phone
> On Jun 21, 2024, at 17:47, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC7344,
> "Automating DNSSEC Delegation Trust Maintenance".
>
> --
> You
On Wed, 19 Jun 2024, Tim Wicinski wrote:
On Wed, Jun 19, 2024 at 2:49 PM Paul Vixie
wrote:
This document makes the argument that because of how things work at the
moment, we should limit our aspirations.
I completely disagree.
I agree with Paul. We deserve nice things - we
On Tue, Jun 18, 2024 at 2:01 PM Wessels, Duane wrote:
>
>
> > 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 40verisign@dmarc.ietf.org> wrote:
> >
> >>> What should an authoritative nam
On Tue, Jun 18, 2024 at 1:40 PM Wessels, Duane
wrote:
> Hi Paul, thanks for the review. Comments inline…
>
>
>
> > On Jun 17, 2024, at 4:23 PM, Paul Wouters via Datatracker <
>
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-zoneversion-08: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dnssec-bootstrapping-10: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
On Sun, 19 May 2024, Steve Crocker wrote:
[speaking as individual only]
In my view, an algorithm moves through seven phases during its lifecycle.
1. Experimental – defined and included in the IANA registry
2. Adopted – begin inclusion in validation suite
3. Available – ok to use for signing
4
On Mon, 6 May 2024, Petr Špaček wrote:
R1. UDP responders SHOULD NOT use IPv6 fragmentation [RFC8200].
Operational impact of this recommendation is unclear.
Why? Because clients belong to several sets:
- One set clients cannot receive fragmented answers,
Good because it has been proven to
On Fri, 17 May 2024, Peter Thomassen wrote:
Proposed text:
# Abstract
OLD
This document deprecates the DS enrollment methods described in
Section 3 of RFC 8078 in favor of Section 4 of this document, and
also updates RFC 7344.
NEW
This document establishes the DS enrollment method
On Wed, 15 May 2024, Peter Thomassen wrote:
[ I know this message predates the telechat, but I had no time to process
this before the telechat ]
[ cut everywhere where we agreed ]
I have a few items to discuss and some comments. I'm leaving out the
discussion
of _signal as a name, as this
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dnssec-bootstrapping-08: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
On May 10, 2024, at 05:36, jab...@strandkip.nl wrote:
>
> I'm interested in where this guidance comes from.
>
> RFC 2782 to me is the grandfather of underscore labels, and it pretty much
> goes out of its way to encourage a hierarchy of underscore labels to anchor
> SRV records under, e.g. unde
On Tue, 30 Apr 2024, Paul Hoffman wrote:
Until someone can show that a reduction in collision resistance can lead to a reduction in real-world
security for DNSSEC, we can wait for "MUST NOT validate", possibly forever. There is no good reason
for this group to say to a zone operator who signed
On Tue, 30 Apr 2024, Paul Hoffman wrote:
Is that something within the realm of ICANN? Perhaps the DNS Tech Day ?
You ask those questions sounding as if ICANN staff had not already done so.
Why not share the data if you have some? This is the list of TLDs affected:
apple. brand TLD
beats.
On Apr 30, 2024, at 18:42, Paul Hoffman wrote:
>
> This cull-because-of-low usage thread incorrectly assumes that the DNS is
> flat instead of a hierarchy. The last I saw, there are 14 TLDs who use
> RSASHA1. Advancing this draft as-is means that all of the zones under those
> TLDs would be c
On Tue, 30 Apr 2024, Philip Homburg wrote:
- FIPS
- PCI-DSS
- BSI
- OWASP
- SOC2
- PKI-industry & CAB/Forum
- TLS, IPsec/IKE, OpenPGP, SMIME, et all at IETF.
- All the cryptographers including CFRG
The problem is that none if them did an impact analysis for this draft.
I phrase it the other
On Wed, 1 May 2024, Mark Andrews wrote:
One got servfail because validators where not aware that support was ripped
away underneath it. Validators started to get errors that where totally
unexpected. Performing runtime testing of algorithm support addressed that by
allowing the validator to s
On Tue, 30 Apr 2024, Philip Homburg wrote:
So what happens instead is that software is patched to return insecure if
SHA1 is not avaiable for signing and that is of course very risky.
has been patched, yes. The problem arguably is that DNS moved WAY slower
that the industry as a whole to get r
On Tue, 30 Apr 2024, Mark Andrews wrote:
They DO NOT disable SHA1. They disable RSASHA1. The distinction is
important. NSEC3 works fine on them.
There were issues with NSEC3's use of SHA1 as well. I am failing to find
the reports on this now unfortunately.
Paul
___
On Tue, 30 Apr 2024, Philip Homburg wrote:
The advise is split between producing SHA1 signatures and consuming SHA1
signatures, and those timings do not have to be identical.
That said, a number of OSes have already forced the issue by failing
SHA1 as cryptographic operation (RHEL, CentOS, Fedo
On Mon, 29 Apr 2024, Paul Hoffman wrote:
If the purpose of deprecating validation that involves SHA-1 is the decision by
RedHat to make that entire section of the DNS insecure, the documents should
say that explicitly. Conflating the pre-image weaknesses of SHA-1 and actual
useful attacks on
On Mon, 29 Apr 2024, Philip Homburg wrote:
As far as I know there is no second pre-image attack on SHA1, and there
will not be one in the foreseeable future.
Correct.
So if we deprecate SHA1 for validators, and assuming validators will follow
this advice, and some platforms already stopped v
On Apr 27, 2024, at 20:39, Tim Wicinski wrote:
>
> M
>
>
> This starts a Call for Adoption for:
> draft-hardaker-dnsop-rfc8624-bis
> draft-hardaker-dnsop-must-not-sha1
> draft-hardaker-dnsop-must-not-ecc-gost
I support adoption for all three drafts. Willing to help with text and w
On Sat, 20 Apr 2024, Peter Thomassen wrote:
The authors certainly don't insist, but we'd need to pick a suitable
replacement for the "_signal" label.
John proposed "_dnssec-signal" elsewhere in this thread.
The authors would like to note that adding "_dnssec-" eats up 8 more bytes,
increasin
ust a ping on this; thank you.
>
> Best regards,
>
> David Dong
> IANA Services Sr. Specialist
>
>> On Sat Apr 13 01:24:13 2024, pe...@desec.io wrote:
>> Hi Paul,
>>
>>> On 4/12/24 22:36, Paul Wouters wrote:
>>> However, I would urge the au
On Fri, 12 Apr 2024, David Dong via RT wrote:
Dear Frederico A C Neves and Paul Wouters (cc: dnsop WG),
As the designated experts for the Underscored and Globally Scoped DNS Node
Names registry, can you review the proposed registration in
draft-ietf-dnsop-dnssec-bootstrapping-08 for us
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dns-error-reporting-08: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dns-error-reporting-08: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
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 current lookup while
> searchin
On Feb 29, 2024, at 20:33, Arnold DECHAMPS wrote:
>
>
> Is it still a concern enough that they justify continuing using those tags
> instead of the full key?
The full key is not there. There is only a key tag. Are you proposing a wire
format change to DNSSEC that puts the full key there? That
> On Feb 29, 2024, at 07:52, Edward Lewis wrote:
> (If no action is taken, malicious activity might follow now that it is
> described, but I have not heard of a historical case of it.)
This attack was more or less described five year ago:
https://essay.utwente.nl/78777/
They didn’t get to
On Feb 27, 2024, at 17:48, Mark Andrews wrote:
>
> If you forbid in the protocol
But part of this is not “in” the protocol. Eg if two dns hosters happen to
arrive at the same key tag for a single zone in concurrent offline ways. Or if
that happens when KSK and ZSK are managed differently.
You
seem to be a consensus for that at
the moment.
I'm sure other folks will chime in with their views. But I want to ping Paul
Wouters specifically - since you are one of
the expert reviewers for this registry and an author of domain-verification,
could you express your opinion on the
specific
On Feb 16, 2024, at 12:17, Petr Špaček wrote:
>
>
> It does not handle collisions in any special way. It simply does not validate
> and the resolver has no way to tell if the crypto thingy is wrong or if it
> just tried a wrong key. Any such failure is counted towards fail-budget (1
> allowe
On Thu, 15 Feb 2024, Ralf Weber wrote:
There is a difference between what a lot of people on this thread did to keep
the Internet alive
Resolvers would have disabled dnssec to remain alive. Also not at all
something nice to happen, but the Internet in fact would not have died.
I am super happ
On Thu, 15 Feb 2024, Ralf Weber wrote:
So to put some real numbers out there. I recently for testing did download all
the zone data I could get from ICANN CZDS and tried to get DNSKEYs for every
domain. So that data set had 256479639 domains (256 million) and out of those
18726163 (18 million
On Feb 15, 2024, at 04:37, Petr Špaček wrote:
>
> If you think colliding keys should be allowed, please propose your own limits
> for sensible behavior.
I do think they need to be allowed because they have always been allowed so
far. Reasons for not allowing them seems to be implementation det
On Wed, 14 Feb 2024, Roy Arends wrote:
It is recommended that the client (the resolver) sets the DNS COOKIE. The
benefit of using cookies is for the client. It is to make sure that the
response is genuine.
Does it? Not for an on-path attacker that sees the COOKIE in the clear.
So what attack
On Tue, 13 Feb 2024, Roy Arends wrote:
Based on this, I assume the error report query is of qtype TXT, but this is not
specified anywhere in the document. Someone could use a qtype of CNAME or ANY
or just A or . Can this be stated explicitly ?
It is explicitly specified in section 3:
Yes
On Wed, 14 Feb 2024, Roy Arends wrote:
1. There is a recommendation to use DNS COOKIEs [RFC7873] over UDP (PS), but no
statement about how to mitigate the effects when these are not used. What ought
someone to do when this is not done?
It is recommended that the client (the resolver) sets the
I don't think I saw any response to this from the authors or dnsop, so let
me reply to your DISCUSS points (as individual DNS enthousaist only):
On Tue, Jan 2, 2024 at 2:44 PM Martin Duke via Datatracker
wrote:
> Martin Duke has entered the following ballot position for
> draft-ietf-dnsop-avoid-
I tried to nudge this document on by filing a PR:
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-avoid-fragmentation/pull/40
While I can confirm it addresses my concerns raised, all proposed changes should
be vetted by the authors, dnsop and the related IESG / Directorate members
before
be
On Thu, 1 Feb 2024, Paul Hoffman wrote:
Maybe we should add to the second paragraph:
Note, however, the root server addresses are not glue records, so setting the
TC bit in truncated responses from
the root servers is not required by RFC 9471.
Does this solve your and Warren's issues?
Works
On Wed, 31 Jan 2024, Paul Hoffman wrote:
On Jan 31, 2024, at 15:15, Paul Wouters wrote:
Can they write a draft with why they are going against the RFC?
Yes, that is possible. However, I think it would be unfair to the DNS community
to hold up draft-ietf-dnsop-rfc8109bis waiting for that to
On Wed, 31 Jan 2024, Paul Hoffman wrote:
Nope. The tone is because some root server operators want the ability to
continue to not set the TC bit due to root server operational independence. We
have to be honest about what is happening, and what the rules are.
The rules are defined in the RFC
On Jan 31, 2024, at 09:56, Ralf Weber wrote:
>
> Moin!
>
> While this is true, there are a lot of players from different part
> of the ecosystem that want to work on DELEG (see contributors)
I am not saying don’t do it. I am saying we need to understand the cost and
benefits. For example, do
On Wed, 31 Jan 2024, Philip Homburg wrote:
Something I wonder about, certainly after the interim, is how do we discuess
with the wider DNS community the trade-offs that are available in de design
of DELEG such that we get good feedback about priorities.
For example, the current design used two
On Tue, 30 Jan 2024, Roy Arends wrote:
One motivation behind DELEG is the ability to use “Aliasmode” to point to an
SVCB record elsewhere, which contains a DS record. This way, DS records in
various top level domains can be federated under a single operator. This works
solely if both the DELE
On Tue, 30 Jan 2024, Roy Arends wrote:
DNSSEC is not mandatory, it is recommended.
One motivation behind DELEG is the ability to use “Aliasmode” to point to an
SVCB record elsewhere, which contains a DS record. This way, DS records in
various top level domains can be federated under a single
On Jan 30, 2024, at 01:14, Ralf Weber wrote:
>
>
> I agree that future extensions will require code changes, but having a
> record type that is extensible from the start might make it easier to
> deploy new parameters then it is to do a full RRTYPE, at least that is
> the hope.
I took a step ba
> On Jan 27, 2024, at 16:42, Paul Marks wrote:
>
> pick .lan
> instead? It seems that a lot of people are already using this abbreviation
> on their internal networks, which happen to be local in
> area.
LAN implies local area network. So an organization with multiple locations
would have
On Jan 17, 2024, at 05:15, Bellebaum, Thomas
wrote:
>
> 1. Caching of unrequested RRs would actually be fine, if they are
> properly signed. At worst, a resolver would cache irrelevant records.
This is not entirely true. By tailoring someone’s cache you might be able to
track them. There is
On Mon, 15 Jan 2024, Warren Kumari wrote:
dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server
expect: status: NOERROR
expect: the SOA record to be present in the answer section
expect: an OPT record to be present in the additional section
expect: DO=1 to be present if an RRSIG is in t
On Mon, 15 Jan 2024, Warren Kumari wrote:
Subject: [DNSOP] Dealing with some open Errata:
[ + Dave Crocker (author), Paul Wouters, Frederico Neves (registry experts)]
Hi there all,
As part of the Great Errata Cleanup of 2024, I'm going through reported Errata
and trying to close them.
On Jan 10, 2024, at 20:55, Paul Vixie wrote:
>
> i think you mean RPZ here.
Yes I did. Thank you.
Paul
>
> 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 re
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 version for
RBL, if these things are done "for the user", the best th
On Mon, 8 Jan 2024, Tim Wicinski wrote:
Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis
From my previous comments (still unaddressed, were my comments rejected?)
there are 13 root servers.
I would really like to see this changed. We keep trying to tell peop
On Jan 7, 2024, at 05:02, Paul Vixie wrote:
>
>
> i think as long as we keep adding features that are only necessary because
> dnssec lacks certain features or is not universally deployed or both, then
> dnssec will lack certain features or not be universally deployed or both.
> please be car
On Fri, 29 Dec 2023, Paul Wouters wrote:
I've missed these calls, my apologies.
I think the document is almost ready to proceed, but contains some
markers of [[unresolved discussion]] that obviously needs resolving
(and should have been resolved before doing a WGLC? :)
Obviously I m
On Thu, 28 Dec 2023, Paul Hoffman wrote:
On Dec 28, 2023, at 13:34, Tim Wicinski wrote:
All,
We wrapped up the second working group last call for
draft-ietf-dnsop-rfc8109bis with no comments pro or con.
The chairs can only assume the working group is not interested in moving this
work for
On Mon, 18 Dec 2023, Geoff Huston wrote:
I am in support of adoption by the Working Group. The process of peer review
has proved to be highly valuable over the years and the result is generally a
more robust framework for critical elements of the DNS infrastructure.
I agree, but also underst
On Wed, 13 Dec 2023, Joe Abley wrote:
On 13 Dec 2023, at 16:37, Paul Wouters wrote:
It should probably change TCP to “source IP validated transports (dns over
stuff, tcp and udp cookies)
Since it is possible to imagine networks in which source address spoofing is
not possible, and hence
It should probably change TCP to “source IP validated transports (dns over
stuff, tcp and udp cookies)
Sent using a virtual keyboard on a phone
> On Dec 13, 2023, at 10:14, Zaheduzzaman Sarker via Datatracker
> wrote:
>
> Zaheduzzaman Sarker has entered the following ballot position for
> dr
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dns-error-reporting-07: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
On Wed, 29 Nov 2023, Warren Kumari wrote:
So, the IANA has a question:
IANA Question --> What about the registrations that currently reference RFC5933?
Should the registrations currently referencing RFC5933 be marked "OBSOLETE,"
"DEPRECATED," changed in
some other way, or left alone?
If IAN
On Nov 17, 2023, at 12:04, Ray Bellis wrote:
>
>
>
>> On 17/11/2023 10:41, Paul Wouters wrote:
>>
>> I think it would be unwise to make assumptions on how people will use
>> this feature. They might want to ask for many more records along with
>>
On Fri, 17 Nov 2023, Ray Bellis wrote:
Last time this came around I also suggested instead of n times QT
entries, to use the same method as NSEC does for conveying which RRtypes
are covered using a single bitmap:
https://datatracker.ietf.org/doc/html/rfc3845#section-2.1.2
Speaking persona
On Tue, 14 Nov 2023, internet-dra...@ietf.org wrote:
Internet-Draft draft-bellis-dnsext-multi-qtypes-08.txt is now available.
Last time this came around I also suggested instead of n times QT
entries, to use the same method as NSEC does for conveying which RRtypes
are covered using a single bi
On Sat, 11 Nov 2023, John R Levine wrote:
work(ed) fine without minimization and I don't think it is reasonable
to expect every mail system in the world to change their configuration
to work around our performance bug.
It is totally reasonable for protocols and software and configurations
1 - 100 of 951 matches
Mail list logo
