This addresses a gap in the DNSSEC specification. DS records need to identify
specific DNSSEC algorithms rather than a set of DNSSEC algorithms.
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for
> draft-andrews-private-ds-digest-types-00.txt
Dear dnsop,
We submitted a new version of the "dry-run DNSSEC" draft.
This work was reinitiated now that RFC9567 (DNS Error Reporting) is a
standard document and my plan to incorporate it into Unbound during the
IETF120 Hachathon.
This update mainly addresses the following feedback we got fro
All
I wanted to call your attention to the most recent update on this
document. The authors have worked through a number of open issues
primarily around editorial clarity and reorganization of the
recommendations. I want to personally thank the authors for working
through these issues, and my co
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
Dear all,
This latest version 07 of draft-ietf-dnsop-ns-revalidation has all
feedback from DNS Directorate early review, the mailing list, the room
and hallways, since it was presented at the last IETF119 in Brisbane,
processed. The authors believe the draft is ready for working group last
ca
(please note I'm sending this to DNSOP and V6OPS)
All
The authors have addressed the comments made during the IESG process and
feedback from DNS implementers, and have published version 18.
The links for the diff are mentioned below. I will point out the
additional introduction paragraph added
Hi dnsop wg.
We have submitted an update to our rfc3901bis draft "DNS IPv6 Transport
Operational Guidelines."
The changes can be seen below.
Diff from v3 to v5(current):
https://author-tools.ietf.org/iddiff?url1=draft-momoka-dnsop-3901bis-03&url2=draft-momoka-dnsop-3901bis-05&difftype=--html
The
Thank you for your reply. I have added some comments in-line.
On Thu, May 2, 2024 at 10:42 AM Ben Schwartz wrote:
> It seems like this draft says that the indicated MRDS overrides the EDNS
> BUFSIZE value. This seems likely to create problems if the MRDS value
> could be set by a lower layer in
Sent: Sunday, April 28, 2024 5:02 PM
To: DNSOP
Subject: [DNSOP] Fwd: New Version Notification for
draft-heard-dnsop-udp-opt-large-dns-responses-00.txt
Greetings, TSVWG currently has the document "Transport Options for UDP" (https:
//datatracker. ietf. org/doc/html/draft-ietf-tsvwg-udp-opti
Greetings,
TSVWG currently has the document "Transport Options for UDP" (
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options) in
Working Group Last Call. It includes a capability to fragment datagrams at
the UDP layer rather than the IP layer, and one of the use cases that has
been
> Il 11/01/2024 03:50 CET Lanlan Pan ha scritto:
>
>
> Thanks Paul.
>
> Paul Wouters 于2024年1月10日周三 23:01写道：
> > 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 thing is to put
> > the censored answer in the auth
Thanks Paul.
Paul Wouters 于2024年1月10日周三 23:01写道：
> On Wed, 10 Jan 2024, Lanlan Pan wrote:
>
> > I have submitted a new draft to discuss the faked answer returned from
> the recursive resolver.
> >
> > Your comments are appreciated.
>
> As I've said during the discussions on RBL and an updated v
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 returned from the
>>> recursive resolver
Thanks Bob, I will revised it.
Bob Harold 于2024年1月10日周三 22:23写道：
>
> On Wed, Jan 10, 2024 at 4:19 AM Lanlan Pan wrote:
>
>> Hi all,
>>
>> I have submitted a new draft to discuss the faked answer returned from
>> the recursive resolver.
>>
>> Your comments are appreciated.
>>
>>
>> -- F
i think you mean RPZ here.
Paul Wouters wrote on 2024-01-10 07:01:
On Wed, 10 Jan 2024, Lanlan Pan wrote:
I have submitted a new draft to discuss the faked answer returned from
the recursive resolver.
Your comments are appreciated.
As I've said during the discussions on RBL and an updated
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 Wed, Jan 10, 2024 at 4:19 AM Lanlan Pan wrote:
> Hi all,
>
> I have submitted a new draft to discuss the faked answer returned from the
> recursive resolver.
>
> Your comments are appreciated.
>
>
> -- Forwarded message -
> 发件人：
> Date: 2024年1月10日周三 16:11
> Subject: New Versio
Hi all,
I have submitted a new draft to discuss the faked answer returned from the
recursive resolver.
Your comments are appreciated.
-- Forwarded message -
发件人：
Date: 2024年1月10日周三 16:11
Subject: New Version Notification for
draft-pan-dnsop-explicit-forged-answer-signal-00.txt
FYI
Forwarded Message
Subject: New Version Notification for draft-lenders-dns-cbor-05.txt
Resent-From: martine.lend...@tu-dresden.de
Date: Mon, 23 Oct 2023 19:55:59 +
From: internet-dra...@ietf.org
To: Thomas C. Schmidt , Matthias Waehlisch
, Carsten Bormann ,
Martine Le
FYI
Forwarded Message
Subject: New Version Notification for draft-ietf-core-dns-over-coap-04.txt
Resent-From: martine.lend...@tu-dresden.de
Date: Mon, 23 Oct 2023 19:47:01 +
From: internet-dra...@ietf.org
To: Thomas C. Schmidt , Cenk Gündoğan
, Christian Amsüss ,
Matthias
://datatracker.ietf.org/doc/html/draft-ietf-httpbis-alias-proxy-status-05#section-2.1
From: DNSOP on behalf of libor.peltan
Sent: Friday, October 20, 2023 11:15 AM
To: Ben Schwartz ; libor.peltan
; Tom Carpay ; dnsop
Subject: Re: [DNSOP] Fwd: New Version
ity with existing
systems.
--Ben Schwartz
*From:* DNSOP on behalf of libor.peltan
*Sent:* Wednesday, May 31, 2023 4:33 AM
*To:* dnsop
*Subject:* [DNSOP] Fwd: New Version Notification for
draft-peltan-edns-presentation-f
On Oct 9, 2023, at 10:02, Ben Schwartz wrote:
>
>
> This is fun to think about, but it seems to me that these networks should
> avoid any reliance on the ICANN DNS tree. I doubt that any network of space
> probes on Io can accept the risk of a technical or governance issue on .io.
>
> Regar
I wonder if some kind of "limited licence local signing key" model
could be used, to get a signed permit from a "real" TA in the DNS to
specify the zone(s) that a limited licence key could use, with a far
longer than normal time over the rights signing. Because we don't want
inflated lifetimes/vali
behalf of Marc Blanchet
Sent: Sunday, October 8, 2023 3:17 PM
To: dnsop@ietf.org
Subject: [DNSOP] Fwd: New Version Notification for
draft-many-dnsop-dns-isolated-networks-00.txt
Hello, The primary use case of this draft is the deployment of naming
infrastructure on celestial bodies networks
Hello,
The primary use case of this draft is the deployment of naming infrastructure
on celestial bodies networks, but could be applied for other use cases.
Would love to get people reviews and comments.
Marc.
> Début du message transféré :
>
> De: internet-dra...@ietf.org
> Objet: New Versi
s closer to the current
"dig" output, for the sake of compatibility with existing systems.
--Ben Schwartz
From: DNSOP on behalf of libor.peltan
Sent: Wednesday, May 31, 2023 4:33 AM
To: dnsop
Subject: [DNSOP] Fwd: New Version Notification for
draft
Peter
On Mon, Jul 17, 2023 at 3:37 AM Peter van Dijk
wrote:
> On Wed, 2023-07-05 at 18:51 -0400, Tim Wicinski wrote:
>
> All
>
> The authors of draft-ietf-dnsop-avoid-fragmentation worked with different
> implementers to expand upon the index of Known Implementations, and what
> they implement s
On Wed, 2023-07-05 at 18:51 -0400, Tim Wicinski wrote:
> All
>
> The authors of draft-ietf-dnsop-avoid-fragmentation worked with
> different implementers to expand upon the index of Known
> Implementations, and what they implement specifically.
>
> The chairs would like to have a one week follow
All
The authors of draft-ietf-dnsop-avoid-fragmentation worked with different
implementers to expand upon the index of Known Implementations, and what
they implement specifically.
The chairs would like to have a one week follow up Working Group Last Call
comment period. We are looking for substan
Hi dsnop,
we'd like to turn your attention again to our draft
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html
We believe this document shall fill a missing gap in specifications, and
help interoperability of DNS tools. Therefore, we think it'd make sense
if this
Dear DNSOP,
This revision of "Consistency for CDS/CDNSKEY and CSYNC is Mandatory" has the
following changes:
- Advise to attempt retries to resolve inconsistencies
- Added that checking C* consistency also significantly limits impact from
nameserver hijacking
I've been pondering a related is
Forwarded Message
Subject: New Version Notification for
draft-bellis-dnsop-qdcount-is-one-00.txt
Date: Fri, 17 Feb 2023 08:12:18 -0800
From: internet-dra...@ietf.org
To: Joe Abley , Ray Bellis
A new version of I-D, draft-bellis-dnsop-qdcount-is-one-00.txt
has been successful
I'd like to learn about ISE first.
Thanks a lot for your advice.
Best regards,
Cathy
> > Dear dnsop,
> >
> > According to the comment, I modified the draft. There are two major changes.
> >
> > 1. Modify the description of SM3 DS records ( Section 2 )
> > In section 2, the length of digest is l
(chairs hat on)
Paul is correct.
Also, I feel we ("we" being the chairs + Overlord Warren + IESG folks)
should write some nice simple text to explain this
to authors in the future.
tim
On Thu, Jan 5, 2023 at 1:42 PM Paul Wouters wrote:
> On Thu, 5 Jan 2023, zhangcuiling wrote:
>
> > Dear dnso
On Thu, 5 Jan 2023, zhangcuiling wrote:
Dear dnsop,
According to the comment, I modified the draft. There are two major changes.
1. Modify the description of SM3 DS records ( Section 2 )
In section 2, the length of digest is listed as a difference between SHA-256
and SM3,
but in reality the l
Dear dnsop,
According to the comment, I modified the draft. There are two major changes.
1. Modify the description of SM3 DS records ( Section 2 )
In section 2, the length of digest is listed as a difference between SHA-256
and SM3,
but in reality the length of both algorithms is 32 bytes. [Corr
Hello,
I have submitted an informational draft that describes resolvers performing
IPv4 to IPv6 translation to send queries to IPv4-only authoritative servers.
We thought it would be beneficial to document that we can operate a
resolver with only an IPv6 address if we utilize the NAT64.
Despite th
Dear DNSOP,
This revision incorporates the feedback from IETF 114, specifically that the
CDS/CDNSKEY consistency check should be tolerant towards servers that don't
serve these records or that are unresponsive.
It occurred to me that the same (and in a way, worse) problem exists with
CSYNC. I
Hi Nils,
Thanks for the comment.
>Hi Cathy,
>
>are there any implementations of this available?
Unfortunately, as far as I know, there is no such implementation yet.
Of course it's a good idea to start real coding work.
We'd like to support the new algorithm in:
* DNS sevice,
* DNS server soft
Hi Cathy,
are there any implementations of this available?
In Sec. 2, it draft says
> The implementation of SM3 in DNSSEC follows the
> implementation of SHA-256 as specified in RFC 4509[RFC4509] except
> that the underlying algorithm is SM3, the digest value is 32 bytes
> long, and the di
Dear dnsop,
According to Paul's comment, I modified the draft. There are two major changes.
1. Replace a reference document with a free one.
In the former version, the draft referenced an ISO standard
[ISO/IEC14888-3:2018] that is not freely available, so I replace it with
another one.
And addi
Dear colleagues,
Here is the updated version of the
"Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records
for DNSSEC"
IETF draft.
We have a new coauthor, Boris Makarenko, who kindly agreed to continue the
development process.
-- Forwarded message -
From:
Da
Dear colleagues,
The updated version of RFC 5933-bis draft is uploaded.
The updated version partially resolves the issues raised by Michael StJohns
in his thorough review.
I hope there will be more interest in the updated version of the draft than
it was during the previous WGLC.
As I'm not sub
Dear DNSOP,
As discussed in
https://mailarchive.ietf.org/arch/msg/dnsop/nQQsixIT5cXFukBq4Ky67mCniAk/, I
wrote a short I-D to update RFC 7344 such that CDS/CDNSKEY consistency is
mandatory across authoritative nameservers. The result is below.
Looking forward to your feedback.
Cheers,
Peter
Hi Petr,
I would say one is a subset of the other, but not exactly the same topic.
draft-moura-dnsop-negative-cache-loop focuses relatively narrowly on one type
of resolution failure: delegations in a loop / cyclic dependency as documented
in their TusNAME work.
draft-dwmtwc-dnsop-caching-reso
Hello everyone,
it seems that we now have two drafts about 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 wro
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
On 11/5/21 1:07 AM, Paul Wouters wrote:
In general, the problem is that we need to make it easier for the DNS
hoster to enable DNSSEC when their customers are non-technical. I think
this draft does properly extend RFC 8078 and even think this document
could deprecate the "Accept after wait" metho
Dear DNSOP,
This draft introduces automatic bootstrapping of DNSSEC delegations. The
previous version has been presented at IETF 112, and the new version
incorporates the feedback gathered there (and on this list before the meeting).
Changes (taken from Appendix, with additional notes):
- Cla
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Sun, Sep 19, 2021 at 2:42 PM
Subject: New Version Notification for draft-dickson-dnsop-ds-hack-02.txt
To: Brian Dickson
A new version of I-D,
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Wed, Sep 22, 2021 at 12:50 AM
Subject: New Version Notification for draft-dickson-dnsop-glueless-02.txt
To: Brian Dickson
A new version of I-
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Sun, Oct 24, 2021 at 9:13 PM
Subject: New Version Notification for draft-dickson-dprive-dnst-00.txt
To: Brian Dickson
A new version of I-D, d
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Tue, Nov 9, 2021 at 6:11 PM
Subject: New Version Notification for draft-dickson-dprive-adot-auth-06.txt
To: Brian Dickson
A new version of I-
On Tue, 9 Nov 2021, Peter Thomassen wrote:
This draft introduces automatic bootstrapping of DNSSEC delegations. It
uses an in-band method for DNS operators to publish information about the
zones they host, per-zone and with authentication. With this protocol, DS
provisioning can happen secur
On 11/5/21 1:07 AM, Paul Wouters wrote:
On Tue, 26 Oct 2021, Peter Thomassen wrote:
This draft introduces automatic bootstrapping of DNSSEC delegations. It uses an
in-band method for DNS operators to publish information about the zones they
host, per-zone and with authentication. With this pr
It appears that Paul Wouters said:
>I've read the draft, and it is an interesting idea. Some thoughts I had:
>
>- Is it really needed to do hashing? Do we really expect domain names to
> hit the 63 or 255 limit ?
Probably not. There was also some thought that this makes it harder for
tourist
On Tue, 26 Oct 2021, Peter Thomassen wrote:
This draft introduces automatic bootstrapping of DNSSEC delegations. It uses
an in-band method for DNS operators to publish information about the zones
they host, per-zone and with authentication. With this protocol, DS
provisioning can happen secure
Dear DNSOP and DNSSEC bootstrapping aficionados,
This draft introduces automatic bootstrapping of DNSSEC delegations. It uses an
in-band method for DNS operators to publish information about the zones they
host, per-zone and with authentication. With this protocol, DS provisioning can
happen s
Hi, DNSOP folks,
I have been working on the "unsigned glue record" problem (and related
"unsigned NS record" problem).
This draft is mostly informational, and does not actually require any
protocol changes.
It might even be worth making a BCP, but I'll leave that up to the WG to
decide.
I think
Hi, DNSOP folks,
I have been working on the "unsigned NS record" problem (and related
"unsigned glue record" problem).
I think this is relatively widely applicable, even though it was originally
motivated by a problem that needed to be solved within DPRIVE.
(That problem is the subject of a draft
Feedback on SVCB draft 06 as requested.
On Mon, 28 Jun 2021 at 02:39, Tim Wicinski wrote:
>8
>
> The chairs would like the WG to review these changes, and give us some
> feedback.
6.1. "alpn" and "no-default-alpn"
The presentation "value" SHALL be a comma-separated list
(Appendix A.1)
Hi all,
As far as I'm concerned, the pain in maintaining a secure delegation is often
too high, and way too many DNS delegations are still insecure. I presume that
many of you agree, which (supposedly) is why mechanisms like RFC 8078 have been
created. And indeed, RFC 8078 is great for rollove
All
The SVCB Authors took some of your last minute requests and they did an
update which
gives more guidance and explanations around Alt-Svc, but also more
explanations around
the requirements.
The chairs would like the WG to review these changes, and give us some
feedback. Take
a look at the di
On Tue, Jun 15, 2021 at 12:03 PM Paul Wouters wrote:
> On Tue, 15 Jun 2021, Shumon Huque wrote:
>
> > On Tue, Jun 15, 2021 at 12:46 PM Tim Wicinski
> wrote:
> >
> > Yes, Stephane, we were envisioning recommending an
> underscore label. Of course, that leads to how to avoid collisions
On Tue, Jun 15, 2021 at 3:06 PM Paul Wouters wrote:
>
> Please try and recommend stronger naming guidelines so that a registry
> is not _needed_
>
Ok, I'm fine with punting on the registry idea for now ..
Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
On Tue, 15 Jun 2021, Shumon Huque wrote:
No, it's for anyone with a plausible application. It already includes
_validation-contactemail and _validation-contactphone from the CAB.
I would rephrase this as "for anyone who foolishly made a really bad
generic name in the past and is no
On Tue, 15 Jun 2021, Shumon Huque wrote:
On Tue, Jun 15, 2021 at 12:46 PM Tim Wicinski wrote:
Yes, Stephane, we were envisioning recommending an underscore
label. Of course, that leads to how to avoid collisions in that
space, and whether we need to establish a registr
On Tue, Jun 15, 2021 at 1:51 PM John Levine wrote:
> It appears that Shumon Huque said:
> >> You mean, a different registry than this one
> >>
> >>
> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
> >
> >Tim - yes, I think this wo
It appears that Shumon Huque said:
>> You mean, a different registry than this one
>>
>> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
>
>Tim - yes, I think this would be a bit different. The above is for IETF
>defined protocols.
On Tue, Jun 15, 2021 at 12:50 PM Shumon Huque wrote:
> On Tue, Jun 15, 2021 at 12:46 PM Tim Wicinski wrote:
>
>>
>> Yes, Stephane, we were envisioning recommending an underscore label. Of
>>> course, that leads to how to avoid collisions in that space, and whether we
>>> need to establish a regi
On Tue, Jun 15, 2021 at 12:46 PM Tim Wicinski wrote:
>
> Yes, Stephane, we were envisioning recommending an underscore label. Of
>> course, that leads to how to avoid collisions in that space, and whether we
>> need to establish a registry of application service names.
>>
>
> You mean, a differen
On Tue, Jun 15, 2021 at 12:38 PM Shumon Huque wrote:
> On Tue, Jun 15, 2021 at 12:28 PM Shivan Kaul Sahib <
> shivankaulsa...@gmail.com> wrote:
>
>> Hi Stephane!
>>
>>>
>>> Section 4.1: you do not mention a recommended name for the
>>> subdomain. Should we suggest a name starting with an undersco
On Tue, Jun 15, 2021 at 12:28 PM Shivan Kaul Sahib <
shivankaulsa...@gmail.com> wrote:
> Hi Stephane!
>
>>
>> Section 4.1: you do not mention a recommended name for the
>> subdomain. Should we suggest a name starting with an underscore, to
>> limit the risk of collisions and to emphasize it is not
Thanks Tony!
Best practice for providers ought to be to document re-validation
> requirements very prominently and clearly. (In my experience the common
> ones are not too bad but occasionally we have to guess, so maybe a service
> stops working for mysterious reasons 30 or 90 days later.)
>
Agre
Hi Stephane!
>
> Section 4.1: you do not mention a recommended name for the
> subdomain. Should we suggest a name starting with an underscore, to
> limit the risk of collisions and to emphasize it is not a host name?
> (On the other hand, some users may have a limited DNS provisioning
> interface,
On Thu, Jun 10, 2021 at 04:26:44PM -0700,
Shivan Kaul Sahib wrote
a message of 164 lines which said:
> Hi all, Shumon and I have been working on an early draft that
> surveys current DNS domain verification techniques. Depending on how
> it goes, we hope to eventually explore if we can come up
Shivan Kaul Sahib wrote:
> Hi all, Shumon and I have been working on an early draft that surveys
> current DNS domain verification techniques. Depending on how it goes, we
> hope to eventually explore if we can come up with some best practices.
This looks like a useful document!
One thing that'
Paul
We've been talking with Shivan and Shumon about the document, and I feel I
already asked them to be prepared to present at the next meeting on this.
I also suggested that they should also with the Application Area, for
feedback.
tim
On Thu, Jun 10, 2021 at 10:22 PM Paul Wouters wrote:
>
Thanks for doing this work!
I’ve read this a while ago when you gave me a preview and this is important
work that you should present at the next IETF and hopefully we can adopt and
put though
reasonably fast - the market needs our guidance.
(For those who think there is no problem, dig txt cnn.
Hi all, Shumon and I have been working on an early draft that surveys
current DNS domain verification techniques. Depending on how it goes, we
hope to eventually explore if we can come up with some best practices.
We plan to ask for time to present it at the IETF 111 DNSOP meeting. In
the meantime
Hi all,
This revision https://tools.ietf.org/html/draft-reddy-dnsop-error-page-07
addresses comments from the WG during the presentation at IETF-110.
As a reminder, it defines an Error page URI EDNS0 option to return an URI
Template which when accessed provides the reason the DNS query was
filter
On Fri, Feb 12, 2021 at 11:08 AM Joe Abley wrote:
> Hi all,
>
> I have discovered that without liberal access to bars and hallways at
> in-person IETF meetings, I no longer know how to tell the difference
> between ambition and insanity when it comes to technical proposals. I am
> quite prepared
On Fri, 12 Feb 2021, Joe Abley wrote:
I have discovered that without liberal access to bars and hallways at in-person
IETF meetings, I no longer know how to tell the difference
between ambition and insanity when it comes to technical proposals. I am quite
prepared to find out that in this case
I like this proposal, look forward to experimenting with this.
I'm not sure about how to defend against downgrade attacks, without
potentially having to touch some other DNSSEC-specific standards. I admit
to not having looked at them again, recently, with this in mind, so the
question I'm asking i
Hi all,
I have discovered that without liberal access to bars and hallways at in-person
IETF meetings, I no longer know how to tell the difference between ambition and
insanity when it comes to technical proposals. I am quite prepared to find out
that in this case the needle is at the crazy end
Hi Joey,
Thanks for the interest in the draft. We published a revised draft
https://tools.ietf.org/html/draft-reddy-dnsop-error-page-06 to address the
comments from the WG during the presentation at IETF-109.
Further comments and suggestions are welcome.
Cheers,
-Tiru
On Sat, 19 Dec 2020 at 02
Dear Tirumal, dnsop,
Following up on the last IETF session and observations regarding the
usability of this draft at the end of the meeting, this draft covers
2 important areas from my perspective: DNS error information made
available to the end-users as opposed to (
Hi all,
This revision https://tools.ietf.org/html/draft-reddy-dnsop-error-page-05
updates security considerations section to address comments from the WG
during the presentation at IETF-108.
As a reminder, it discusses a method to return an URL that explains the
reason the DNS query was filtered.
Hello Paul,
On Fri, 2020-09-25 at 17:13 -0400, Paul Wouters wrote:
> I could see a use of publishing a DNSKEY at the parent in a DS record
> that could be used for encrypted connections towards child nameservers.
Me too! :-)
> But we talked about this within the context of your other proposals,
On Thu, 24 Sep 2020, Ben Schwartz wrote:
I would certainly be concerned about such a scenario, but I don't understand
how it's relevant to Peter's proposal.
Couldn't this already be done today, by simply including such a hypothetical "parent
opinion" record in the glue?
For the scenario you'
On Fri, 25 Sep 2020, Peter van Dijk wrote:
in this new episode of 'enabling future innovations that we perhaps
cannot even imagine today', please find below a link to a draft
proposing a DS digest type that does no digesting at all. This allows a
zone owner to publish information in the parent z
Brian Dickson wrote:
>
> This doesn't even address the significant challenges of developing a
> method of passing the information from the domain owner (registrant) to
> the parent name server (registry). The current mechanism of EPP, does
> not even accommodate the DNS operator unless the DNS ope
On Fri, Sep 25, 2020 at 5:36 AM Peter van Dijk
wrote:
> Hello dnsop,
>
> in this new episode of 'enabling future innovations that we perhaps
> cannot even imagine today', please find below a link to a draft
> proposing a DS digest type that does no digesting at all. This allows a
> zone owner to
On Thu, Sep 24, 2020 at 10:58 AM Peter van Dijk
wrote:
> Hello dnsop,
>
> early 2019, Manu of Facebook proposed the DSPKI record - a parent-side-
> of-the-delegation record to hold a pin for authenticating child-side
> DoT servers. This would be undeployable.
>
> A few months ago, Tim April propo
Hello dnsop,
in this new episode of 'enabling future innovations that we perhaps
cannot even imagine today', please find below a link to a draft
proposing a DS digest type that does no digesting at all. This allows a
zone owner to publish information in the parent zone and have the
parent sign tha
[added hrpc to CC: list]
On Thu, 24 Sep 2020, Peter van Dijk wrote:
When talking to Petr Spacek about this, he came up with the following:
-if-, long enough ago, besides DS, a range of RRtype numbers would have
been reserved with the same processing rules, i.e. these types live in
the -parent
Hello dnsop,
early 2019, Manu of Facebook proposed the DSPKI record - a parent-side-
of-the-delegation record to hold a pin for authenticating child-side
DoT servers. This would be undeployable.
A few months ago, Tim April proposed NS2/NS2T, which looks like it
would clearly benefit from the abil
Hi all,
This revision https://tools.ietf.org/html/draft-reddy-dnsop-error-page-03
addresses
several comments from the WG during the presentation at IETF-108.
Major updates are listed below:
1. Error page URI EDNS0 option to return an URI Template which when
accessed provides the reason the DNS q
Hi ADD and DPRIVE,
I've noticed three recent drafts that propose to use the SVCB format:
draft-mglt-add-rdp, draft-tapril-ns2, and
draft-pauly-add-resolver-discovery. These drafts, across multiple
working groups, consider distinct use cases and architectures, but they all
propose using SVCB (in v
1 - 100 of 672 matches
Mail list logo
