gt; there is interest we can add the details.
As I mentioned during the IETF meeting, I am interested in the idea and
would like to contribute.
--
Stefan Ubbink
DNS & Systems Engineer
Present: Mon, Tue, Wed, Fri
SIDN | Meander 501 | 6825 MD | ARNHEM | The Netherlands
T +31 (0)26 352 55 00
htt
e valuable information for people considering it.
--
Stefan Ubbink
DNS & Systems Engineer
Present: Mon, Tue, Wed, Fri
SIDN | Meander 501 | 6825 MD | ARNHEM | The Netherlands
T +31 (0)26 352 55 00
https://www.sidn.nl
pgppiwBTopEWV.pgp
Description: OpenPGP digital signature
_
s is a private extension.
I would argue that you wouldn't need to know what the value means, if
it is a number and it always changes in a predictable way. Or when the
publisher of the value has documented somewhere what it means.
The current RFC 9660 uses SOA-SERIAL and it doesn't really
30:02 + (EPOCH 1730878202)"
$ dig +short txt se
"SE zone update: 2024-11-06 07:11:36 + (EPOCH 1730877096) (auto)"
This version could stay the same when the database is down, but we
continue to update the zone (SOA) to update signatures for example.
What do you think?
-
> On 12/27/24 12:09, Stefan Ubbink wrote:
> > In section 3.2 (Child-specific Method) it says:
> > "It is also possible to publish child-specific records, where the
> > wildcard label is replaced by the child's FQDN with the parent
> > zone's labels strippe
> So if you think this draft should be published as an RFC, please say
> so.
Overall I support the document, but some things might need some
clarification (at least to me).
--
Stefan Ubbink
DNS & Systems Engineer
Present: Mon, Tue, Wed, Fri
SIDN | Mea
must be
> specified by the application service" and "might be ignored by the
> operator", but the latter makes me nervous.
I wonder how the operator will handle the situation when there is
already a record of a certain type and the DUJ provides a different TTL.
[cu
ted GOST algorithms from active use within DNSSEC"
A small nit on section 2, the last word insecure is written with a capital I,
instead of a small letter as in the first paragraph.
I support the publication of this draft.
--
Stefan Ubbink
DNS & Systems Engineer
Present: Mon, Tue, We
On Mon, 13 Jan 2025 13:16:43 -0800
Warren Kumari wrote:
> On Wed, Jan 08, 2025 at 7:07 AM, Stefan Ubbink <
> Stefan.Ubbink=40sidn...@dmarc.ietf.org> wrote:
>
> > On Mon, 6 Jan 2025 21:02:52 -0500
> > Tim Wicinski wrote:
[cut comments on other drafts]
> > &
On Wed, 15 Jan 2025 13:41:47 -0800
Wes Hardaker wrote:
> Stefan Ubbink writes:
>
> > I do not see the change in
> > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-must-not-gost/blob/main/README.txt
> > . Am I missing something?
>
> Nope, you weren't. M
: Fri, 2 May 2025 01:06:56 -0700
From: internet-dra...@ietf.org
To: Stefan Ubbink
Subject: New Version Notification for
draft-ubbink-zoneversion-extended-00.txt
A new version of Internet-Draft
draft-ubbink-zoneversion-extended-00.txt has been successfully
submitted by Stefan Ubbink and posted to
show other possibilities than the SOA like
number.
If it is a free form TXT field that is just copied, I think it still
should be limited to minimize the possible misuse for reflection
attacks.
> > On May 2, 2025, at 5:26 AM, Stefan Ubbink
> > wrote:
> >
> > Hello,
>
nt for
> the authoritative nameserver implementations?
I would like to have a uniform way to know what the source of the DNS
data is in a way that it is visible to the public.
> > On 2. 5. 2025, at 14:26, Stefan Ubbink
> > wrote:
> >
> > Signed PGP part
> > Hello,
>
On Wed, 7 May 2025 19:35:42 +0200
Ondřej Surý wrote:
> Hi Stefan,
Hello Ondřej,
Sorry for the late reply. I was a bit busy with other things.
> > On 7. 5. 2025, at 10:45, Stefan Ubbink
> > wrote:
>
> [...]
>
> >> The draft is definitely underspecified i
14 matches
Mail list logo
