With thanks to an astute reader, 3 corrections that do not change the
meat of the problem statement:
On Sat, 2025-07-26 at 00:45 +0200, Peter van Dijk wrote:
> On Tue, 2025-06-17 at 17:44 +0200, Joe Abley wrote:
> > Hi all,
> >
> > Warren, Wes and I put our respective hea
especially if that signal covers 3 protocols instead of just DoT.
Kind regards,
--
Peter van Dijk
PowerDNS.com B.V. - https://www.powerdns.com/
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
ell. We do
need to then remember that there's an EDNS option that can cause big
responses.
Kind regards,
--
Peter van Dijk
PowerDNS.com B.V. - https://www.powerdns.com/
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
Document: draft-ietf-dnsop-must-not-sha1
Title: Deprecating the use of SHA-1 in DNSSEC signature algorithms
Reviewer: Peter van Dijk
Review result: Almost Ready
Hello SHA1-fighting friends,
this is a DNSDIR review for draft-ietf-dnsop-must-not-sha1.
This document appears to be mostly ready, but
On Wed, 2025-03-05 at 15:36 +0100, Peter Thomassen wrote:
> > > It seems desirable to minimize the number of steps that the
> > > notification sender needs to figure out where to send the NOTIFY.
> >
> > This sentence needs work. "needs to /perform to/ figure out" perhaps?
>
> Done ("needs to per
Reviewer: Peter van Dijk
Review result: Ready with Nits
I am the assigned DNSDIR reviewer for this document.
Generally this document appears to be in very good shape. I have several nits.
Some of those I have phrased as questions below, but they really are requests
to improve the text. My
the -best- name.)
Forwarded Message
From: internet-dra...@ietf.org
To: Peter van Dijk
Subject: [EXT] New Version Notification for draft-vandijk-dnsop-ds-
digest-verbatim-02.txt
Date: 11/04/24 11:04:26
A new version of Internet-Draft draft-vandijk-dnsop-ds-digest-verbatim-02.txt
has been success
added note in the Security Considerations about DF makes
sense to me - we will have to see if anybody is willing to do the DF
experiment for real, of course.
Kind regards,
--
Peter van Dijk
PowerDNS.com B.V. - https://www.powerdns.com/
___
DNSOP mailing
Reviewer: Peter van Dijk
Review result: Ready
Thank you for addressing my last nit. This looks ready to me.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
not. Nonetheless,
>resolution failures from FORMERR responses are rare.
Looks good to me, thanks.
Kind regards,
--
Peter van Dijk
PowerDNS.com B.V. - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
YG5s6po/
you said "good point, we need to address this".
After that I have seen no communication on the list about addressing
this, so I'm very surprised to see this publication request.
Kind regards,
--
Peter van Dijk
PowerDNS.com B.V. - https://www.powerdns.com/
___
Reviewer: Peter van Dijk
Review result: Ready with Nits
Thank you for processing my previous comments. The document is in great shape.
I have one nit:
One of the new sections based on my earlier comments is "2.7. FORMERR
Responses". It currently says
> Upon receipt of a FOR
ct! I missed
this one until now.
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
sconfigured (e.g., the name server
> is not authoritative for the given zone, also known as 'lame')." It
> prohibits unnecessary "aggressive requerying" to the parent of a non-
> responsive zone by sending NS queries.
>
> The problem of aggresive requerying to parent zones is not limited to
> queries of type NS. This document updates the requirement from
> section 2.1.1 of [RFC4697] to apply more generally: Upon encountering
> a zone whose name servers are all non-responsive, a resolver MUST
> cache the resolution failure. Furthermore, the resolver MUST limit
> queries to the non-responsive zone's parent zone (and other ancestor
> zones) just as it would limit subsequent queries to the non-
> responsive zone.
Looks great.
Thanks!
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 Mon, 2023-06-26 at 07:47 -0700, Peter van Dijk via Datatracker wrote:
> ## 3.2
>
> A previous review
> (https://mailarchive.ietf.org/arch/msg/dnsop/sJlbyhro-4bDhfGBnXhhD5Htcew/)
> suggested that the then-chosen tuple was not specific enough, and also said it
> was too pre
Reviewer: Peter van Dijk
Review result: Almost Ready
I have been selected as the DNS Directorate reviewer for this draft. The
DNS Directorate seeks to review all DNS or DNS-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the
s" do.
PowerDNS Authoritative Server:
* the default DNSSEC algorithm is 13
* responses are minimal, this is not configurable
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://ww
for PowerDNS. This brings us to 3
production ready implementations of this specification, which I think is
an excellent number. I'll update the draft text (in GitHub) to reflect
this.
More details at https://doc.powerdns.com/authoritative/catalog.html
Kind regards,
--
Peter van Dijk
Powe
thanks to DNS flag day 2020.
>
> - API to get PMTU to any destination is available on many platforms
> (other than Linux)?
As far as such APIs exist, they rely on the few bits of data your kernel
happens to have learned recently. Usually, the data you want
ing. I do see
it's not the most likely outcome :-)
(2, then 1, perhaps?)
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 Fri, 2022-07-29 at 13:50 +, Paul Hoffman wrote:
> On Jul 29, 2022, at 8:58 AM, Peter van Dijk
> wrote:
> > The mention of 5011 talks about the root, but 5011 does not mention the
> > root at all. 5011 is not limited to the root.
>
> It is limited to "trust
ially important document, as NSEC/NSEC3 are
almost impossible to understand without it.
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
be a MAY, or a lowercase "can retry using ...".
>The proposed method supports incremental deployment.
In its current shape, this document does not really propose a method for
anything. If the document gets updated to provide implementable advice,
it should get an Implementation St
onion names differently from other queries. By default,
> authoritative servers MUST NOT respond authoritatively to
> queries for .onion names.
I like this even more.
> The "By default" qualifier covers the case of a non-default
> configuration (such as being c
be changed
when you get a number assigned.
So, Paul, I support the idea behind your draft, but not the current
wording. While more 253-like points might be somewhat useful, what we
really need are experimental code points with non-253 semantics.
Kind regards,
--
Peter van Dijk
P
ning SERVFAIL.
Is "as insecure" missing after "treated"?
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
n
authoritative servers in this document, and I think non-authoritative
NXDOMAINs would be very confusing. In particular, resolvers would not
believe them anyway.
That all said, I can certainly see that other texts than my suggestion
could make sense.
Kind regards,
--
Peter van Dijk
PowerDNS.C
On Fri, 2021-10-22 at 12:44 -0400, Rose, Scott W. wrote:
> On 22 Oct 2021, at 12:13, Wes Hardaker wrote:
>
> > Peter van Dijk writes:
> >
> > > > It remains to be debated whether these ideas that you shouldn't use
> > > > unless you h
e debated whether these ideas that you shouldn't use
> unless you have to should eventually be published as an RFC.
I'm torn on this one. Sometimes going insecure is what has to happen, and for
those cases, operational guidance is good to have.
Kind regards,
--
Peter van Dijk
NSEC3 proof
missing (because it is ignored).
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
ion, maybe you want to read it and see if anything surprises you):
https://doc.powerdns.com/recursor/dnssec.html#what-when
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
here): get the draft out of the way first and hope
that we manage to limit discussion time on it, to leave time for the
wider WG discussion on priorities.
It is understood. Thank you.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
_
irs apologized to me later
> that they hadn't responded earlier and said they could fit me on Thursday.
Ah, apologies, then - I assumed it was post-cutoff because I did not notice any
email about the draft on dnsop pre-cutoff.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV -
o me to discuss prioritisation -after-
we spend time talking about current and, especially, new business.
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
to say that out loud here, that there is no expection of
-resolver- software to handle this signal in any special way.
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
level for this 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
, but do not feel entirely capable of judging that. If (again, when
there's WG bandwidth) we draft a document about why 5011 is a bad fit for the
root, perhaps somebody can contribute text about the level-of-fit for other use
cases.
Kind regards,
--
ppy to write text for that, if there
is an appetite - 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
ike many other 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
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
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
lower the DNSKEY TTL (in PowerDNS).
A quick skim of the BIND dnssec-keygen manual page suggests that BIND
might sometimes take the SOA TTL as the DNSKEY TTL.
So, yes, there might be consequences. I will add a note.
> Section 8
>
> Why is RFC 8174 only an informative referenc
at is only useful 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
ne here.)
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
> that
> 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.
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
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 serial; this also reinvokes the 'why not put
it in AUTHORITY 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
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
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
> IETF.
> >
> > Title : DNS Catalog Zones
> > Authors : Peter van Dijk
> > Libor Peltan
> > Ondrej Sury
> > Willem Toorop
> >
ill smells like 'you should do this'.
How about:
These features are implemented as low-level socket options, and they
are not activated automatically. If applications wish to use these
features, they will need to make specific calls to set the right
options, and administrators ma
ins only')
* we use 1-1-1-3-3-.. label steps, which is not exactly what section 2.3
describes
(you can find some more details at
https://doc.powerdns.com/recursor/appendices/internals.html#qname-minimization )
Kind regards,
--
Peter van Dijk
PowerDNS
aft-ietf-dnsop-avoid-fragmentation/ even
proposes setting DONTFRAG socket options, and some servers out there already
send IPv4 replies with the DF bit set (the two I can verify immediately are
OpenDNS, and whatever is running on the router my provider gave me, but most
likely there a
case 'must' is confusing.)
Suggested extra text:
> The Linux TCP_DEFER_ACCEPT feature, while more limited in scope, can
provide some of the same benefits as the BSD accept filter feature.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
contents.
> >
> > + Recursive resolvers MAY treat the SvcParams portion of the SVCB RR
> > + as opaque. No part of this specification requires recursive resolvers
> > + to alter their behavior based on its contents, even if the contents are
> > + invalid.
>
>
omewhere that I missed in the references. I'm
> > happy to take a "go read this for the answer" if that's the 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
me checks.
The only thing I wonder about is whether we can combine the 3597 format
with the 3 part breakdown 7477 did on the hexdump, which also is very
educational. Of course, nothing prevents us from doing both the
breakdown and a couple of 3597 pairings.
So, +1 from me!
Kind regards
he length is limited to some sensible value?
The reporting query comes from an IP, presumably owned by the 'failing'
resolver, or some upstream of it. That IP is in a WHOIS database. Am I
too optimistic when I suggest that the WHOIS database ca
esponse (with
rcode NOERROR or NXDOMAIN), no records are harvested and the whole
query is retried over TCP.
Based on only our choices, it is pointless to have any content in a
TC=1 response. Others may feel somewhat differently, of course!
Kind regards,
--
P
ried by random
tools that might have unrelated semantics.
I'm not arguing that catalog zones -should- use TXT for everything
(because that would be terrible); but the firmess of 5507's conclusion
does not fully apply here.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.p
New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
>
> Title : NSEC and NSEC3 TTLs and NSEC Aggressive Use
> Author : Peter van Dijk
>
>
> Title : NSEC and NSEC3 TTLs and NSEC Aggressive Use
> Author : Peter van Dijk
> Filename: draft-ietf-dnsop-nsec-ttl-03.txt
> Pages : 9
> Date: 2021-02-09
>
> Abstract:
>Due to a combin
when that effective TTL expires."
The client (I assume you mean a caching validating resolver) should not
do that at all. If the document suggests that to you, please help me
fix that.
Note that if we -did- wanted to write this, we couldn't - section
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
ion Status' 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
et-Draft is available from 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
when people change operators.
In short, moving this pain into the signers&auths (both of which come from only
a handful of vendors!) actually makes a lot of sense to me. Many TLDs will be
able to 'implement' CNSRRSIG (or some other va
s 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,
--
P
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
>
> Ab
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
ation does not
currently cap the TTL of expanded 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
even a Background section, and 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
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
Than
n convinced this 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
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 in
that you'd 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-
n extremely slow,
> I do think in recent years it has been much better and 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:
arent sign 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-0
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
erver, or can it be done opportunistically so
that the information eventually appears in the cache? (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
etting about a
query 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
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
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
pe of things is 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
f Answer/Additional/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
ers.xhtml.
Section 11, second RUN TIME REC: certainly an operator is 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 short
client 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 r
he perceived privacy concerns.
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
PowerDN
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
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 &quo
N.
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
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
r 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
eful 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
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
lowest 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@iet
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
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
ill 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
1 - 100 of 164 matches
Mail list logo
