On Thu, Oct 31, 2019 at 2:41 PM Brian Dickson
wrote:
>
>
> On Thu, Oct 31, 2019 at 4:12 PM John Levine wrote:
>
>> In article <
>> cahbrmsdwdotqn8y5zk7rsvepjwwyateyaa6f0oj9desmafh...@mail.gmail.com
>> >
>> you write:
>> >The ideas floated here about ADoT to the root are not, in my view, about
On Thu, 31 Oct 2019, Brian Dickson wrote:
IMNSHO, ADoT at the leaf + QNAME minimization is all that is required for
privacy.
I.e. No need for ADoT anywhere other than at the leaf zone's name server
(whose NS name might not be in-bailiwick, FYI).
I dunno, I can think of some 2LD queries that
On Thu, Oct 31, 2019 at 4:12 PM John Levine wrote:
> In article <
> cahbrmsdwdotqn8y5zk7rsvepjwwyateyaa6f0oj9desmafh...@mail.gmail.com> you
> write:
> >The ideas floated here about ADoT to the root are not, in my view, about
> >privacy (directly). They're about using ADoT to protect the
In article
you write:
>The ideas floated here about ADoT to the root are not, in my view, about
>privacy (directly). They're about using ADoT to protect the integrity of
>(currently) unsigned data in the root zone.
>
>An alternative solution is to get ADoT bootstrap info from the child zone,
Hiya,
On 31/10/2019 19:49, Ben Schwartz wrote:
> An alternative solution
I wonder if we'd be better off here if we encourage people
to do and document experiments before we try to select one
(or >1) approach?
I figure the trade-offs are complex enough that a round of
people pruning
On Wed, Oct 30, 2019 at 2:37 AM Watson Ladd wrote:
>
> The root zone is data: whether one distributes it via DoT, DoH, IPv6, or
> carrier pigeon is irrelevant to the policies that goven what's in it.
>
That is arguably true, but I think we are having this discussion primarily
because of RFC
In article
you write:
>I may have misunderstood John, of course, but that's the point of what I
>understood him to be saying.
Pretty much.
The root is an unusual zone in that it is small and unlikely ever to
be huge, it is easy to AXFR without prior arrangement, and its
management is subject
In article
you write:
>I think there will be both interest and deployment, sufficient to justify
>the effort.
I hope so, but some actual comments from large DNS operators would be welcome.
>root-servers.net be DNSSEC signed, but without a secure delegation. ...
Do any DNS resolvers use
On Thu, Oct 31, 2019 at 3:27 PM Ted Hardie wrote:
>
> On Thu, Oct 31, 2019 at 12:06 PM Jim Reid wrote:
>>
>>
>> There are gazillions of layer-9+ problems around the introduction of new or
>> different distribution mechanisms at the root for serving root zone data.
>> Not least of these are the
On Thu, Oct 31, 2019 at 12:06 PM Jim Reid wrote:
>
> There are gazillions of layer-9+ problems around the introduction of new
> or different distribution mechanisms at the root for serving root zone
> data. Not least of these are the interminable ICANN consultations that
> inevitably have to
On Thu, Oct 31, 2019 at 12:11 PM Jim Reid wrote:
>
>
> > On 30 Oct 2019, at 18:40, Livingood, Jason
> wrote:
> >
> > I agree that this is not a technical issue of scaling the root; that
> quantity of queries per day and second is not a big problem. Rather, as you
> note, it is a layer-9 issue.
> On 30 Oct 2019, at 06:37, Watson Ladd wrote:
>
> The root zone is data: whether one distributes it via DoT, DoH, IPv6, or
> carrier pigeon is irrelevant to the policies that goven what's in it.
I agree. But that's orthogonal to what I thought we were discussing.
There are gazillions of
> On 31 Oct 2019, at 01:21, John Levine wrote:
>
> In article
> you
> write:
>> Encryption at the root is very possible.
>
> Indeed, but that's not the same question as whether it's a good idea.
+1
>
> ...
> Let's put this in the pile of things to think about later.
+1 to that too.
> On 30 Oct 2019, at 18:40, Livingood, Jason
> wrote:
>
> I agree that this is not a technical issue of scaling the root; that quantity
> of queries per day and second is not a big problem. Rather, as you note, it
> is a layer-9 issue. But I don't think we should constrain our requirements
The working group has given lots of feedback on this and the authors have
worked to address all these concerns. The last larger item was discussed and
resolved during our interim.
We want to run a 1 Week WGLC to confirm all outstanding items have been
resolved.
This starts a Second Working
Thanks Stephen
(Follow up on this in another email)
On Thu, Oct 31, 2019 at 9:16 AM Stephen Farrell
wrote:
>
> Hiya,
>
> On 31/10/2019 13:12, Sara Dickinson wrote:
> > Hi All,
> >
> > Following the DPRIVE interim meeting earlier this week I’ve done an
> > update to the draft with two main
Hello.
> 4.5 End-User Policy Propagation
I think the client-subnet part here is fully covered by the current RFC
7871 already, but that seems an unimportant nitpick at this point.
--Vladimir
___
dns-privacy mailing list
dns-privacy@ietf.org
Hiya,
On 31/10/2019 13:12, Sara Dickinson wrote:
> Hi All,
>
> Following the DPRIVE interim meeting earlier this week I’ve done an
> update to the draft with two main changes:
>
> 1) I have remove the text around consent that did not have consensus
> i.e. paragraph 2 in section 5.3.3 and Item
Hi All,
Following the DPRIVE interim meeting earlier this week I’ve done an update to
the draft with two main changes:
1) I have remove the text around consent that did not have consensus i.e.
paragraph 2 in section 5.3.3 and Item 6 in the DROP Practice statement (and in
the example). I
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS PRIVate Exchange WG of the IETF.
Title : Recommendations for DNS Privacy Service Operators
Authors : Sara Dickinson
20 matches
Mail list logo
