On Mon, Jan 29, 2024 at 3:45 PM Wes Hardaker wrote:
> IESG Secretary writes:
>
> > The Domain Name System Operations (dnsop) WG will hold a virtual
> > interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam
> > (17:00 to 18:00 UTC).
>
> I'm sadly very day-job conflicted with this slo
Wes
On Mon, Jan 29, 2024 at 6:45 PM Wes Hardaker wrote:
> IESG Secretary writes:
>
> > The Domain Name System Operations (dnsop) WG will hold a virtual
> > interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam
> > (17:00 to 18:00 UTC).
>
> I'm sadly very day-job conflicted with t
The following errata report has been verified for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of
Attribute Leaves".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7068
-
Hi all,
I have read draft-dnsop-deleg-00 and have some comments. It seems premature to
offer actual text as well as commentary but I can definitely do that if the
authors would like. I am fully enthusiastic about updating delegations and
referral responses, and anything negative below should no
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
To your last point, I've proposed some examples of how "alpn" and "tlsa" ought
to work here: https://github.com/fl1ger/deleg/pull/16/files
--Ben Schwartz
From: DNSOP on behalf of Kazunori Fujiwara
Sent: Tuesday, January 30, 2024 1:55 AM
To: dnsop@ietf.org
Subj
Hi Joe,
> On 30 Jan 2024, at 12:57, Joe Abley wrote:
>
> Hi all,
>
> I have read draft-dnsop-deleg-00 and have some comments. It seems premature
> to offer actual text as well as commentary but I can definitely do that if
> the authors would like. I am fully enthusiastic about updating delega
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 1/30/24, 01:14, "DNSOP on behalf of Ralf Weber" wrote:
>... but having a
>record type that is extensible from the start ...
Designing in extensibility is a very good idea, ah, essential idea, but isn't a
no-brainer.
Start by asking and documenting: What information is needed at a DNS
de
It appears that Ralf Weber said:
>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.
If the RRTYPE is extensible, how do t
On 1/30/24, 09:57, "DNSOP on behalf of Roy Arends" wrote:
>> On 30 Jan 2024, at 12:57, Joe Abley wrote:
>
>> Related, what to do when the ipv4hints are not the same as the
> corresponding A RRSet?
>
>IMHO, potential unsigned glue records from elsewhere are inferior to
> address reco
> On 30 Jan 2024, at 15:05, Paul Wouters wrote:
>
> 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 re
On 1/30/24 16:05, Paul Wouters 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 30 Jan 2024, at 15:11, John Levine wrote:
>
> It appears that Ralf Weber said:
>> 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 le
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
Negotiation is handled via the SVCB "mandatory" mechanism:
https://datatracker.ietf.org/doc/html/rfc9460#name-servicemode-rr-compatibilit
Basically, extensions are ignorable by default unless they are marked
mandatory. If a record has a mandatory parameter that you don't understand,
you skip t
On 30 Jan 2024, at 15:57, Roy Arends wrote:
>> Unless we are certain that there is no benefit from DELEG without DNSSEC,
>> perhaps DNSSEC should not be mandatory.
>
> DNSSEC is not mandatory, it is recommended.
I was responding to the FOR DISCUSSION in section 1.5, which I imagined
referred
(my vibes only)
On Tue, Jan 30, 2024 at 11:21 AM Joe Abley wrote:
>
>
> I think specifying rules about which to prefer is important. But I also
> think it's worth thinking more pessimistically around what kinds of
> failures will result when people get that wrong. We have already seen this
> wit
On 30/01/2024 16:21, Joe Abley wrote:
On 30 Jan 2024, at 15:57, Roy Arends wrote:
If an authority server is capable of loading a DELEG RRSet and generating
referral responses accordingly, it's surely also possible of synthesising an
unsigned NS set?
I’m all in favour of synthesising NS/Gl
On 30 Jan 2024, at 17:25, Tim Wicinski wrote:
> I do feel that SVCB is/was the right way to solve having more robust DNS
> records, but it also is/was the thing that may end up destroying DNS.
Destroying DNS sounds like a worthy goal to be honest :-)
But yes, I like the SVCB approach too. It
John
On Tue, Jan 30, 2024 at 11:29 AM John Dickinson wrote:
> On 30/01/2024 16:21, Joe Abley wrote:
> > On 30 Jan 2024, at 15:57, Roy Arends wrote:
>
> >>> If an authority server is capable of loading a DELEG RRSet and
> generating referral responses accordingly, it's surely also possible of
Dear WG,
this is a reminder that the virtual meeting is about to start in 3 minutes!
The agenda URL will guide you to document with links for Meetecho etc.
Petr Špaček
On 24. 01. 24 21:54, Benno Overeinder wrote:
Dear WG,
We have published an updated agenda for the interim, see
https://da
Again thanks to mr Hoffman for minutes, here they are and uploaded in
the datatracker and our git repo
Thank you one and all for having great productive conversations!
tim
DNSOP WG
Interim meeting 2024-01-30 1700 UTC
Chairs: Benno Overeinder, Suzanne Woolf, Tim Wicinski
Minutes taken by Paul Hoff
I hear talk about "downgrade attacks" frequently, across different ideas.
Hearing it again in the context of DELEG, I had this thought.
We often wind up mired in discussions about downgrades, what they mean, the
consequences. I'd suggest, as definers of protocols, we think in terms of
ensurin
In this line of reasoning, let's remember the "herd immunity" effect. If
receivers mostly respond to expectation violations by transparent fallback, an
attacker on the wire has more incentive to attempt the downgrade attack. If
receivers mostly "fail closed", this incentive is reduced. This i
The following errata report has been verified for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of
Attribute Leaves".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7068
-
26 matches
Mail list logo
