In your letter dated Sat, 2 Mar 2024 16:55:59 -0400 you wrote:
>The core DNSSEC protocol includes multi-signer. RFC 8901 just spells out expli
>citly how it is covered by the protocol; that's why its status is Informationa
>l.
>
>> The first step to conclude is that for the core DNSSEC protocol, re
To rephrase, it sounds like you are proposing a rule that zones should be
configured to use at most one glueless delegation step.
Under this rule, one cannot place an "unrelated nameserver name" anywhere
beneath a zone cut that itself uses an unrelated nameserver. Effectively, all
zones below
It appears that Philip Homburg said:
>What I mean is that if we take all of the standards track DNSSEC RFCs and we
>add a new RFC that says something to the effect:
>1) A signer MUST NOT sign a DS or DNSKEY RRset if the set has duplicate key
> tags.
>2) An authoritative DNS server MUST not serv
Ben Schwartz wrote on 2024-03-04 07:20:
To rephrase, it sounds like you are proposing a rule that zones should
be configured to use at most one glueless delegation step.
i think it's the inverse. according to fujiwara-san's comments each zone
must have at least one in-zone name server name:
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
>Not at all. This would be an incompatible change that breaks existing
>working DNS configurations, for at most a trivial simplification in
>load limiting code many years from now, even assuming people were to
>implement it.
Opinions difference how much this change will help.
The point I wanted t
On 3/4/24 15:14, Paul Wouters wrote:
It means every registrant, who doesn’t know about DNS, has to create host
objects for glue and whenever the ISP changes nameserver names (eg gets bought,
sold or merges), or IP address, the ISP has to talk to the registrant to fix
things at their registry
I understood Fujiwara’s proposal to be slightly different:
If you are a DNS provider (hosting other zones) then the provider should use
in-domain name servers.
DW
> On Mar 4, 2024, at 3:14 PM, Paul Wouters wrote:
>
> On Mar 4, 2024, at 14:04, Paul Vixie
> wrote:
>>
>>
>>
>> this means a
It appears that Philip Homburg said:
>>Not at all. This would be an incompatible change that breaks existing
>>working DNS configurations, for at most a trivial simplification in
>>load limiting code many years from now, even assuming people were to
>>implement it.
>
>Opinions difference how much
Internet-Draft draft-ietf-dnsop-dns-error-reporting-08.txt is now available.
It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF.
Title: DNS Error Reporting
Authors: Roy Arends
Matt Larson
Name:draft-ietf-dnsop-dns-error-reporting-08.txt
Page
Internet-Draft draft-ietf-dnsop-generalized-notify-01.txt is now available. It
is a work item of the Domain Name System Operations (DNSOP) WG of the IETF.
Title: Generalized DNS Notifications
Authors: Johan Stenstam
Peter Thomassen
John Levine
Name:draft-ietf
Hi,
This revision has the following changes from -00:
- Describe endpoint discovery
- Rename NOTIFY rrtype to DSYNC (to distinguish from NOTIFY message)
- Reserve scheme values 128-255
- Expanded discussion on amplification risks and garbage notifications
- Clean-up, editorial changes
Looking f
Hi,
We're leaving this open a few more days to allow for any other comments. We'd
like to submit it for publication before IETF 119.
Thanks,
Suzanne
For the chairs
On Feb 15, 2024, at 10:57 AM, Suzanne Woolf wrote:
Hi,
The qdcount draft is brief and straightforward, and there have been no n
Internet-Draft draft-ietf-dnsop-rfc7958bis-01.txt is now available. It is a
work item of the Domain Name System Operations (DNSOP) WG of the IETF.
Title: DNSSEC Trust Anchor Publication for the Root Zone
Authors: Joe Abley
Jakob Schlyter
Guillaume Bailey
> On 4 Mar 2024, at 19:14, Paul Wouters wrote:
>
> It means every registrant, who doesn’t know about DNS, has to create host
> objects for glue and whenever the ISP changes nameserver names (eg gets
> bought, sold or merges), or IP address
Er, no. It’ll be the registant’s registrar who will
Internet-Draft draft-ietf-dnsop-qdcount-is-one-02.txt is now available. It is
a work item of the Domain Name System Operations (DNSOP) WG of the IETF.
Title: In the DNS, QDCOUNT is (usually) One
Authors: Ray Bellis
Joe Abley
Name:draft-ietf-dnsop-qdcount-is-one-02.txt
Internet-Draft draft-ietf-dnsop-ns-revalidation-05.txt is now available. It is
a work item of the Domain Name System Operations (DNSOP) WG of the IETF.
Title: Delegation Revalidation by DNS Resolvers
Authors: Shumon Huque
Paul Vixie
Willem Toorop
Name:draft-i
Internet-Draft draft-ietf-dnsop-compact-denial-of-existence-03.txt is now
available. It is a work item of the Domain Name System Operations (DNSOP) WG
of the IETF.
Title: Compact Denial of Existence in DNSSEC
Authors: Shumon Huque
Christian Elmerot
Olafur Gudmundsso
Martin Duke has entered the following ballot position for
draft-ietf-dnsop-avoid-fragmentation-17: No Objection
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 r
Forwarded Message
Subject: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt
Date: Mon, 04 Mar 2024 13:12:26 -0800
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Internet-Draft draft-toorop-dnsop-ranking-dns-data-00.txt is now available.
Title: Ranking Dom
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
All,
We are pleased to announce that the draft agenda for the IETF 119 DNSOP
sessions has been published. The sessions are scheduled as follows:
- Monday, March 18, 2024, from 15:30 to 17:00 AEST (05:30-07:00 UTC)
- Friday, March 22, 2024, from 15:00 to 16:30 AEST (05:00-06:30 UTC)
You can v
Paul Wouters wrote on 2024-03-04 11:14:
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 curre
On Mon, Mar 4, 2024 at 3:29 AM Philip Homburg
wrote:
>
> What I mean is that if we take all of the standards track DNSSEC RFCs and
> we
> add a new RFC that says something to the effect:
> 1) A signer MUST NOT sign a DS or DNSKEY RRset if the set has duplicate key
>tags.
> 2) An authoritative
On Sun, Mar 3, 2024 at 11:34 PM Kazunori Fujiwara
wrote:
> dnsop WG,
>
> "unrelated" (or, previosly called as out-of-bailiwick) name server names
> are
> necessary for DNS hosting providers.
>
Fujiwara-san, I have to nitpick your very first statement above.
Many DNS providers do offer the abili
26 matches
Mail list logo
