Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Brian Dickson]

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 things at all times. 
> And of course it would be useful to tell the difference between policy and a 
> RST injection attack.
> 
> If the client does acknowledge the network has the right to set policy - then 
> the policy can be set on the client using existing configuration mechanisms 
> that allow the client to differentiate between authorized configuration and 
> perhaps less-authorized folks identifying their DNS traffic. This is well 
> worn ground in the HTTP space.

What I find interesting, is that as far as I can tell, everything you wrote 
applies equally to DoH and DoT, if the transport is the only difference. E.g. 
Same client browser, same DNS service, accessed via DoH or DoT.

Are you suggesting (or claiming) otherwise, and if so, please elaborate?

Brian ___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Brian Dickson]

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
> implementation of security policies for
> > DNS don’t conflict with any other network policies (regardless of what
> those policies are.)
>
> The network cannot "ensure" this based on DNS. I can come on to the
> network with a DNS cache already, which is the functional equivalent
> of me refreshing my personal cache using a sneaky HTTPS connection.
> The network can never control my DNS cache. I won't let it.
>
> So while it was perhaps nice that network operators _could_ help in such
> a case, it was never a real defense against a smart network "abuser".
>
>
I am trying to keep conversation sub-threads specific to single variables.
In this case, I am interested in policy enforcement mechanisms, not what
the policy is or who it applies to.

The assumption in the above is that the network operator has some policy
(regardless of what it is) that it would like to enforce between some (or
possibly all) hosts, towards encrypted DNS services.
If the operator blocks all DoH, but does something less restrictive for
DoT, then the policies applied on DoT are the ones that have the desired
effect.

Yes, this is network-centric, or more specific, network-security-centric.

>From the perspective of the network policy enforcement, the applicable
rules involve 3-tuples of source, destination, and port 853 (plus TCP but
not UDP). Any such rules, when explicitly applied only to port 853, by
definition have no direct bearing on any destinations for port 443 (HTTPS).
These rules only need to be updated if/when new "permit" rules for new DoT
servers are added. This is a white-list model, which scales very nicely.

However, the blocking of specific DoH servers becomes an absolute
nightmare, in that the network operator needs continuously monitor
information from any number of sources (of various degrees of completeness,
trustworthiness, timeliness, etc), for new DoH servers, along with an
ongoing policy maintenance on (allow vs deny). This is, by its very nature,
a black-list model, which does not scale nicely, and consequently reduces
the overall security, from the perspective of the network operator (or
network security department of the enterprise network).

(See my previous message detailing *why* networks NEED to do this, at least
in the large enterprise.)

Chances are, the network segment you are on does not care one whit about
the DNS cache you have, and probably is happy to let you access whoever you
want for your encrypted DNS service.

I'm willing to wager, in the enterprise environment, they do have an
opinion on what transport they prefer you use for that: DoT.

This is mostly about scalability, and about the ability to detect abnormal
behavior distinct from regular user activity (malware, phishing, and other
use cases.)


> > IMNSHO, if both ports are reachable for a given provider of Do*, the DoT
> port MUST be used. DoH should only be
> > used with explicit informed user consent, and only when DoT is
> unavailable.. This supports the “dissident” use
> > case, without impacting any other aspects of privacy provided by DoT.
>
> If the network allows DoT, clearly it does not care about DoH being
> used? Since it will also not be able to read DoT to a remote server
> like the Quads. So I do not understand what is gained by such a
> policy.
>

It is about scale. If large numbers of users, across a variety of
platforms, all use only DoT, then restrictions about which DoT servers are
permitted can be applied.
Or, alternatively, access to new DoT servers can potentially alert the
appropriate security team(s) to investigate which machines have started
this new behavior, and get an early jump on things if this happens to be a
malware-infected device (for example).

Blocking specific DoT servers (or more typically, blocking all DoT servers
except those white-listed) allows end users to know that this blockage is
deliberate. Users can then make informed decisions about whether to accept
that blockage (e.g. due to enterprise policies, or perhaps ISP policies
where those are allowed according to contract and jurisdictional legal
frameworks), or to take unilateral action to bypass the blockage.

What is gained by preferring DoT over DoH, is scaling on the network
operator side, and clear indication of policy via DoT blocking.

Scaling for network operators is always an indirect win for users -- users
have to pay, directly or indirectly, for situations where technology does
not (and cannot) scale.


>
> Unless you meant "must use a local DoT server first", in which case we
> are again shifting the discussion towards when can or should you trust
> a network for anything but relaying IP packets. Because then you
> basically demand access 

Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Olli Vanhoja]

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 
> me to set this policy in the DoH world, i.e. if the TV came equipped with 
> applications preconfigured to use their own remote resolver via DoH?
>
> As a minimum, I would have to open all the applications and configure them 
> one by one to use my desired resolver, and repeat this for every device 
> connected to my network - while in the current situation this is all 
> automated after I configure the resolver once on my router. But applications 
> like Firefox might completely refuse to use the resolver I want, advertised 
> by my router on my behalf, because it does not support DoH, or it does but is 
> not on their list of "trusted resolvers". And Javascript bits in the pages I 
> visit might use DoH to pre-encoded servers without even offering me any 
> configuration.
>

I think configuring every application, operating system, or platform
to do the filtering is the right way regardless of the existence of
DoH. I wouldn't trust that the opinion given by a DHCP server is what
will be really used by all clients. If you need to check that's what
is really happening, wouldn't it require about the same effort to
configure the parental control features that are already provided by
many vendors. I also believe that's a lot easier thing to do for the
average user.

If you really want a DIY solution, why don't you look into the actual
HTTP(S) traffic and SNIs?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Paul Wouters]

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 other network policies (regardless of what those 
policies are.)


The network cannot "ensure" this based on DNS. I can come on to the
network with a DNS cache already, which is the functional equivalent
of me refreshing my personal cache using a sneaky HTTPS connection.
The network can never control my DNS cache. I won't let it.

So while it was perhaps nice that network operators _could_ help in such
a case, it was never a real defense against a smart network "abuser".


IMNSHO, if both ports are reachable for a given provider of Do*, the DoT port 
MUST be used. DoH should only be
used with explicit informed user consent, and only when DoT is unavailable.. 
This supports the “dissident” use
case, without impacting any other aspects of privacy provided by DoT.


If the network allows DoT, clearly it does not care about DoH being
used? Since it will also not be able to read DoT to a remote server
like the Quads. So I do not understand what is gained by such a
policy.

Unless you meant "must use a local DoT server first", in which case we
are again shifting the discussion towards when can or should you trust
a network for anything but relaying IP packets. Because then you
basically demand access to my decrypted DNS stream.

Why should I ever use a starbucks DNS server, regardless of whether
I use DoT or DoH or plain 53? On almost every network I connect to,
I only want one service: "relay my (encrypted) IP packets". The rest
of the services I obtain from trusted sources elsewhere, using this
ephemeral network as an insecure transport only.

So your policy above that you propose really assumes a lot about the
network, namely that you are considered hostile to the network and
that you trust that network more than your own device. That's a very
specific application. It basically never applies to me unless I join
an enterprise network with an enterprise device, and then we have
other ways for the enterprise to enforce things on their device.


The blocking of DoT to a given provider should be interpreted as an explicit 
policy. Users should be informed
that they may, and very likely will, be violating someone’s policy, if they 
choose to use DoH in that
circumstance, and that they may be violating laws by doing so, and should only 
do so if they are willing to
accept that risk.


Again, this is the network operator centric view. There are many hostile
networks that would block DoT just so that they could monetize (legally
or illegally!) from my harvested DNS data. I can assure you the warning
you want to write to users would be very different from the warning I
would want to give those users. Which is why the IETF doesn't do
banners towards endusers.

Besides, why should the network operator have a say about when I want my
device to connect to my remote servers? Do you want my VPN client to
throw the same warning around that it might be against the network
operator's wishes to inspect all my traffic and it might be against the
law to circumvent it? Then you also have to do that for _all_ TLS
connections, and make the internet go back to port 80. Why is there a
different expectation of website content monitoring versus dns content
monitoring? You shouldn't have access to either.


There is no reason DoH should be used if DoT works (towards the same DNS 
provider).


If DoT works to dot.nohats.ca, which you cannot decrypt, why do you care
whether I use DoH to that server or not?

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Vittorio Bertola]

> 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 
> > 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 difference between policy 
> and a RST injection attack.
> 
> If the client does acknowledge the network has the right to set policy - 
> then the policy can be set on the client using existing configuration 
> mechanisms that allow the client to differentiate between authorized 
> configuration and perhaps less-authorized folks identifying their DNS 
> traffic. This is well worn ground in the HTTP space.
> 
Let's say I just bought a new smart TV that can browse the Internet, but I 
don't want my kids to be able to access inappropriate websites from it. Or, 
let's say I actually like the fact that my operator filters out malware 
destinations at the DNS level and I want my new TV to have that protection as 
well.

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 
me to set this policy in the DoH world, i.e. if the TV came equipped with 
applications preconfigured to use their own remote resolver via DoH?

As a minimum, I would have to open all the applications and configure them one 
by one to use my desired resolver, and repeat this for every device connected 
to my network - while in the current situation this is all automated after I 
configure the resolver once on my router. But applications like Firefox might 
completely refuse to use the resolver I want, advertised by my router on my 
behalf, because it does not support DoH, or it does but is not on their list of 
"trusted resolvers". And Javascript bits in the pages I visit might use DoH to 
pre-encoded servers without even offering me any configuration.

Regards,

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Patrick McManus]

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 difference between
policy and a RST injection attack.

If the client does acknowledge the network has the right to set policy -
then the policy can be set on the client using existing configuration
mechanisms that allow the client to differentiate between authorized
configuration and perhaps less-authorized folks identifying their DNS
traffic. This is well worn ground in the HTTP space.




>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Brian Dickson]

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 the privacy practices of the 
> provider is that it allows the client to authenticate the provider. Trust in 
> their privacy practices needs to be establish some other way (and the best 
> way we have right now is 'out of band' - hopefully that gets better) - but 
> with DoH

Minor correction: with DoH or DoT ...

> you can be confident that you're having a private conversation with the 
> entity you've decided to trust. That's a pretty big distinction from port 53. 
> Without that assurance its reasonable to be concerned about what names you 
> lookup.
> 
> This of course applies to local and enterprise configs as well as the cloud 
> configs contemplated by most of this thread. An enterprise DoH server

Minor correction: An enterprise DoH and/or DoT server...

> expresses and enforces a policy - if an application needs to use that policy 
> it should be comforted in transport security providing confirmation that it 
> is doing so rather than reading in whatever might be showing up on port 53..

The only point I’m making in the above is there is no meaningful distinction in 
the privacy, security, or server validation between DoH vs DoT.

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 other network policies (regardless of what those policies 
are.)

IMNSHO, if both ports are reachable for a given provider of Do*, the DoT port 
MUST be used. DoH should only be used with explicit informed user consent, and 
only when DoT is unavailable. This supports the “dissident” use case, without 
impacting any other aspects of privacy provided by DoT..

The blocking of DoT to a given provider should be interpreted as an explicit 
policy. Users should be informed that they may, and very likely will, be 
violating someone’s policy, if they choose to use DoH in that circumstance, and 
that they may be violating laws by doing so, and should only do so if they are 
willing to accept that risk.

There is no reason DoH should be used if DoT works (towards the same DNS 
provider).

Brian 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-wessels-dns-zone-digest

[Matthew Pounsett]

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.

>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: New draft for consideration:

[Matthew Pounsett]

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 makes the choice for
>> the
>> > user".
>>
>> The split here is more "someone changes from traditional without the user
>> knowing, when the user cares". If you have a better way to express that,
>> that would be great.
>>
>> > Perhaps we should talk about 'Per-application stubs'? Because this is
>> the
>> > nub.
>>
>> Maybe, but I'm hesitant to make the break that way because some
>> applications' stubs use the traditional resolver, others don't. I would be
>> hesitant to conflate those two.
>>
>
> I don't think the current wording for DaO expresses the same point that
> you've made here.  In particular, mentioning that DaO might refer to a user
> modifying /etc/resolv.conf is inconsistent with the intent that DaO is
> sending queries somewhere other than where the traditional configuration
> says.  /etc/resolv.conf (and its equivalents in non-unix OSes) *are* the
> traditional place to configure that.  Whatever that file says, I think any
> resolver that is consulting that file to find its upstreams is doing DaT.
>
>
> I think we’re at the point where using acronyms is is obscuring the detail
> of what is being described. If and acronym describes a protocol or an
> architectural feature that is unambiguous, great.
>
>
> How about:
>DaO: DNS resolution between a stub resolver and a recursive resolver
> that
>differs from the recursive resolver configured in the traditional
>location(s) for a system.
>
>
> This describes a multitude of systems of varying implementation. It would
> seem for example to include bonjour, a tor client, some vpns and many
> operating system container environments.
>

I may be wrong, but I don't believe bonjour uses RDoT or DoH.

The VPNs you reference are, I think, intended to be covered by the term, so
I think the definition works there.

 I don't think I have an opinion on whether Tor should or shouldn't be
covered by the definition (although others might), so if you wanted to
suggest text that excluded it I think people would consider that.

I don't think container environments are included in the definition either,
because in a container environment the container's resolution path is the
traditional point of configuration for that type of system.  Perhaps the
word "traditional" is too ambiguous, and leads people to think more
"historical" than "typical"?


>
> DaO can be configured by a user changing where a
>stub resolver gets its list of recursive servers, or an application
> running
>RDoT or DoH to a resolver that is not the same as the resolver
> configured
>in the traditional location for the operating system.
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Patrick McManus]

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/achieve host or application configuration.
Indeed - deploying trust anchors to these clients is the only way you're
going to intercept https as the notion of network defined configuration of
"trusted proxies" and the like is consistently rejected by clients. That
seems like the right standard for DNS as well - go ahead and configure a
different policy but do it via an existing authenticated configuration
mechanism like you would use for adding a trust root.

However, rather than adding a root I would suggest that if you're doing
client configuration for network-local DNS policy, that you deploy a DoH
server that enforces that policy and point DoH clients at it through the
various enterprise config mechanisms. It doesn't require any kind of access
that adding a trust root does not. This has the desirable property that the
application can reliably know what server is providing DNS service in a
fully authenticated way. Perhaps in a "my way or the highway" scenario it
will choose the highway. That's fair enough - that should be a real
choice.  When you just intercept 8.8.8.8:53 an informed decision cannot be
made.

Use of non-default trust roots is also a property generally visible to
applications. Most allow it as a matter of user configuration.

-Patrick
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Patrick McManus]

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 their privacy practices needs to be establish some other way (and the
best way we have right now is 'out of band' - hopefully that gets better) -
but with DoH you can be confident that you're having a private conversation
with the entity you've decided to trust. That's a pretty big distinction
from port 53. Without that assurance its reasonable to be concerned about
what names you lookup.

This of course applies to local and enterprise configs as well as the cloud
configs contemplated by most of this thread. An enterprise DoH server
expresses and enforces a policy - if an application needs to use that
policy it should be comforted in transport security providing confirmation
that it is doing so rather than reading in whatever might be showing up on
port 53.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: New draft for consideration:

[Joel Jaeggli]

> 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 here is more "someone changes from traditional without the user 
>> knowing, when the user cares". If you have a better way to express that, 
>> that would be great.
>> 
>> > Perhaps we should talk about 'Per-application stubs'? Because this is the
>> > nub. 
>> 
>> Maybe, but I'm hesitant to make the break that way because some 
>> applications' stubs use the traditional resolver, others don't. I would be 
>> hesitant to conflate those two.
> 
> I don't think the current wording for DaO expresses the same point that 
> you've made here.  In particular, mentioning that DaO might refer to a user 
> modifying /etc/resolv.conf is inconsistent with the intent that DaO is 
> sending queries somewhere other than where the traditional configuration 
> says.  /etc/resolv.conf (and its equivalents in non-unix OSes) *are* the 
> traditional place to configure that.  Whatever that file says, I think any 
> resolver that is consulting that file to find its upstreams is doing DaT.

I think we’re at the point where using acronyms is is obscuring the detail of 
what is being described. If and acronym describes a protocol or an 
architectural feature that is unambiguous, great. 
> 
> How about:
>DaO: DNS resolution between a stub resolver and a recursive resolver that
>differs from the recursive resolver configured in the traditional
>location(s) for a system. 

This describes a multitude of systems of varying implementation. It would seem 
for example to include bonjour, a tor client, some vpns and many operating 
system container environments.

> DaO can be configured by a user changing where a
>stub resolver gets its list of recursive servers, or an application running
>RDoT or DoH to a resolver that is not the same as the resolver configured
>in the traditional location for the operating system.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: New draft for consideration:

[Matthew Pounsett]

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, when the user cares". If you have a better way to express that,
> that would be great.
>
> > Perhaps we should talk about 'Per-application stubs'? Because this is the
> > nub.
>
> Maybe, but I'm hesitant to make the break that way because some
> applications' stubs use the traditional resolver, others don't. I would be
> hesitant to conflate those two.
>

I don't think the current wording for DaO expresses the same point that
you've made here.  In particular, mentioning that DaO might refer to a user
modifying /etc/resolv.conf is inconsistent with the intent that DaO is
sending queries somewhere other than where the traditional configuration
says.  /etc/resolv.conf (and its equivalents in non-unix OSes) *are* the
traditional place to configure that.  Whatever that file says, I think any
resolver that is consulting that file to find its upstreams is doing DaT.

How about:
   DaO: DNS resolution between a stub resolver and a recursive resolver that
   differs from the recursive resolver configured in the traditional
   location(s) for a system.  DaO can be configured by a user changing
where a
   stub resolver gets its list of recursive servers, or an application
running
   RDoT or DoH to a resolver that is not the same as the resolver configured
   in the traditional location for the operating system.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Paul Vixie]

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 DNS transport mechanisms that
our users can use to reach the service. This includes the traditional
UDP and TCP transports as well as DNS-over-TLS and DNS-over-HTTPS that
provide privacy for the user’s communication with a DNS resolver.

-Puneet Sood
TL/Manager for the Google Public DNS team.
this position (for google public dns) is inconsistent with the google 
chrome design description here:


Kenji Baheux wrote on 2019-03-23 22:43:

2) What other reasons are you considering when doing DOH instead of DOT
to protect privacy. >

> We are not considering DOT, just DOH.

this disparity is concerning. for reasons amply described here...


From: Brian Dickson 
Date: Sun, 24 Mar 2019 04:48:27 -0700
Message-ID: 
Archived-At: 



...i remain hopeful that google will adopt a DoT support policy for all 
services (such as Public DNS) _and all products_ (such as Chrome).


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: New draft for consideration:

[Olli Vanhoja]

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 "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 DoH being used to perform
>> > DNS lookups in a different fashion than configured by the network
>> settings
>> > (see DaT and DaO)."
>>
>> A much better outcome would be that people who are saying DoH when they
>> mean DaT or DaO would use the new terms. That is, this is a forward-looking
>> document because we're making up new terms.
>>
>
> 
> This is likely to be an annoying comment, but I don't really like the DaO
> "acronym", simply because I'm not sure how people will pronounce it -- I
> could see people mishearing "DaO" as "DoH", or the other way round --
> unfortunately I don't have a better suggestion. Is it just me who has this
> issue?
>
> 
> W
>
>
>
>>
>> > Secondly, I understand the technical need for the wording of the
>> definition
>> > of DaO.  But I had to read this all a few times before I understood that
>> > 'DaO' includes what I've referred to as DoC (DNS over Cloud). I think
>> > definitions should be easy to understand because otherwise they don't
>> > function.
>>
>> I fully agree; proposed changes to this wording are quite welcome. It's a
>> new term, after all.
>>
>> > 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, when the user cares". If you have a better way to express that,
>> that would be great.
>>
>> > Perhaps we should talk about 'Per-application stubs'? Because this is
>> the
>> > nub.
>>
>> Maybe, but I'm hesitant to make the break that way because some
>> applications' stubs use the traditional resolver, others don't. I would be
>> hesitant to conflate those two.
>>
>> > I'm willing to write text once we have discussed this a bit.
>>
>> Thanks!
>>
>> --Paul Hoffman
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>---maf
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Ray Bellis]

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

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-wessels-dns-zone-digest

[Paul Wouters]

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 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 starts a Call for Adoption for draft-wessels-dns-zone-digest
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/
> 
> 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.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 24 March 2019
> 
> Thanks,
> tim wicinski
> DNSOP co-chair
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] FW: New Version Notification for draft-mglt-dnsop-dnssec-validator-requirements-07.txt

[Daniel Migault]

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 operate DNSSEC validators. In particular, feed backs from
> operators or implementers would be more than welcome. Please feel free to
> share your thoughts on the mailing list, or let me know if there is a time
> slot available to discuss them. Would Monday during the lunch break
> convenient for you ?
>
> Yours,
> Daniel
>
> -- Forwarded message -
> From: Daniel Migault 
> Date: Wed, Nov 28, 2018 at 1:18 PM
> Subject: [DNSOP] FW: New Version Notification for
> draft-mglt-dnsop-dnssec-validator-requirements-07.txt
> To: dnsop 
>
>
> Hi,
>
> Please find an updated version of the DNSSEC validator requirements
> document. The document reflect discussions we had in the Montreal and
> Bangkok meeting.
> In particular we describe the DNSSEC trust model. We suppose that is an
> important piece DNSSEC resolver operators needs to understand.  We reduce
> the number of requirements to remain more aligned with the DNSSEC
> architecture.  Overall the document seems reasonable to us.
>
> Feed backs are always welcome!
>
> Yours,
> Daniel
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Wednesday, November 28, 2018 1:02 PM
> To: Edward Lewis ; Daniel Migault <
> daniel.miga...@ericsson.com>; Dan York 
> Subject: New Version Notification for
> draft-mglt-dnsop-dnssec-validator-requirements-07.txt
>
>
> A new version of I-D, draft-mglt-dnsop-dnssec-validator-requirements-07.txt
> has been successfully submitted by Daniel Migault and posted to the IETF
> repository.
>
> Name:   draft-mglt-dnsop-dnssec-validator-requirements
> Revision:   07
> Title:  DNSSEC Validator Requirements
> Document date:  2018-11-28
> Group:  Individual Submission
> Pages:  17
> URL:
> https://www.ietf.org/internet-drafts/draft-mglt-dnsop-dnssec-validator-requirements-07.txt
> Status:
> https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/
> Htmlized:
> https://tools.ietf.org/html/draft-mglt-dnsop-dnssec-validator-requirements-07
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-mglt-dnsop-dnssec-validator-requirements
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-mglt-dnsop-dnssec-validator-requirements-07
>
> Abstract:
>The DNS Security Extensions define a process for validating received
>data and assert them authentic and complete as opposed to forged.
>
>This document describes what is needed in implementations to make the
>validation process manageable Considerations for accurate time as
>well as management of the trust anchor store.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New draft for consideration:

[Martin Hoffmann]

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
> 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.

I would like to boldly suggest to not or at least not only define
abbreviations but proper names for the more general concepts instead.
The ship has probably sailed for the protocols itself and they will now
forever be DoH and DoT, but maybe we can agree on something more
meaningful such as "traditional [name] resolution" v. "alternative
[name] resolution" for the what the draft calls DaT and DaO.

The reasoning here is that proper terms are less confusing and, if
chosen wisely, can be understood by someone not intimately familiar
with the matter. When speaking, they aren’t much more bothersome than
the abbreviation. Writing will be a bit more work but then again, an
extra layer of clarity can help with avoiding misunderstanding.

I will spare you my aesthetic concerns around camel-case abbreviations.

Kind regards,
Mar*shudder*tin

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[bert hubert]

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 are known not to be shy asserting their IPR.

https://datatracker.ietf.org/ipr/3014/ notes an Akamai IPR claim and does
not yet provide a license suitable for use on an open internet.

https://patents.google.com/patent/US8583801B2/en & 

https://en.wikipedia.org/wiki/Akamai_Techs.,_Inc._v._Limelight_Networks,_Inc.
have some context. 

The mechanics are that once something is an RFC, operators require adherance
to it. This in turn is a boon for the IPR holder, and hurts everyone else.

My secondary objection is that the draft contains an example implementation
that then however uses normative words. This leads to pain with operators
demanding serve-stale compliance. Example algorithms should clearly be
examples and not tell us what we SHOULD do.

Bert

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: New draft for consideration:

[Brian Dickson]

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 browser vendors and cloud
>> > providers is frequently also called 'DoH'. DoH-the-protocol is
>> > therefore frequently conflated with DoH being used to perform
>> > DNS lookups in a different fashion than configured by the network
>> settings
>> > (see DaT and DaO)."
>>
>> A much better outcome would be that people who are saying DoH when they
>> mean DaT or DaO would use the new terms. That is, this is a forward-looking
>> document because we're making up new terms.
>>
>
> 
> This is likely to be an annoying comment, but I don't really like the DaO
> "acronym", simply because I'm not sure how people will pronounce it -- I
> could see people mishearing "DaO" as "DoH", or the other way round --
> unfortunately I don't have a better suggestion. Is it just me who has this
> issue?
>

It probably isn't just you.
Here's a couple of suggestions to maybe canonicalize some of the terms, and
make them easier to distinguish/say:

DoTR (rather than RDoT): DNS over TLS, Recursive
DoTA (rather than ADoT): DNS over TLS, Authoritative. Or, some kind of
online game played by Millennials, presumably. :-)
DoN (rather than DaO): DNS on Nonstandard
DoS (rather than DaT): DNS on Standard. Risks confusion with Denial of
Service, if there is no provided context (but generally context will exist,
so...)

In anticipation of crazy ideas I might bring up, maybe we can agree on
compounding of lower-case "o" usage, with left-to-right meaning
left-encapsulated-in-right.
E,.g, DoTo53 would be "DNS over TLS, carried via some manner of encoding
within the payload of a Do53 message".

Brian


>
> 
> W
>
>
>
>>
>> > Secondly, I understand the technical need for the wording of the
>> definition
>> > of DaO.  But I had to read this all a few times before I understood that
>> > 'DaO' includes what I've referred to as DoC (DNS over Cloud). I think
>> > definitions should be easy to understand because otherwise they don't
>> > function.
>>
>> I fully agree; proposed changes to this wording are quite welcome. It's a
>> new term, after all.
>>
>> > 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, when the user cares". If you have a better way to express that,
>> that would be great.
>>
>> > Perhaps we should talk about 'Per-application stubs'? Because this is
>> the
>> > nub.
>>
>> Maybe, but I'm hesitant to make the break that way because some
>> applications' stubs use the traditional resolver, others don't. I would be
>> hesitant to conflate those two.
>>
>> > I'm willing to write text once we have discussed this a bit.
>>
>> Thanks!
>>
>> --Paul Hoffman
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>---maf
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Concerns around deployment of DNS over HTTPS (DoH)

[Brian Dickson]

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.
>
>
>> Sorry for the delayed question, but with respect to this bullet:
>>
>
>
>
>
>> 1) Do you have evidence that DOH is faster than DOT, since speed was one
>> of your goals?
>>
>
> Speed isn't a primary goal, hence the use of "hopefully". Based on
> Mozilla's early results [1], there is hope that the performance will be
> improved at the high percentiles and remain neutral/acceptable otherwise.
>
>
> [1]
> https://blog.nightly.mozilla.org/2018/08/28/firefox-nightly-secure-dns-experimental-results/
>
>
>
>
>> 2) What other reasons are you considering when doing DOH instead of DOT
>> to protect privacy.
>
>
> We are not considering DOT, just DOH.
>

I sincerely hope you reconsider this position.

See below on a variety of factors on why DoT >> DoH, for enterprise
use/deployment(s).

The concerns that have been raised about blocking DoT are, IMHO, somewhat
"red herrings".
The specific blocking scenarios are likely to be "block all DoT EXCEPT this
specific set of DoT servers", which is not the same as "blocking DoT". In
particular, it does not downgrade to Do53.

However, it is much more likely, at least in enterprises (especially in
data centers or in multiple security zones) that DoH will be blocked
entirely, while DoT will be restricted (but not blocked).


>
> I believe that there has been many discussions in the past that offered
> reasons why a browser / ... would naturally prefer DoH over DoT.
>
> I don't think I have anything to add that would sway the debate in way or
> another. In fact, I think it's fair to say that the debate is unlikely to
> come to an end anytime soon.
>
> Instead, I imagine it would be more effective to focus on specific
> scenarios: who are the actors, what do they want or accept/understand, is
> the scenario reasonable to all parties involved, what can they do, etc.
>
>
>
Let me give some specific examples of actors, including DNS operators, DNS
software maintainers, malware and other bad actors (with very specific
examples), and CIO/CISO types.

DNS operators (i.e. those operating recursive dns resolvers) generally have
specific existing environments, consisting of selected DNS software
vendor(s), DNS configurations, plus additional DNS-related components.
Changing software vendors is not something done lightly, and generally
requires compelling reasons. Many aspects of DNS configurations do not work
the same, or at all, if vendors are switched.

DNS operations frequently entails a number of additional elements,
including policies for resolution (white lists, black lists, dynamic
white/black lists), security-zone specific configuration elements
(typically maintained with automation tools), logging, inspection,
alerting, and active mitigations (such as RPZ).

DNS operations may involve combinations of caching, recursive resolution,
forwarding, including on a "split-brain" server, and sometimes integrated
authoritative service for a configured set of zones (typically via AXFR
secondary).

The existing mostly-UDP nature of Do53 is problematic for traffic that
crosses security boundaries, specifically because of the stateless nature
of UDP, and the ability of spoofing source addresses. DoT improves this
aspect of DNS operations considerably.

The incremental development of DoT, compared to Do53, is relatively minor,
and from a software perspective, very constrained in the additional code,
pathways, and ability to inspect/audit the changes to the software. This is
especially true when the same software packages are used, with the DoT
being essentially an upgrade. Upgrade/downgrade of software used by DNS
operators means configuration files, zone files, etc., don't require
modification, limiting the impact of requirements to perform roll-backs if
needed.

DNS operators in enterprises often are required to support multiple
environments, including end-users with a large variety of COTS (commercial
off the shelf) equipment, including multiple form factors (desktops,
laptops, tablets, mobile devices), multiple vendors, multiple OS (even
within vendors), multiple applications (everything from OS stub resolvers,
to mail packages, to browsers, to VPN software, to third party
applications), across possibly large ranges of major and minor versions.

The support for multiple environments of greatly simplified, if the same
DNS software packages can be used in multiple environments, including using
a small number of shared caching resolvers (each with their own security
profiles, configurations, etc.).

The operations and support issues strongly lends itself to use of DoT for
inter-security zone resolution, and for shared use across apps/OS/etc which
have DoT enabled and configured. The use of DoT 

Re: [DNSOP] [Ext] Re: New draft for consideration:

[Warren Kumari]

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 'DoH'. DoH-the-protocol is
> > therefore frequently conflated with DoH being used to perform
> > DNS lookups in a different fashion than configured by the network
> settings
> > (see DaT and DaO)."
>
> A much better outcome would be that people who are saying DoH when they
> mean DaT or DaO would use the new terms. That is, this is a forward-looking
> document because we're making up new terms.
>


This is likely to be an annoying comment, but I don't really like the DaO
"acronym", simply because I'm not sure how people will pronounce it -- I
could see people mishearing "DaO" as "DoH", or the other way round --
unfortunately I don't have a better suggestion. Is it just me who has this
issue?


W



>
> > Secondly, I understand the technical need for the wording of the
> definition
> > of DaO.  But I had to read this all a few times before I understood that
> > 'DaO' includes what I've referred to as DoC (DNS over Cloud). I think
> > definitions should be easy to understand because otherwise they don't
> > function.
>
> I fully agree; proposed changes to this wording are quite welcome. It's a
> new term, after all.
>
> > 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, when the user cares". If you have a better way to express that,
> that would be great.
>
> > Perhaps we should talk about 'Per-application stubs'? Because this is the
> > nub.
>
> Maybe, but I'm hesitant to make the break that way because some
> applications' stubs use the traditional resolver, others don't. I would be
> hesitant to conflate those two.
>
> > I'm willing to write text once we have discussed this a bit.
>
> Thanks!
>
> --Paul Hoffman
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Paul Vixie]

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. Delegation Revalidation Upon NS RRSet Expiry

   2.1. Because the delegating NS RRset at the bottom of the parent zone
   and the apex NS RRset in the child zone are unsynchronized, the TTL
   of the parent's delegating NS RRset is meaningless. A child zone's
   apex NS RRset is authoritative and thus has a higher cache
   credibility than the parent's delegating NS RRset, so, the NS RRset
   "below the cut" immediately replaces the parent's delegating NS RRset
   in cache when an iterative caching DNS resolver crosses a zone cut.

   2.2. The lowest TTL found in a parent zone's delegating NS RRset
   should be stored in the cache and used to trigger delegation
   revalidation as follows.  Whenever a cached RRset is being considered
   for use in a response, the cache should be walked upward toward the
   root, looking for expired delegations. At the first expired
   delegation encountered while walking upward toward the root,
   revalidation should be triggered, putting the processing of dependent
   queries on hold until validation is complete.

   2.3. To revalidate a delegation, the iterative caching DNS resolver
   will forward the query that triggered revalidation to the nameservers
   at the closest enclosing zone cut above the revalidation point. While
   searching for these nameservers, additional revalidations may occur,
   perhaps placing an entire chain of dependent queries on hold,
   unwinding in downward order as revalidations closer to the root must
   be complete before revalidations further from the root can begin.

   2.4. If a delegation can be revalidated at the same node, then the
   old apex NS RRset should be deleted from cache and then the new
   delegating NS RRset should be stored in cache. The minimum TTL from
   the new delegating NS RRset should also be stored in cache to
   facilitate future revalidations. This order of operations ensures
   that the RRset credibility rules do not prevent the new delegating NS
   RRset from entering the cache. It is expected that the child's apex
   NS RRset will rapidly replace the parent's delegating NS RRset as
   soon as iteration restarts after the revalidation event.

   2.5. If the new delegating NS RRset cannot be found (RCODE=NXDOMAIN)
   or if there is a new zone cut at some different level of the
   hierarchy (insertion or deletion of a delegation point above the
   revalidation point) or if the new RRset shares no nameserver names in
   common with the old one (indicating some kind of redelegation, which
   is rare) then the cache should be purged of all names and RRsets at
   or below the revalidation point. This facilitates redelegation or
   revocation of a zone by a parent zone administrator, and also
   conserves cache storage by deleting unreachable data.

   2.6. To make the timing of a revalidation event unpredictable from
   the point of view of a potential cache-spoof attacker, the parent's
   delegating NS RRset TTL should be reduced by a random fraction of its
   value before being stored for use in revalidation activities.


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.


vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Feedback on extended error from the IETF hackathon

[Shane Kerr]

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 to encode the 
INFO-CODE into the 12 bits allocated to it. I think that the idea is 
that it should be represented in network (MSB) order, but probably it 
should be specified.




Minor suggestion: text for the descriptions should be consistent 
regarding capitalization. So:


* Forged answer -> Forged Answer
* DNSKEY missing -> DNSKEY Missing
* RRSIGs missing -> RRSIGs Missing



For some reason NXDOMAIN(3)-specific codes are listed after 
NOTIMP(4)-specific and REFUSED(5)-specific codes in the draft. I think 
it would make more sense to just include these in order.




Numbering is a bit weird in section 4.1.3:

4.1.3.  INFO-CODEs for use with RESPONSE-CODE: NOERROR(3)
4.1.3.1.  NOERROR Extended DNS Error Code 3 - Stale Answer

Probably the idea is just to have:

4.1.3. NOERROR Extended DNS Error Code 3 - Stale Answer



   RESPONSE-CODE:  3 (NOERROR)
   INFO-CODE:  3
   Purpose:  Answering with stale/cached data
   Reference:  Section 4.1.3.1
-> should be RESPONSE-CODE 0



   RESPONSE-CODE:  2 (SERVFAIL)
   INFO-CODE:  7
   Purpose:  No NSEC records could be obtained
   Reference:  Section 4.2.8
-> should be "No Reachable Authority", 4.2.7



This code is missing in the table:

   RESPONSE-CODE:  2 (SERVFAIL)
   INFO-CODE:  8
   Purpose:  No NSEC records could be obtained
   Reference:  Section 4.2.8



   RESPONSE-CODE:  4 (NOTIMP)
   INFO-CODE:  1
   Purpose:
   Reference:  Section 4.4.2
-> should be "Deprecated"



Finally, I note that the suggestion of requiring that the sender have 
some signal indicating that it is interested in extended errors was not 
adopted. I don't insist on it, but I think it would be useful to avoid 
bloating packets unnecessarily. It's a bit like the useless additional 
section data that lots of servers insist on appending to answers... why 
send something that will not be seen?


OTOH I realize that having this information available may be useful for 
humans debugging things, even if the sender does not ask for it.


On the gripping hand, adding unasked-for information may have privacy 
implications. Possibly adding a "Privacy Considerations" section would 
be useful?


https://tools.ietf.org/html/rfc6973#section-7

Cheers,

--
Shane

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-05.txt

[Stephane Bortzmeyer]

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
>   Wes Hardaker
>   David C Lawrence
>   Filename: draft-ietf-dnsop-extended-error-05.txt

At the IETF 104 hackathon in Prague, Vladimír Čunát and myself
implemented it in the Knot resolver
. You can see the result in the git
merge request

(branch extended_error
).

> 4.1.5.  SERVFAIL Extended DNS Error Code 5 - DNSSEC Indeterminate
>   The resolver attempted to perform DNSSEC validation, but validation
>   ended in the Indeterminate state.  The R flag should not be set.

Isn't there an error here? 4.1 is the section for NOERROR. What
should be returned for DNSSEC Indeterminate? NOERROR or SERVFAIL? (In
the first case, change the text, in the second, move this paragraph to
4.2.)

Now, implementation experience. We tested with Wireshark and dig (did
not try to develop a client using the extended error code, just the server).

As expected, producing extended error codes is quite simple and the
draft is clear. The camel will be happy.

The biggest issue is of course to find out what to put in the extended
error code. On some resolvers (at least on Knot), the place where the
error is noticed can be quite far from the place where the answer is
built, with its EDNS options. In practice, we had to add data to the
request object, for the extended error information to be carried to
the module that emits the extended error code EDNS option. So, the
real difficulty is not in the draft, but in knowing and understanding
your resolver.

Some details:

* no resolver will use all the response-code/info-codes because some
are never reached for this resolver, or are mixed with other
issues. Generic errors (such as "SERVFAIL Extended DNS Error Code 1 -
DNSSEC Bogus") are useful for when you cannot reliably find the problem.

* the draft is silent about the laying out of bits in info-code. Not
many IETF protocols have an integer field which is larger than a byte
but not byte-aligned.

* the draft has a passing mention that multiple extended error options
are allowed but I don't see how it could be used by the poor client
trying to figure out what happened. I suggest to disallow it.

* the draft has (rightly so) two info-codes for NXDOMAIN/Blocked and
NXDOMAIN/Censored but Knot cannot use it currently since the policy
module (written in Lua) has no way today to be configured to express
the difference. Not a problem in the draft but it will be probably a
common case that the resolver cannot make use of *all* codes.

Let's end with a few examples:

4.2.2.  SERVFAIL Extended DNS Error Code 2 - Signature Expired

% dig  @::1 -p 9053 A servfail.nl 
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12100
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; OPT=65500: 00 00 20 02 44 4e 53 53 45 43 20 65 78 70 69 72 65 64 20 73 69 67 
6e 61 74 75 72 65 73 (".. .DNSSEC expired signatures")
...


4.2.7.  SERVFAIL Extended DNS Error Code 7 - No Reachable Authority

% dig  @::1 -p 9053 A brk.internautique.fr
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38620
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; OPT=65500: 80 00 20 07 6e 6f 20 4e 53 20 77 69 74 68 20 61 6e 20 61 64 64 72 
65 73 73 (".. .no NS with an address")
...

(Not an ideal message but this is quite generic code in Knot.)


4.5.1.  NXDOMAIN Extended DNS Error Code 1 - Blocked

% dig  @::1 -p 9053 A googleanalytics.com 
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1189
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; OPT=65500: 80 00 30 01 4e 6f 20 74 72 61 63 6b 69 6e 67 ("..0.No tracking")
;; QUESTION SECTION:
;googleanalytics.com.   IN A

;; AUTHORITY SECTION:
googleanalytics.com.10800 IN SOA googleanalytics.com. nobody.invalid. (
1  ; serial
3600   ; refresh (1 hour)
1200   ; retry (20 minutes)
604800 ; expire (1 week)
10800  ; minimum (3 hours)
)

;; ADDITIONAL SECTION:
explanation.invalid.10800 IN TXT "No tracking"



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Benno Overeinder]

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 guidance of a recent attempt being
> made.  If that is not the case, and you can get stale answers from
> Unbound even without a recent refresh attempt, then I personally think
> that is an error in Unbound and not this document.

The current implementation of serve stale in Unbound is closely related
with the pre-fetching process.  It works well for most cases, that is
names that are frequently queried for, so the pre-fetch assures for
fresh and correct entries in the cache.

For names with relative short TTLs and that are not frequently queried
for (i.e. less frequent than covered by the TTL), the entry from the
cache is stale and only after serving the reply, a pre-fetch (resolve)
is initiated to update/re-fresh the entry in the cache.

We acknowledge this behavior is not optimal in some situations and will
reimplement a part of the re-fresh strategy of cache entries.

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: New draft for consideration:

[Paul Hoffman]

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 DoH being used to perform
> DNS lookups in a different fashion than configured by the network settings
> (see DaT and DaO)."

A much better outcome would be that people who are saying DoH when they mean 
DaT or DaO would use the new terms. That is, this is a forward-looking document 
because we're making up new terms.

> Secondly, I understand the technical need for the wording of the definition
> of DaO.  But I had to read this all a few times before I understood that
> 'DaO' includes what I've referred to as DoC (DNS over Cloud). I think
> definitions should be easy to understand because otherwise they don't
> function.

I fully agree; proposed changes to this wording are quite welcome. It's a new 
term, after all.

> 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, when the user cares". If you have a better way to express that, that 
would be great.

> Perhaps we should talk about 'Per-application stubs'? Because this is the
> nub. 

Maybe, but I'm hesitant to make the break that way because some applications' 
stubs use the traditional resolver, others don't. I would be hesitant to 
conflate those two.

> I'm willing to write text once we have discussed this a bit.

Thanks!

--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-wessels-dns-zone-digest

[Brian Dickson]

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 starts a Call for Adoption for draft-wessels-dns-zone-digest
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/
>
> 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 am in favor of adoption of this draft by DNSOP WG.


> Please also indicate if you are willing to contribute text, review, etc.
>

I am willing to review and contribute text.

Brian Dickson


>
> This call for adoption ends: 24 March 2019
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New draft for consideration:

[bert hubert]

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 for this, and I have understood the note that the draft is early
and the words will likely improve. 

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 DoH being used to perform
DNS lookups in a different fashion than configured by the network settings
(see DaT and DaO)."

Secondly, I understand the technical need for the wording of the definition
of DaO.  But I had to read this all a few times before I understood that
'DaO' includes what I've referred to as DoC (DNS over Cloud). I think
definitions should be easy to understand because otherwise they don't
function.

I'm also not too hot for conflating "user consciously changes
/etc/resolv.conf or equivalent" with "application makes the choice for the
user". 

Perhaps we should talk about 'Per-application stubs'? Because this is the
nub. 

I'm willing to write text once we have discussed this a bit.

Bert


> 
> --Paul Hoffman
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> Title   : Abbreviations for DNS Transports and Location
> Author  : Paul Hoffman
>   Filename: draft-hoffman-dns-terminology-ter-00.txt
>   Pages   : 3
>   Date: 2019-03-23
> 
> Abstract:
>This document adds abbreviations to "DNS Terminology" (RFC 8499) that
>relate to DNS running over various transports, as well as
>abbreviations for DNS resolution at traditional and non-traditional
>locations.
> 
>[[ This is an early attempt at these terms.  They will probably be
>improved over time. []
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology-ter/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-hoffman-dns-terminology-ter-00
> https://datatracker.ietf.org/doc/html/draft-hoffman-dns-terminology-ter-00
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-wessels-dns-zone-digest

[Joe Abley]

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 text, review, etc.

I am willing to do all of those things.

> This call for adoption ends: 24 March 2019


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New draft for consideration:

[Tim Wicinski]

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:

> 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 in these discussions. The draft below, if adopted by the DNSOP WG,
> would update RFC 8499 with a small set of abbreviations.
>
> --Paul Hoffman
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title   : Abbreviations for DNS Transports and Location
> Author  : Paul Hoffman
> Filename: draft-hoffman-dns-terminology-ter-00.txt
> Pages   : 3
> Date: 2019-03-23
>
> Abstract:
>This document adds abbreviations to "DNS Terminology" (RFC 8499) that
>relate to DNS running over various transports, as well as
>abbreviations for DNS resolution at traditional and non-traditional
>locations.
>
>[[ This is an early attempt at these terms.  They will probably be
>improved over time. []
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology-ter/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-hoffman-dns-terminology-ter-00
> https://datatracker.ietf.org/doc/html/draft-hoffman-dns-terminology-ter-00
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] The DNSOP WG has placed draft-hoffman-dns-terminology-ter in state "Candidate for WG Adoption"

[IETF Secretariat]

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.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] New draft for consideration:

[Paul Hoffman]

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 in these 
discussions. The draft below, if adopted by the DNSOP WG, would update RFC 8499 
with a small set of abbreviations.

--Paul Hoffman

A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Abbreviations for DNS Transports and Location
Author  : Paul Hoffman
Filename: draft-hoffman-dns-terminology-ter-00.txt
Pages   : 3
Date: 2019-03-23

Abstract:
   This document adds abbreviations to "DNS Terminology" (RFC 8499) that
   relate to DNS running over various transports, as well as
   abbreviations for DNS resolution at traditional and non-traditional
   locations.

   [[ This is an early attempt at these terms.  They will probably be
   improved over time. []


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology-ter/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-hoffman-dns-terminology-ter-00
https://datatracker.ietf.org/doc/html/draft-hoffman-dns-terminology-ter-00

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] I-D Action: draft-ietf-dnsop-rfc7816bis-02.txt

[internet-drafts]

A New Internet-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   : DNS Query Name Minimisation to Improve Privacy
Authors : Stephane Bortzmeyer
  Paul Hoffman
Filename: draft-ietf-dnsop-rfc7816bis-02.txt
Pages   : 13
Date: 2019-03-23

Abstract:
   This document describes techniques called "QNAME minimisation" to
   improve DNS privacy, where the DNS resolver no longer always sends
   the full original QNAME to the upstream name server.  This document
   obsoletes RFC 7816.

   This document is part of the IETF DNSOP (DNS Operations) Working
   Group.  The source of the document, as well as a list of open issues,
   is at 

   NOTE FOR THE DNSOP WORKING GROUP: There is still much work to be done
   in this draft.  Future versions of this draft will contain
   descriptions of different minimisation implementation choices that
   have been made since the RFC 7816 first came out, as well as
   deployment experience.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-rfc7816bis-02
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc7816bis-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc7816bis-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop