On Mon, 2023-07-03 at 10:50 +0200, Peter van Dijk wrote:
> On Fri, 2023-06-30 at 16:32 +, Paul Hoffman via dnsdir wrote:
> > The current wording at the end of 4.6.9 is:
> > But if `R` is unsuccessful (e.g. timeout or connection closed):
> >
> > I believe that cha
> But if `R` is unsuccessful (RCODE other than 0, timeout, connection
> closed):
>
> Does that fix your case and not break other cases?
You need to allow, at a minimum, RCODE 3 (NXDomain) too.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV
4.7.1 [3])
[1]
https://blog.powerdns.com/2022/05/30/powerdns-recursor-4-7-0-released/
[2]
https://blog.powerdns.com/2022/06/13/probing-dot-support-of-authoritative-servers-just-try-it/
[3] https://github.com/PowerDNS/pdns/pull/11692
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https
On Thu, 2022-02-03 at 12:59 -0500, Daniel Kahn Gillmor wrote:
> Hi Peter, DPRIVE folks--
>
> On Thu 2022-02-03 11:03:35 +0100, Peter van Dijk wrote:
> > Speaking only for myself: some of the parts still seem too prescriptive
> > to me (but I know I haven't been clear on w
k. We strongly suggest that
the WG adopts unilateral-probing so we can work out what it would take
to get some implementation work going.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@iet
be judged at its merits, which has been hard for various
handwavy proposals only seen in messages in email threads.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
you have a
bunch of RFCs to update.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
>2. Recursive resolver to authoritative servers
>3. Zone transfers
>
> Do you agree/disagree that the use cases should be considered for DoQ?
agree
> Do you agree/disagree that DoQ provides sufficient functionality for the
> use cases?
agree
Kind regards,
--
Pe
ystem port (<=1024) or non-system port (>1024).
system port (<1024) or non-system port (>=1024)
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
empt to port 853. Similar for DoH (443) and DoQ (the
QUIC protocol has a CONNECTION REFUSED error code). This way, the
downgrade in a resolver can be swift, instead of having to wait for
timeouts.
- Peter van Dijk & Paul Hoffman
___
dns-privacy m
it too became a WG document, particularly to help focus the discussions on
> the unauthenticated and fully-authenticated use cases.
>
> --Paul Hoffman and Peter van Dijk
>
> https://www.ietf.org/archive/id/draft-pp-dprive-common-features-01.txt
> https://www.ietf.org/archive/id/dra
Paul Hoffman , Peter van Dijk <
peter.van.d...@powerdns.com>
Subject: [EXT] New Version Notification for draft-pp-dprive-common-
features-00.txt
Date: Sun, 02 May 2021 09:51:09 -0700
A new version of I-D, draft-pp-dprive-common-features-00.txt
has been successfully submitted by Pete
siderations for both
> proposals.
This makes sense to me. The explored solution space (which is way
bigger than the viable solution space!) has covered so much ground,
we've basically already seen it all. So, it is better to judge each
proposal on its own, honestly stated indeed, merits (and deme
Hello DPRIVE,
First, a recap of my IETF110 presentation for those who missed it. I
explained that the recent version of our opportunistic/unauthenticated
draft (draft-ietf-dprive-opportunistic-adotq-01) included a rough
skeleton of support for an authenticated use case, because no other
proposal
aček and Tomáš Křížek said.
I also oppose adoption, for these reasons and many other reasons
already given in the thread by others.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
m (
https://mailarchive.ietf.org/arch/msg/dns-privacy/xOVfHOR6FFFPxsFqM8eB44J-Db0/
) never made it into a draft, because at the time it did not seem like
the right direction for the WG.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
__
On Thu, 2021-02-11 at 13:54 -0500, Tim Wicinski wrote:
> Thanks Sara
>
> Folks should take a look at the changes, and those who raised issues can
> ensure
> these updates have addressed everything.
This update works for me. Thanks!
Kind regards,
--
Peter van Dijk
PowerDNS
der or intermingled responses as they will
> never receive them. "
>
> Would that address your concerns? It would also be good to hear from other
> folks if they agree with this balance.
This works for us. Thank you very much!
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV
On Wed, 2021-01-27 at 21:35 +0100, Peter van Dijk wrote:
>
> > I'm not one of the authors, but re-reading the draft with "intermingling"
> > in focus, I think the issues are:
> > - The intermingling aspect originates in RFC5936 (over TCP)
>
> Several p
could multiplex multiple XFR
> over TCP streams, such as from multiple TCP clients to multiple TCP servers,
> across "shared" TLS XFR sessions (site to site). But that is conjecture only
> at this point.
Yes, but definitely possible. Such a proxy would need to be aware of DNS TCP
framing, of course.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
with primaries actually intermingling multiple XFR responses over a single
TCP/TLS session, and with secondaries actually firing off several XFR requests
on a single connection to receive the zone chunks in whichever order they may
come?
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV -
ery mechanism is "the parent's zone signer software";
that would just leave open the question of delivering the policy flag
that Vladimir mentioned).
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Fri, 2020-11-20 at 20:47 +0100, Vladimír Čunát wrote:
> On 11/19/20 2:05 PM, Peter van Dijk wrote:
> > 1. auth operators publish TLSA records for their NSes
> > 2. the registry, while generating zone files, queries for those TLSA records
> > 3. from the found TLSA
the TLD zone file grow by 100k
records by publishing one additional (TLSA) record for one of their NSes
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org
uch lower congnitive load for
> operators who can reuse their https knowledge; deveopers don't have to
> write code that's too weirdly different from https; very straightforward
> parallel deployment for DoT, DoH, DoQ (if we ever want to support more
&g
On Tue, 2020-11-17 at 23:30 +, Tony Finch wrote:
> Peter van Dijk wrote:
> > The incremental cost for a resolver (doing a full resolution process
> > for the TLSA records of one or more NS names) is not small, and neither
> > are the latency costs. For 'popular' name s
derstand you
correctly. The other problem is protecting the delegation NS records against
meddling, for which various partial solutions have been provided but we have
zero standardised today.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
On Tue, 2020-11-17 at 01:21 +, Tony Finch wrote:
> Thanks for reading and providing feedback!
>
> Peter van Dijk wrote:
>
> > On Wed, 2020-11-11 at 19:07 +, Tony Finch wrote:
> > > * Encryption would apply to the server as a whole, whereas the
> &
-hashing variants of 'authenticate data that is
unsigned today'.
:-)
(If you'd like to have more puzzle pieces,
https://github.com/PowerDNS/parent-signals-dot has some additional semi-rambly
thoughts in the area, although most of it has made it into conversations on
DPRIVE and DNSOP meanwhile).
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Which buys you very little if the name you are looking up is from an
unauthenticated source - like NS names in delegations.
> So, downgrade-resistant, period.
No.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
tative for multiple zones. As
such, a name server MAY support use of a secure transport
protocol for one zone, but not for another.
So in fact, right now we have written down that this is allowed. But I
think it is a mistake.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV -
On Sun, 2020-11-15 at 16:52 +, Paul Hoffman wrote:
> Thanks for the response! I hope that there is more list discussion before the
> WG meeting this week.
>
> On Nov 15, 2020, at 5:52 AM, Peter van Dijk
> wrote:
> > The cost of port checking is not low.
>
> We d
nclude_text=1
)
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
in other parts of that process.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Wed, 2020-08-12 at 12:51 +0200, Peter van Dijk wrote:
> Delegation NS records are not signed, so do we stick -those- (or a hash
> of the NSset perhaps?) into DS?
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/?include_text=1
Kind regards,
--
Pet
offman and others that we have plenty of proposals,
fully worked out or not, but not a lot of agreement on what the actual shape is
of the problem we are solving.)
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-p
still believe a DNSKEY bit on
> the DNSKEY to signal encrypted DNS availability would be worth pursuing.
As I said before, if this is the contribution that makes some other
draft work, I'll also be happy :)
Kind regards,
--
Peter van Dijk
PowerDNS.COM
> Please respond to the mailing list with your view (positive or
> > negative) and supporting rationale on adopting the draft. This WGLC will
> > end on 2020-08-24 at 23:59 UTC.
> >
> > Regards,
> > Brian & Tim
> >
Kind regards,
--
Peter van Dijk
PowerDNS
(I changed the subject because this has turned into a solution
conversation, instead of a use case conversation)
On Tue, 2020-08-11 at 21:49 -0400, Paul Wouters wrote:
> On Mon, 10 Aug 2020, Peter van Dijk wrote:
>
> > On Thu, 2020-08-06 at 23:04 -0400, Paul Wouters wrote:
>
nt to prescribe resolver behaviour for other discovery methods
(such as opportunistic). Sensible handling of connection establishment and
pooling feels like a separate topic to me, so I don't think it should be part
of any discovery document. I am unsure it should be an IETF spec at all.
Kind reg
On Thu, 2020-08-06 at 23:04 -0400, Paul Wouters wrote:
>
> In the case of encrypted DNS to authoritative servers, those servers
> obviously can have an cryptographic ID based on FQDN.
This is not obvious. It would be great if it was; but it isn't.
Kind regards,
--
Peter van Dijk
Pow
as the response to RRSIG queries).
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Hello Paul,
On Thu, 2020-07-16 at 15:29 -0400, Paul Wouters wrote:
> On Mon, 13 Jul 2020, Peter van Dijk wrote:
>
> > please find below revision -01 of our proposal for enabling DoT from
> > resolver to authoritative.
>
> DoT can be enabled regardless. This draft is no
ple,
>
>more than one DS record with DNSKEY algorithm TBD
>
> is better as just
>
>more than one DS record with algorithm TBD
Thanks! We've noted this at
https://github.com/PowerDNS/parent-signals-dot/issues/37 and will
improve the wording for -02.
K
be presenting the draft at the IETF108 dprive session.
Kind regards,
Manu, Robin & Peter
Forwarded Message
From: internet-dra...@ietf.org
To: Robin Geuze , Peter van Dijk <
peter.van.d...@powerdns.com>, Emmanuel Bretelle
Subject: [EXT] New Version Notification for draft-vand
tors or between registries and nameserver
> operators and can be implemented right now.
I'm looking forward to reading a single, complete, coherent description
of that protocol, because I've been unable to piece it together
completely from your various emails - which tells me it does need an
RFC. If there are no roadblocks, and it can be implemented right now,
why isn't it implemented right now?
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
ker.org could also
get a cert from the same public CA.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
rypted connection (in our case, DoT). So flags are out. I think it would be
simplest to allocate one 'algorithm' number per protocol. This would also allow
protocols other than DoT to perhaps use the various DNSKEY/DS fields for
different semantics.
Kind regards,
--
Peter van Dij
On Fri, 2020-05-29 at 11:59 -0400, Paul Wouters wrote:
> On Fri, 29 May 2020, Peter van Dijk wrote:
>
> > > - Takes DNSKEY, only does syntax checks ---> we dont need to publish
> > > anything
> >
> > Yes.
>
> Actually I was wrong. We still ne
e specifically targeted at
people/organisations/groups that do not want/cannot afford/... an IANA
registration. In other words, people that don't want to go through the RFC
process. I don't think that's the path we want to be going down here :)
Kind regards,
--
Peter van Dijk
PowerDNS
On Fri, 2020-05-29 at 11:25 -0400, Paul Wouters wrote:
> On Fri, 29 May 2020, Peter van Dijk wrote:
>
> > On Wed, 2020-05-27 at 21:27 -0400, Paul Wouters wrote:
> > > It would make everything a LOT cleaner and we got no bogus
> > > DNSKEY records to ignore
y
do for any existing DNSKEY algorithm.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Thu, 2020-05-28 at 00:43 +0100, Tony Finch wrote:
> Peter van Dijk wrote:
> > On Tue, 2020-05-26 at 09:10 +0200, Ondřej Surý wrote:
> > > 1. Bit 7 of the Flags fields needs to be 0.
> >
> > Definitely [...] I noted earlier that whatever flags we might need,
omplexity of
chain-extension is preferable. For others, with a million domains, obviously
our draft does not scale. I've been assuming we'd end up with two or three
separate signals, each fit for purpose for a certain scale. Your proposal seems
like a viable candidate to be one of those to me.
K
https://indico.dns-oarc.net/event/22/contributions/315/attachments/316/555/Quest_for_the_missing_keytags.pdf
and
https://ripe78.ripe.net/presentations/5-20190520-RIPE-78-DNS-wg-Keytags.pdf
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerd
sting into a DS on their end.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
assignments between the existing and this
new registry overlap. So, we'd have to state that the two registries
may not issue overlapping assignments, in which case we might as well
stick with the one registry we have.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com
On Sun, 2020-05-24 at 17:36 -0400, Paul Wouters wrote:
> On Sun, 24 May 2020, Peter van Dijk wrote:
> > The draft says 'The pseudo DNSKEY record MUST NOT be present in the
> > zone.' What can we add to the text to make it clear that no query is
> > sent to the zone's name serv
s roundtrips; as far as I can
> > imagine, anything using TLSA would need extra queries.
>
> I don't believe a working solution cannot be allowed to introduce an
> extra roundtrip.
I also do not believe that, but it's nice that we can do wi
On Tue, 2020-05-19 at 11:46 -0400, Paul Wouters wrote:
> On Tue, 19 May 2020, Peter van Dijk wrote:
>
> > The draft is managed on GitHub in .md format at
> > https://github.com/PowerDNS/parent-signals-dot/tree/master/draft-vandijk-dprive-ds-dot-signal-and-pin
>
> We fi
On Tue, 2020-05-19 at 10:56 +0100, Jeremy Harris wrote:
> On 19/05/2020 10:24, Peter van Dijk wrote:
> > Name: draft-vandijk-dprive-ds-dot-signal-and-pin
> > Revision: 00
>
> It's almost-but-not-quite DANE, and a TLSA record. Why (not)?
I've thought about ma
On Tue, 2020-05-19 at 11:51 +0200, Mikael Abrahamsson wrote:
> On Tue, 19 May 2020, Peter van Dijk wrote:
>
> > please find below all details about our proposal for enabling DoT from
> > resolver to authoritative.
>
> Thanks, interesting approach.
Thanks!
> Some t
to your comments,
Peter, Manu & Robin
Forwarded Message
From: internet-dra...@ietf.org
To: Peter van Dijk , Emmanuel Bretelle <
chan...@fb.com>, Robin Geuze
Subject: [EXT] New Version Notification for draft-vandijk-dprive-ds-
dot-signal-and-pin-00.txt
Date: Tue, 19 May 202
his document, I agree with its
adoption. I do see that it will need some work before publication.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing l
d unsigned delegations, which I also
think is an important use case.
Glue records are never signed.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.o
an, over time, be fixed.
Personally I like the DS signalling idea a lot, but I do see the
‘cloud provider’ problem angle.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
dns-privacy mailing list
dns-privacy@i
.
See you there!
Cheers,
Peter van Dijk, Shane Kerr, Pieter Lexis
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
67 matches
Mail list logo
