Internet-Draft draft-ietf-dnsop-structured-dns-error-08.txt is now available.
It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF.
Title: Structured Error Data for Filtered DNS
Authors: Dan Wing
Tirumaleswar Reddy
Neil Cook
i do not foresee a time when any dns protocol agent won't need NS
support any more, nor also UDP/53 support. so DELEG can at best add
features for its adopters at the expense of permanent added complexity
for the specification and for the system.
i realize that in today's client/server model
thanks rob for your long service. we'll do as you suggest.
Rob Wilton (rwilton) wrote on 2024-01-29 02:48:
Hi Authors,
Just a note/reminder that I am stepping down as an AD in March. I don’t
think that I’ve seen any reply to my DISCUSS comments (perhaps the
authors and/or WG are still
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?
On Jan 31, 2024, at 17:39, Paul Wouters wrote:
>
> 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
>>
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 1 Feb 2024, at 06:38, Warren Kumari wrote:
>
> Hi there, authors (and WG),
>
> Thank you for this document — I have some questions / comments before I can
> progress it.
>
> Firstly, the (presumably) easy one:
> The document says:
> "This document, when published, obsoletes RFC 8109."
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 happen, and it would
be a bad policy 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
Philip Homburg writes:
> DNSSEC has a lot of moving parts that needed to be in place compared
> to DoH.
Yes, certainly there are many differences between the two, some of
which speak to the challenges of DELEG when looked at through the lens
of DNSSEC. The core point was that motivation as a
On Jan 31, 2024, at 11:38, Warren Kumari wrote:
>
> Hi there, authors (and WG),
>
> Thank you for this document — I have some questions / comments before I can
> progress it.
>
> Firstly, the (presumably) easy one:
> The document says:
> "This document, when published, obsoletes RFC 8109." -
>When DNSSEC came out, I admit I was kind of surprised to see how long
>it took to be used. I thought it would be adopted faster. There was
>insufficient motivation when the system worked well enough and the
>problem being addressed was, to many people, largely theoretical.
>
>When DoH was
Hi there, authors (and WG),
Thank you for this document — I have some questions / comments before I can
progress it.
Firstly, the (presumably) easy one:
The document says:
"This document, when published, obsoletes RFC 8109." - can you add
something along the lines of "Section 1.1 contains a list
Paul Wouters writes:
> I tried to show some of of these in my "Costs of deleg" slide.
> A new RRtype has a fairly big cost meassures in years, both in
> terms of DNS software, DNS deployment and worse, in Registrar
> deployment for Registrant webui elements.
Unfortunately, I know of no good way
On 1/31/24, 13:04, "DNSOP on behalf of Dave Lawrence" wrote:
>
>Edward Lewis writes:
>> The impact on the registration system wasn’t raised at the table.
>
>Not entirely true. We did recognize that there'd need to be an EPP
>draft too.
Ah, yes. Joe suggested not making changes
On Jan 31, 2024, at 10:03, Dave Lawrence wrote:
>
> Edward Lewis writes:
>> The impact on the registration system wasn’t raised at the table.
>
> Not entirely true. We did recognize that there'd need to be an EPP
> draft too.
And a very early one is available:
Edward Lewis writes:
> The impact on the registration system wasn’t raised at the table.
Not entirely true. We did recognize that there'd need to be an EPP
draft too.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 1/31/24 15:33, Paul Wouters wrote:
A new RRtype has a fairly big cost meassures in years, both in
terms of DNS software, DNS deployment and worse, in Registrar
deployment for Registrant webui elements.
Re-using DS is not nice, but neither was Pseudo OPT, EDNS0, etc.
But it gains us a
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
Moin!
On 31 Jan 2024, at 15:33, Paul Wouters wrote:
> I tried to show some of of these in my "Costs of deleg" slide.
> A new RRtype has a fairly big cost meassures in years, both in
> terms of DNS software, DNS deployment and worse, in Registrar
> deployment for Registrant webui elements.
While
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
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 contraints:
1) no creative (ab)use of DS
>Let me just point out a key distinction: the typical use case
>of DELEG should be kind-of child centric. Most people will only
use a simple alias-mode DELEG at the parent, pointing somewhere
>into their DNS hoster's namespace. That's practically important,
>because all the
Two things buried in Joe’s message I want to build on:
From: DNSOP on behalf of Joe Abley
Date: Wednesday, January 31, 2024 at 03:17
>
>However, that will require new metadata to be bundled with domain registration
>in transactions between registrant and registrar and between registrar and
On 31/01/2024 09.16, Joe Abley wrote:
It seems important to be prepared for a long transition phase [...]
Yes, that's been well known since the very beginning of the discussions
at IETF 118. Support in resolvers will also take years to deploy
widely, even for relatively simple changes.
On 31 Jan 2024, at 09:04, Vladimír Čunát
wrote:
> On 30/01/2024 07.55, Kazunori Fujiwara wrote:
>> It proposes new name resolution using only information on the parent side.
> Let me just point out a key distinction: the typical use case of DELEG should
> be kind-of child centric. Most people
On 30/01/2024 07.55, Kazunori Fujiwara wrote:
It proposes new name resolution using only information on the parent side.
Let me just point out a key distinction: the typical use case of DELEG
should be kind-of child centric. Most people will only use a simple
alias-mode DELEG at the parent,
27 matches
Mail list logo
