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
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
po/
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
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
er
> 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
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
PowerDNS.
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 will not b
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
lly 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
rcase "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 Status section.
Secti
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
anged
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
PowerD
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
ative 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.COM BV - ht
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 have t
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
PowerDNS.COM BV - ht
ause 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
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
: 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/
__
s 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 - https://w
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
t 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
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
f 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,
--
Peter van Dijk
PowerDNS.COM BV - https://www.pow
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
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 devi
L (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 reference? Shouldn't it be
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,
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
> 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
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
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
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
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
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
> > Title : DNS Catalog Zones
> > Authors : Peter van Dijk
> > Libor Peltan
> > Ondrej Sury
> > Willem Toorop
> > Leo Vandew
'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 may need to configure the a
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.COM BV - https://www.pow
nsop-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 are others
'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/
___
ents.
> >
> > + 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.
>
> This
hat 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
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,
--
s 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 can provide the
c
sponse (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,
--
Peter
y 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.powerdns.com/
__
net-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
> Filenam
: 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 combination of unfortunate wording i
ctive 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 3.4
('No updates to
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
' 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
n into the signers (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 variant) through the regular
updates I trust they already do.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns
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
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
>
>
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
> >
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
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
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!
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
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
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
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
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
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
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
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
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
Power
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
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
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 -
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
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
regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, 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
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
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
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
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
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
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
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
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
). 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
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
. 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
.
See you there!
Cheers,
Peter van Dijk, Shane Kerr, Pieter Lexis
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
1 - 100 of 145 matches
Mail list logo
