Sent from my iPhone
> On Mar 24, 2019, at 10:42 PM, Patrick McManus wrote:
>
>
>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson
>> wrote:
>>
>> This is important for network operators in identifying encrypted DNS traffic,
>
> not all clients acknowledge a network's right to do such thing
On Sun, Mar 24, 2019 at 11:25 PM Paul Wouters wrote:
> On Sun, 24 Mar 2019, Brian Dickson wrote:
>
> > There is one important difference, which is that DoT uses a unique port
> number. This is important for network
> > operators in identifying encrypted DNS traffic, in order to ensure that
> impl
On Sun, Mar 24, 2019 at 11:14 PM Vittorio Bertola
wrote:
>
> In today's "plain DNS" world, I choose a DNS resolver that provides that kind
> of filters for me, I set it up on my router, and my router pushes it to my
> smart TV via DHCP. What is the "existing configuration mechanism" that allows
On Sun, 24 Mar 2019, Brian Dickson wrote:
There is one important difference, which is that DoT uses a unique port number.
This is important for network
operators in identifying encrypted DNS traffic, in order to ensure that
implementation of security policies for
DNS don’t conflict with any ot
> Il 24 marzo 2019 alle 22.42 Patrick McManus ha scritto:
>
>
> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
> brian.peter.dick...@gmail.com mailto:brian.peter.dick...@gmail.com > wrote:
>
> > >
> >
> > This is important for network operators in identifying encrypted
On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
brian.peter.dick...@gmail.com> wrote:
>
> This is important for network operators in identifying encrypted DNS
> traffic,
>
not all clients acknowledge a network's right to do such things at all
times. And of course it would be useful to tell the d
Sent from my iPhone
>> On Mar 24, 2019, at 9:43 PM, Patrick McManus wrote:
>>
>>
>
>> On Fri, Mar 22, 2019 at 11:15 AM Winfield, Alister
>> wrote:
>>
>> Don't overplay the privacy provided by DoH it has no effect on the DNS
>> provider
>
> The major effect of the transport security on t
On Sun, 10 Mar 2019 at 15:31, Tim Wicinski wrote:
>
> This starts a Call for Adoption for draft-wessels-dns-zone-digest
>
I believe DNSOP should adopt this draft.
> Please also indicate if you are willing to contribute text, review, etc.
>
I am willing to review and contribute text.
>
>
On Sun, 24 Mar 2019 at 17:17, Joel Jaeggli wrote:
>
>
> On Mar 24, 2019, at 08:59, Matthew Pounsett wrote:
>
>
>
> On Sun, 24 Mar 2019 at 11:46, Paul Hoffman wrote:
>
>>
>> > I'm also not too hot for conflating "user consciously changes
>> > /etc/resolv.conf or equivalent" with "application mak
I want to add one thought to the general argument that goes along the lines
of "I need to enforce a policy on my network, and doh will just encourage
more https interception - we have gotten nowhere."
This argument assumes a scenario where the network is trusted by the
application and can require/
On Fri, Mar 22, 2019 at 11:15 AM Winfield, Alister wrote:
>
> Don't overplay the privacy provided by DoH it has no effect on the DNS
> provider
The major effect of the transport security on the privacy practices of the
provider is that it allows the client to authenticate the provider. Trust
in
> On Mar 24, 2019, at 08:59, Matthew Pounsett wrote:
>
>
>
>> On Sun, 24 Mar 2019 at 11:46, Paul Hoffman wrote:
>>
>> > I'm also not too hot for conflating "user consciously changes
>> > /etc/resolv.conf or equivalent" with "application makes the choice for the
>> > user".
>>
>> The split
On Sun, 24 Mar 2019 at 11:46, Paul Hoffman wrote:
>
> > I'm also not too hot for conflating "user consciously changes
> > /etc/resolv.conf or equivalent" with "application makes the choice for
> the
> > user".
>
> The split here is more "someone changes from traditional without the user
> knowing
Hi Daniel,
At 07:10 AM 23-03-2019, Daniel Migault wrote:
We would particularly appreciate to share your thoughts and discuss
the requirements to operate DNSSEC validators. In particular, feed
backs from operators or implementers would be more than welcome.
Please feel free to share your thought
first, thank you for this statement, and for the policies it describes.
Puneet Sood wrote on 2019-03-22 15:08:
...
As a core principle, Google Public DNS aims to provide a DNS resolver
that respects our users’ privacy. Towards that goal, we aim to provide
high quality implementations of various
I don't like it either because DAO is a well known acronym for Data Access
Object.
On Sun, Mar 24, 2019 at 12:49 PM Warren Kumari wrote:
>
>
> On Sun, Mar 24, 2019 at 11:46 AM Paul Hoffman
> wrote:
>
>> On Mar 24, 2019, at 11:18 AM, bert hubert
>> wrote:
>> > It may be good to add a note that
On 24/03/2019 12:36, Paul Vixie wrote:
in other words, we'd be negotiating for the right to re-interpret
existing signaling (the authority's TTL no longer purely governs the
data's lifetime) by insisting that the parent zone's delegating TTL be
given absolute power for revocation.
+lots
I support adoption and note that since the draft already has an early code
point allocation there really isn’t any strong argument for not adopting it
anymore. The code point is lost, so we might as well make it as good as
possible :)
Sent from mobile device
> On Mar 10, 2019, at 15:31, Tim Wi
We received positive feed back for Monday. So we will meet in the main
lobby at 12:20 during the lunch break. See you there!
Yours
Daniel
On Sat, Mar 23, 2019, 15:10 Daniel Migault
wrote:
>
> Hi,
>
> We would particularly appreciate to share your thoughts and discuss the
> requirements to operat
Paul Hoffman wrote:
> Greetings again. As y'all have seen over the past few weeks, the
> discussion of where DNS resolution should happen and over what
> transports has caused some people to use conflicting terms. As a
> possible solution to the terminology problems, I am proposing a few
> abbrevi
On Sun, Mar 24, 2019 at 04:36:50AM -0700, Paul Vixie wrote:
> i object to serve-stale as proposed. my objection is fundamental and goes to
> the semantics. no editorial change would resolve the problem.
I too object. This is partially due to the apparently unresolved IPR issue
from Akamai, who ar
On Sun, Mar 24, 2019 at 4:49 AM Warren Kumari wrote:
>
>
> On Sun, Mar 24, 2019 at 11:46 AM Paul Hoffman
> wrote:
>
>> On Mar 24, 2019, at 11:18 AM, bert hubert
>> wrote:
>> > It may be good to add a note that "DoH is the protocol as defined in
>> > [RFC8484]. The operation of this protocol by
On Sat, Mar 23, 2019 at 10:44 PM Kenji Baheux wrote:
>
>
> On Sat, Mar 23, 2019, 13:04 Wes Hardaker wrote:
>
>> Kenji Baheux writes:
>>
>> > * We are considering a first milestone where Chrome would do an
>> automatic
>> > upgrade to DoH when a user’s existing resolver is capable of it.
>
On Sun, Mar 24, 2019 at 11:46 AM Paul Hoffman
wrote:
> On Mar 24, 2019, at 11:18 AM, bert hubert
> wrote:
> > It may be good to add a note that "DoH is the protocol as defined in
> > [RFC8484]. The operation of this protocol by browser vendors and cloud
> > providers is frequently also called 'D
i object to serve-stale as proposed. my objection is fundamental and
goes to the semantics. no editorial change would resolve the problem.
i would withdraw that objection if this draft incorporates section 2 of
https://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00, to wit:
2. Delegati
Hello everyone,
Several folks have worked on implementing the
draft-ietf-dnsop-extended-error at the IETF Hackthon yesterday and
today. This is my own feedback on the draft based on trying to get it
added to dnsdist.
Stéphane Bortzmeyer pointed out that it wasn't clear how
On Mon, Mar 11, 2019 at 03:08:10PM -0700,
internet-dra...@ietf.org wrote
a message of 46 lines which said:
> Title : Extended DNS Errors
> Authors : Warren Kumari
> Evan Hunt
> Roy Arends
>
Hi,
On 08/03/2019 21:29, Dave Lawrence wrote:
> Huh, My understanding from a hallway conversation with Benno was that
> the immediate response is only sent for names that would have been
> subject to pre-fetching, such that the immediate response in this case
> is sufficiently covered under the g
On Mar 24, 2019, at 11:18 AM, bert hubert wrote:
> It may be good to add a note that "DoH is the protocol as defined in
> [RFC8484]. The operation of this protocol by browser vendors and cloud
> providers is frequently also called 'DoH'. DoH-the-protocol is
> therefore frequently conflated with Do
On Sun, Mar 10, 2019 at 7:31 AM Tim Wicinski wrote:
>
> The chairs feel the document has been updated to address
> several issues raised from the last meeting, including
> some implementations.
>
> If there is pushback during this call for adoption, we can
> take the topic up in Prague.
>
> This
On Sun, Mar 24, 2019 at 06:42:53AM +, Paul Hoffman wrote:
> to the terminology problems, I am proposing a few abbreviations that
> people can use in these discussions. The draft below, if adopted by the
> DNSOP WG, would update RFC 8499 with a small set of abbreviations.
Hi Paul,
Thank you
Hi Tim,
On Mar 10, 2019, at 15:31, Tim Wicinski wrote:
> Please review this draft to see if you think it is suitable for adoption by
> DNSOP, and comments to the list, clearly stating your view.
I support adoption of this draft by dnsop.
> Please also indicate if you are willing to contribute
The chairs spoke with Paul yesterday, and we are in agreement, if the
working group feels these are useful terms
to be added (and several of them are in common use already), we're good on
adopting and fast tracking the whole
document.
Tim
On Sun, Mar 24, 2019 at 8:02 AM Paul Hoffman wrote:
> G
The DNSOP WG has placed draft-hoffman-dns-terminology-ter in state
Candidate for WG Adoption (entered by Tim Wicinski)
The document is available at
https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology-ter/
___
DNSOP mailing list
DNSOP@ietf.o
Greetings again. As y'all have seen over the past few weeks, the discussion of
where DNS resolution should happen and over what transports has caused some
people to use conflicting terms. As a possible solution to the terminology
problems, I am proposing a few abbreviations that people can use i
35 matches
Mail list logo
