Paul Wouters wrote:
>
> At the IETF, we have done a REALLY bad job at keeping secure DNS as an
> optional feature. The more we treat it that way, the more others will
> treat it that way. We should really do the opposite. DNS without DNSSEC
> is legacy. It's irresponsible. It's vulnerable. It's
I oppose adopting this draft at this time. There seemed to be interest in the
WG to focus on use cases first, and this draft is an instantiation of an use
case that is not clearly identified. Once that use case is identified, the WG
can decide whether this draft is a good potential solution for
Moin!
On 10 Aug 2020, at 13:44, Brian Haberman wrote:
Hi all,
During the DPRIVE session at IETF108, we discussed adopting
https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/
and the results were inconclusive. The chairs would like to start a
2-week call for
Hi all,
During the DPRIVE session at IETF108, we discussed adopting
https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/
and the results were inconclusive. The chairs would like to start a
2-week call for adoption to determine the WG's interest in this work.
Hi Paul,
On 8/8/20 7:39 PM, Paul Hoffman wrote:
> Sorry to break in, but what does the question of number of anycast auth
> servers have to do with this use case? Or did y'all mean to start this as a
> thread for draft-ietf-dprive-phase2-requirements, in which it could be
> relevant?
>
I
On Fri, 2020-08-07 at 19:12 -0700, Rob Sayre wrote:
> The issue is that connection establishment will be expensive, which is
> something separate from getting a bunch of queries. As others have pointed
> out, this cost will be amortized to almost nothing most of the time. After an
> outage,
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
PowerDNS.COM
