be
NXDOMAIN. I think this argument could go either way.
Unless conflicting opinions come in, I will fix PowerDNS to do the right thing
for ANY, and will report the A query issue to the NSD developers.
Kind regards,
--
Peter van Dijk
Netherlabs Computer Consulting BV - http://www.netherlabs.nl
Hello Paul,
On Oct 26, 2012, at 15:17 , Paul Wouters wrote:
On Fri, 26 Oct 2012, Peter van Dijk wrote:
nxd IN CNAME nxdomain.example.com.
PowerDNS currently does not generate this NSEC3 but this will be fixed
shortly.
You would return an NSEC3 record
bled, we believe
that the
NXDOMAIN was generated from the top label. In other words, we rely on
the
‘shape’ of the root zone in that every positive entry in it is only
one label
long.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://
, I understand) here:
https://github.com/cmouse/pdns-v6-autorev
The last paragraph of 2.5 also makes no sense to me. Database
synchronisation from a single master is a solved problem.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
On 29 Apr 2016, at 1:43, Alain
sion draft for dnssd push, that’s fine.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
missed a mailing list, please forward this
message.
If you need to reach me, please use +31-6-10908570.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
Hello Ray,
On 10 Feb 2017, at 14:12, Ray Bellis wrote:
On 10/02/2017 12:52, Peter van Dijk wrote:
Can you please consider adding a port number field?
I see where you're coming from, but I'm not inclined to add it (yet)
for
a couple of reasons:
1. CGNAT is evil ;-)
You have my full
ful!
However, both in ECS, and now in XPF, we do not get client’s port
number. With increasing CGNAT deployment, this makes it impossible to
distinguish clients once a request has passed through a proxy, like
dnsdist or a TLS frontend.
Can you please consider adding a port number field?
Kind r
Hello,
On 23 Sep 2016, at 10:22, Stephane Bortzmeyer wrote:
On Tue, Sep 20, 2016 at 06:13:50PM +0200,
Stephane Bortzmeyer <bortzme...@nic.fr> wrote
a message of 68 lines which said:
This issue was spotted by Peter van Dijk. It is about
draft-ietf-dnsop-nxdomain-cut-05, recently ap
Hello Paul,
On 26 Sep 2016, at 16:32, Paul Hoffman wrote:
On 26 Sep 2016, at 0:33, Peter van Dijk wrote:
2308 does not “redefine” QNAME. It clarifies that the usage in
1034 4.3.2 is the definition we use in RFCs. 1035 4.1(.2) does not
conflict with this; the QNAME there is just the initial
, please return SERVFAIL there,
not NXDOMAIN :)
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
://indico.dns-oarc.net/event/24/session/8/contribution/13/material/slides/2.pdf
(slide 7).
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, which in a world of growing CGN deployment, may soon prove
quite important.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
. We're way past that
now.
Tim, thanks, this is the voice of reality. Our hope is that we can
reduce this pain by one point by standardising ALIAS/ANAME.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
at 7:13 PM, Evan Hunt
<e...@isc.org<mailto:e...@isc.org>> wrote:
>
> (Incidentally, I'm working on a somewhat more ambitious ANAME draft
with
> Peter van Dijk and Anthony Eden, who has kindly agreed to merge his
efforts
> with ours. I expect to post it in a few days, sta
rewriting NODATA responses, injecting ads
into existing domains. So you really have to have addresses at the
zone apex these days.
They solved the issue for ‘CNAME at apex’, which is not the only use
case for ANAME.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com
to
all existing resolvers out there, but we can’t. Until then, the auths
will have to assist, as many of them are doing today already.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https
on Amazon with ELB which means Route53 is mandatory
for him.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
d also allow that. If you have suggestions for a section on ANAME
target resolving and DNSSEC, please let us know.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 10 Apr 2017, at 1:04, Richard Gibson wrote:
On Sun, Apr 9, 2017 at 3:56 PM, Peter van Dijk
<peter.van.d...@powerdns.com>
wrote:
This section calls for limiting the TTL of cached address records to
the
lesser of the ANAME TTL and the TTL of the retrieved address
records, but
sec
as an error condition.” but I
am aware that more words are needed.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
internal networks the
> server is part of. This was so far concern for resolvers, but with
> ANAME it may become a concern for authoritative servers as well.
Oh good catch, thanks!
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
_
van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
to relax this requirements, and will consider that.
That said, nothing prevents your own implementation from choosing the
target based on any kind of local policy. So if you want to pick US or
CN based on client IP, you can do that.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https
On 5 Apr 2017, at 8:57, Peter van Dijk wrote:
Hello Stephane,
On 28 Mar 2017, at 16:33, Stephane Bortzmeyer wrote:
On Mon, Mar 13, 2017 at 08:59:32AM -0700,
internet-dra...@ietf.org <internet-dra...@ietf.org> wrote
a message of 45 lines which said:
Title
; 3. Does it not matter if it is either?
2308 does say
“
Some name servers fail to set the RCODE to NXDOMAIN in the presence
of CNAMEs in the answer section. If a definitive NXDOMAIN / NODATA
answer is required in this case the resolver must query again using
the QNAME as the query label.
“
but not al
Hello Tony,
On 31 Mar 2017, at 12:10, Tony Finch wrote:
Evan Hunt <e...@isc.org> wrote:
(Incidentally, I'm working on a somewhat more ambitious ANAME draft
with
Peter van Dijk and Anthony Eden, who has kindly agreed to merge his
efforts
with ours. I expect to post it in a few days
On 28 Mar 2017, at 21:56, Barry Raveendran Greene wrote:
On Mar 28, 2017, at 12:31 PM, Peter van Dijk
<peter.van.d...@powerdns.com> wrote:
Please note that neither draft handles the use case of also passing
the port number, which in a world of growing CGN deployment, may soon
prove
On 31 Mar 2017, at 16:09, Peter van Dijk wrote:
On 28 Mar 2017, at 23:27, Dave Lawrence wrote:
Peter van Dijk writes:
Please note that neither draft handles the use case of also passing
the
port number, which in a world of growing CGN deployment, may soon
prove
quite important.
I agree
to it, including details
that may, if resolver operators cooperate, reduce the need for
online/live signing in the future.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org
On 28 Mar 2017, at 23:27, Dave Lawrence wrote:
> Peter van Dijk writes:
>> Please note that neither draft handles the use case of also passing the
>> port number, which in a world of growing CGN deployment, may soon prove
>> quite important.
>
> I agree that neither ha
Hi Job,
On 7 Apr 2017, at 20:24, Job Snijders wrote:
> Dear Evan & Authors,
>
> Can you add a RFC 7942 section to this document?
Absolutely, we’ll do that in -01.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
. I suspect this removal is
specifically hurting OPENPGPKEY deployment today.
So, if you want to know about implementation status, please click
through from https://tools.ietf.org/html/rfc to the relevant draft.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com
Hello Suzanne,
On 18 Jul 2017, at 14:13, Suzanne Woolf wrote:
If this is acceptable to the WG, we’ll keep the new draft with these
changes as a WG draft.
Yes please!
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com
the
point of BULK (even though we are capable of online signing and thus
have it easier than some of the other name servers), but we could
certainly be convinced otherwise.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com
one. For NSEC3 I suspect this is not feasible.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
u for your extensive review!
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
email, being extra long, is currently a singular item
on that list because it deserves some time to digest. We take every
comment seriously, even if we don’t necessarily respond. I hope we can
post a new version within a few weeks.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https
/270.
Why not use /etc/hosts instead, so you only expose yourself?
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Hello,
On 21 Sep 2017, at 18:01, Evan Hunt wrote:
On Thu, Sep 21, 2017 at 02:20:15PM +0200, Peter van Dijk wrote:
thank you for this, I like it a lot. One nit below.
Me too, with another nit...
This creates a kind of confusion, however, because the answer
to a
query
r ever a good idea to say MUST NOT rather than SHOULD NOT. I
can for example imagine ways that might make some kinds of debugging
easier.
I would settle for SHOULD NOT. Can you elaborate on the debugging?
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerd
in any case.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 25 Aug 2017, at 0:27, Mark Andrews wrote:
> RFC 2308 is consistent with RFC 1034.
>
> Go read *all* of RFC 1034. QNAME is used to refer to *both* the original
> *and* updated value after following a CNAME.
+1
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.
cepted, all is consistent again
between 1034, 1035, 2308. Then, RFCs like 5155 which rely on the 2308
definition remain correct in their usage of QNAME.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNS
.
See you there!
Cheers,
Peter van Dijk, Shane Kerr, Pieter Lexis
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
aft will die the death it deserves. In other words,
a draft needs to put its money where its mouth is. This way, drafts that
actually help operations (this is dnsOP, after all) will get the
attention they need, while other drafts may wither away - and that’s a
good thing.
Kind regards,
--
Peter van D
it is
getting away with no ‘round robin’ at all in many deployments.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
d regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
. This week, we hope you will look at the
definition in the draft for "QNAME".
Please review the lengthy explanation and comment on the list if you
think the definition should change.
+1 on the lengthy explanation. Nothing shorter could settle this thing.
Kind regards,
--
Pete
I have not figured
out the exact wording yet (but I will).
What does dnsop think?
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
st TTL per name, instead of per RRset. This, if true, would argue against 0.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
are grateful that ISC is now doing that
:-)
So far: I was told that PowerDNS has implemented a plug-in/script that
provides support for catalog zones.
https://github.com/powerdns/powercatz
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com
this opportunity to start demanding Implementation Status
sections for those drafts where that requirement makes sense? Because it
certainly makes sense here!
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing
will not be implementing this protocol.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
). As authors
we feel this is a good time to ask for adoption of the document.
We’d like to ask the WG to consider adoption. Ray and myself will be
present at IETF101 if you want to discuss.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
Forwarded message:
From
for submission is Saturday, 1 December 2018. If you have a FOSDEM
pentabarf account from a previous year, please use that account. Reach out to
dns-devroom-mana...@fosdem.org if you run into any trouble.
See you there!
Cheers,
Peter van Dijk, Shane Kerr, Pieter Lexis, and Kees Monshouwer
signature.asc
useful debugging aids, and in big numbers, indications of attacks or
operational problems. With the draft, ICMP becomes another useless source of
background noise.
Meanwhile, we have no indication that the draft solves any existing real world
problem in a useful way.
Please do no
regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Hi Warren,
On 4 Mar 2019, at 16:23, Warren Kumari wrote:
On Thu, Feb 28, 2019 at 10:13 AM Peter van Dijk
wrote:
As this pertains to a section that will apparently be removed for
publication, only posting it here on dnsop@ for historical reasons:
So, RFC7942 (the one about
affects DNS operations.
+1
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
t IP address matches a specified set of address list,
> - this version of off-the-shelf BIND 9 happens to have a new
> configuration option to skip RRL if an incoming request contains an
> edns-tag option with bit X on
> ?
Yes.
Kind regard
erns.
So while not requiring an RFC to obtain an assignment, the I-D is
published for feedback on the design aspects of the option and to act
as the reference specification for it.
Well said!
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.po
, for the same
reasons.
Are they currently returning no error/no data?
Yes, many do. Others do not respond at all (i.e., timeout).
Case in point: https://github.com/dns-violations/dnsflagday/issues/73
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com
the status of the document, will be
*actively harmful to the DNS at large*. Please do not implement this.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
not expected to
notice -every- failed DNSSEC validation? And what does 'report' mean? Report it
where?
I'm looking forward to a more focused revision of the draft. I suspect that
this document could be a lot shorter without losing its usefulness.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV -
onal/Auth counts, and the sizes of
those individual records.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
sufficiently agreed on.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
The related dprive
document hints at answers for this but does not provide enough rope either.)
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
it, and this email, have brought the
idea across. Editorial comments are welcome via GitHub (link is in the
draft), or via the WG of course.
Looking forward to your thoughts on this.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
Forwarded Message
From
that data on the owner's behalf.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
Forwarded Message
From: internet-dra...@ietf.org
To: Peter van Dijk
Subject: [EXT] New Version Notification for draft-vandijk-dnsop-ds-
digest-verbatim-00.txt
Date: Fri
nd is still
> improving. So I am less concerned about anything taking 5 years again.
Now if only we could apply that optimism to operator-registry communications :)
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP
y the moment they responded to it, but I don't think scavenging that query
from incoming ICMP packets is the solution.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
erral Responses Is Not Optional
> Author : M. Andrews
Mark,
thank you for writing this down in a document.
If you're doing an implementation status section, you can note that
PowerDNS Auth is compliant since 4.2.0, or about a year ago.
Kind regards,
--
Peter van Dijk
Power
oceedings/108/agenda/agenda-108-anrw-05
11:05-11:30 Enabling Privacy-Aware Zone Exchanges Among
Authoritative and Recursive DNS Servers
(Nikos Kostopoulos)
11:30-11:45 Inferring the Deployment of Inbound Source
Address Validation Using DNS Resolvers
NSEC/NSEC3 record is already set to the minimum value.
>
>
> Ralph can of course still be acknowledged for the helpful pointer.
Yes, that makes sense, it is relevant background. I took your text plus
something extra and put it at
https://github.com/PowerDNS/draft-dnsop-nsec-ttl/pull/5
Thanks!
d then I can shorten the Introduction section to
only explain the core of the problem.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
rather not see immortalised in an RFC, please
let me know!)
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV -
https://www.powerdns.com/
Forwarded Message
From: internet-dra...@ietf.org
To: Peter van Dijk
Subject: [EXT] New Version Notification for draft-vandijk-dnsop-nsec-
ttl
Hello DNSOP,
On Mon, 2020-11-23 at 21:16 +0100, Peter van Dijk wrote:
> please find below my draft that updates one
> sentence in 4034 and the ~same sentence in 5155. As far as I can see,
> no correction to 8198 is necessary or useful.
I believe this draft is non-controversial. I am
s needs to be a new type, vs. reusing RRSIG
under the specific semantics you described, but a new type feels
cleaner to me.)
> Thoughts?
+1 !
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
t is what the quoted text means to convey, sorry if that was
unclear!
> , and I think also require EPP changes.
I don't see how EPP comes into it at all. The signer signs all NSsets;
the auth serves the signatures with the delegations; done.
Kind regards,
--
Peter
' from the draft is gone (we usually do
not publish it in the final RFC - and if we did, it would quickly be
outdated).
If we do this for other documents too, we can easily check how
implementation is going - and if implementation is happening at all!
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV
rom the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
>
> Title : NSEC(3) TTLs and NSEC Aggressive Use
> Author : Peter van Dijk
> Filename: draft-ietf-dnsop-nsec-ttl
ded wildcards to the lowest TTL in the
proof. Now I wonder if that needs to be written down explicitly, and
whether that should also go into this document (which we would then
retitle 'NSEC(3) TTL clarifications'?).
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Wed, 2021-01-13 at 10:21 +0100, Peter van Dijk wrote:
> On Fri, 2021-01-08 at 11:33 +0100, Vladimír Čunát wrote:
> > Well, if the client requests the proof (+dnssec), you have to include
> > those NSEC*s and I'd consider it incorrect to prolong their TTL. I'd be
> >
Name System Operations WG of the IETF.
>
> Title : NSEC(3) TTLs and NSEC Aggressive Use
> Author : Peter van Dijk
> Filename: draft-ietf-dnsop-nsec-ttl-00.txt
> Pages : 7
> Date: 2021-01-13
>
>
Hello,
I noticed that 5155 had another occurence of the wrong text. This
revision -02 updates that text too.
With this, I again believe the document is ready for WGLC. Chairs?
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV -
https://www.powerdns.com/
On Fri, 2021-01-29 at 02:51 -0800
ppetite - when the WG queue is small enough!
There are quite some things I like in rfc2317-bis, especially the parts where
it proposes something -other than- slashes in labels. I am not offering to take
it on at this time, though.
Kind regards,
--
Peter van Dijk
PowerD
On Mon, 2021-05-10 at 22:09 +0100, Tony Finch wrote:
> Peter van Dijk wrote:
> > Also in section 3.2, I do not think responding with the option should
> > be limited to NOERROR. Specifically, I'd very much also want it to work
> > for NXDOMAIN,
>
> Isn't the
happy to contribute the necessary words.
>
> If you have the words to fix this issue that would need to changes the
> code but clears everything up, do it :).
I would like to clarify that Pieter meant 'need no changes to the code'.
:-)
Kind regards,
--
Peter van Dijk
Y or ADDITIONAL' question, but I really like the short
EDNS option that does not change the processing of any RRsets from a
query response.)
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
use NSEC3 at
all (i.e. when to pick NSEC instead) and I would be happy to contribute
that too, if nobody beats me to it.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf
of those out on subsequent records. The wire
format does not: https://datatracker.ietf.org/doc/html/rfc1035#section-4.1.3
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mail
> the attacker needs to seed the cache more often?
The delay is never indefinite. The mitigation provided here is that the limit
to that delay is lowered, and indeed also, that the attacker might need to seed
more often to implement the attack at all.
Thanks!
K
re.)
Of course. Updated in my copy.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ul in
validators until signers/authoritatives become compliant with this draft. It is
a secondary measure (that the WG explicitly requested so as to attempt to solve
the problem in multiple places) that should become irrelevant as signers (most
of which already have software fixes pending,
On Wed, 2021-05-19 at 12:28 +0200, Peter van Dijk wrote:
> Hello Benjamin,
>
> On Tue, 2021-05-18 at 20:36 -0700, Benjamin Kaduk via Datatracker
> wrote:
> > I don't think I understand what a "deviating value" would be (and in
> > which direction it would devi
he Domain Name System Operations WG of the IETF.
>
> Title : NSEC and NSEC3 TTLs and NSEC Aggressive Use
> Author : Peter van Dijk
> Filename: draft-ietf-dnsop-nsec-ttl-05.txt
> Pages : 10
> Date
drafts that have been crushed under the sheer weight of
scope creep.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
advice. It is good to let
implementers know that somebody thought of this trick, and it might
make sense for many implementations, but we should not be overly
prescriptive.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
1 - 100 of 145 matches
Mail list logo
