Subject: [dns-privacy] Threat Model

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Nov 2019 11:09:56 -0700

It seemed like it might be a good idea to take a step back and talk
about threat model to see if we're all on the same page.

The set of threats I am concerned with is primarily about an on-path
active attacker who learns the query stream (i.e., the domains being
queried) coming out of the recursive resolver. It's of course mostly
inevitable that the attacker learns which authoritative servers are
being queried, but I think we can all agree there's still plenty of
information to leak here [0].

In the current DNS, such an attacker can of course just perform a
passive attack by listening to the DNS query traffic. It's possible to
straightforwardly exclude this attack by opportunistically attempting
DoT [1] to the authoritative. However, an active attacker can mount a
downgrade attack on the negotiation, forcing you back to
cleartext. So, unless you have a secure way of:

(1) knowing the expected name of the authoritative for a given query
    and that it supports DoT
(2) verifying that the server you are connecting to actually has
    that name

Then the attacker can just mount a MITM attack on your connections and
collect this data by proxying the traffic to the true authoritative.

Do people agree with this assessment of the situation? Is this form
of attack something they agree should be in scope?

-Ekr

[0] There are of course also integrity issues here, but (1) those
are addressed by DNSSEC and (2) if you solved the active attack
problem, that would provide some measure of integrity for the data.

[1] Or any secure transport such as DoH, DoQ, tcpcrypt, etc.
but given the focus of this group, I'll just say DoT.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 1 Nov 2019 12:40:30 -0700

> of attack something they agree should be in scope?

I would think so, yes.

I am also concerned with attackers "on the side". They too might try to
downgrade the connections from ADOT to clear text. But yes, that should
be the general concern: preventing both downgrade attacks and MITM attacks.

-- Christian Huitema

---

From: Brian Dickson <[email-masked]>
Date: Fri, 1 Nov 2019 14:54:21 -0500

> information to leak here [0].

This is where IMHO there is a major distinction between the C2R and R2A
query streams and respective privacy metrics.

C2R traffic is always PII, since the client ID (IP address) and query are
combined (literally) in the query and answer.
(NB: the proposal for "oblivious DNS" is an interesting approach that
decouples those in such a way that the resolver itself no longer has that
PII.)

There are two related considerations:

   - Does the attacker has access to timing data (source/dest IP plus port
   number indicating that DNS is being queried), even if the C2R traffic is
   encrypted?
   - How frequently has a query previously been seen (possibly "never", to
   "only from one client", to "frequently and widely seen")?

If the attacker does not have access to the timing data, IMHO the R2A
queries expose no PII, since the query data cannot be associated with an
originating client.
In this case, an on-path active attacker isn't actually a threat (!!).

If the attacker does have access to the timing data (or raw query data),
then the details of the second question come into play, including when and
how the resolver performs queries.

Here are possibilities that I can think of (which might not cover all
possibilities, everyone is welcome to add to this list):

   1. First query ever, never been cached. Must obtain from authority in
   response to new query.
   2. Only queried once, about to expire (TTL), can be preemptively
   obtained to keep the cache full.
   3. Queried multiple times by a single client, about to expire (TTL), can
   be preemptively obtained to keep the cache full.
   4. Only queried once, expired. Must obtain from authority in response to
   new query.
   5. Queried multiple times by a single client, expired. Must be obtained
   from authority in response to new query.
   6. Queried multiple times by multiple clients, about to expire (TTL),
   can be preemptively obtained to keep cache full.
   7. Queried multiple times by multiple clients, expired. Must be obtained
   from authority in response to new query.

Case #1 is obviously a rather unique case. It will always leak information.
The other 6 cases are pairs with the same semantic on the three cases that
differ only in numbers of queries and numbers of clients.
The following apply to all 3 of those pairs:
If the cache entry is allowed to expire, the next query would necessarily
leak information, as it becomes effectively a degenerate version of case #1.
If the cache entry is not allowed to expire (by preemptively doing a query
to keep the cache fresh), there might not be an association between the
query traffic (C2R) and the cache refresh traffic (R2A).
I.e. there might not be any information leak.

I believe it is the case that:

   1. If no cache entry exists and the R2A query is encrypted, there is no
   leakage. (Required for case #1, or TTL expiry every occurs).
   2. If a particular cache entry that has not been sent in the clear
   previously, and is refreshed before TTL expires, no information leak
   occurs, and it can continue to be treated as if it has never been sent in
   the clear.
   3. Only if a query has never been seen, or the TTL expires, AND the next
   query resulting in R2A is sent in the clear, does information leak.

If this strategy is used, this creates an interesting side effect.
On a busy enough resolver, the regular cache refresh traffic may be
significant enough to negatively impact timing attacks against encrypted
C2R traffic in determing IP/QNAME matches, even if port 853 is blocked and
all traffic is on port 53.

> collect this data by proxying the traffic to the true authoritative.

This MITM attack method would work, and should be protected against, in
response to downgrade attacks against traffic that would otherwise leak
information.

This risk needs to be given context, specifically where are the client, the
recursive, and authoritative, and whether an attacker is able to block port
853 to cause the downgrade?
The current passive attack does not require the attacker to expose her
existence, while port blocking reveals the existence (if not the identity)
of the attacker.

Clearly there are places where such attackers are well known and
unavoidable.
The scenarios to consider include when the R2A connection is not in such an
environment, but the C2R is, and when the R2A is in such an environment but
the C2R is not, and when both connections are (even if any one of the hosts
is not in that environment).

> of attack something they agree should be in scope?

Modulo the nuances enumerated above, I think it is necessary to analyze the
attacks to determine requirements, and to evaluate the design(s) being
proposed to validate their ability to resist the attacks (as well as
expected costs).

Brian

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 1 Nov 2019 14:27:14 -0700

(cutting a good bit)

> queries expose no PII, since the query data cannot be associated with an

In the cases where EDNS Client Subnet is used, it does seem to associate
the query with a pool of potential clients even when there is no timing
data; depending on the size of that pool, this could easily represent a
loss of privacy.

> In this case, an on-path active attacker isn't actually a threat (!!).
Even without EDNS Client subnet, the active attacker now has access to new
targeting data.  Let us say that the active attacker sits in front of
vlogsite.example.  If the attacker sees a query for
free-disputed-territory.vlogsite.example, the information that specific
recursives are seeing that traffic may be of interest to one or more of the
parties disputing the territory.

If this strategy is used, this creates an interesting side effect.  On a
> busy enough resolver, the regular cache refresh traffic may be significant
> enough to negatively impact timing attacks against encrypted C2R traffic in
> determing IP/QNAME matches, even if port 853 is blocked and all traffic is
> on port 53.
>

This is similar to the logic this working group used to conclude that doing
the client-to-recursive first was the right choice.  I don't think the fact
that it is still true when port 853 is blocked refutes the advantages of
encrypting recursive to authoritative traffic.

> existence, while port blocking reveals the existence (if not the identity)

I think Eric's point is different from a standard downgrade by port
blocking.  If the attacker is on path and there is no authentication of the
authoritative server, then a back-to-back user agent can be used to
eavesdrop on the query traffic.  Your recursive makes a TLS connection to
the attacker and sends a query; the attacker reads it and retrieves the
answer from the authoritative server in order to provide you a reply.
You get the right answer (and can even use DNSSEC to check it), but the
query stream still leaked to the attacker.  This is an active attack
(because the attacker terminates the TLS connection and starts a new
outbound connection), but the result is equivalent to what a passive
attacker would get from port 53 data.

regards,

Ted

---

From: Brian Dickson <[email-masked]>
Date: Fri, 1 Nov 2019 18:27:53 -0500

Sent from my iPhone

> On Nov 1, 2019, at 4:27 PM, Ted Hardie <[email-masked]> wrote:
> 
> 
> (cutting a good bit)
> 
>> On Fri, Nov 1, 2019 at 12:54 PM Brian Dickson <[email-masked]> wrote:
>> 
>> 
>> If the attacker does not have access to the timing data, IMHO the R2A queries expose no PII, since the query data cannot be associated with an originating client.
> 
> In the cases where EDNS Client Subnet is used, it does seem to associate the query with a pool of potential clients even when there is no timing data; depending on the size of that pool, this could easily represent a loss of privacy.

Yes, ECS adds a whole extra dimension to the problem space. The particular issue arises entirely due to the source of the need for ECS.

It is an additional argument against centralization, at least from the perspective of comparing no-ECS to ECS. I think this was already telegraphed by Mozilla’s TRR requiring encryption to auth for use of ECS.

The degree of information leakage is probably some function of the granularity of ECS prefixes and the number of active clients on each ECS subnet, on a per name basis.

> Even without EDNS Client subnet, the active attacker now has access to new targeting data.  Let us say that the active attacker sits in front of vlogsite.example.  If the attacker sees a query for free-disputed-territory.vlogsite.example, the information that specific recursives are seeing that traffic may be of interest to one or more of the parties disputing the territory.

I think you mean the attacker sits in front of the nameserver for vlogsite.example?

Maybe, but that prerequisite location is relative to the recursive and authoritative. In some cases, that may be a tautology (recursive is inside a given region, where all traffic exiting is known to be monitored, and the authoritative is outside). There may not be a privacy solution available at all, or not legally permitted.

I don’t doubt the interest of the attacker. I question whether additional DNS protocol stuff to address that specific issue has value if the eventual data traffic isn’t equally protected from detection (eg SNI), or whether that particular problem might be addressed better with a non-DNS-only solution.

>  
> 
>> If this strategy is used, this creates an interesting side effect.  On a busy enough resolver, the regular cache refresh traffic may be significant enough to negatively impact timing attacks against encrypted C2R traffic in determing IP/QNAME matches, even if port 853 is blocked and all traffic is on port 53.
> 
> 
> This is similar to the logic this working group used to conclude that doing the client-to-recursive first was the right choice.  I don't think the fact that it is still true when port 853 is blocked refutes the advantages of encrypting recursive to authoritative traffic.
> 

Me neither. The point was more about the fact that an active attacker needs to reveal her existence, and the above assertion was that the attacker’s goal would not be guaranteed (and thus affecting the risk/reward math, possibly enough to discourage the attempt).

> 
>> This risk needs to be given context, specifically where are the client, the recursive, and authoritative, and whether an attacker is able to block port 853 to cause the downgrade?
>> The current passive attack does not require the attacker to expose her existence, while port blocking reveals the existence (if not the identity) of the attacker.
> 
> I think Eric's point is different from a standard downgrade by port blocking.  If the attacker is on path and there is no authentication of the authoritative server, then a back-to-back user agent can be used to eavesdrop on the query traffic.  Your recursive makes a TLS connection to the attacker and sends a query; the attacker reads it and retrieves the answer from the authoritative server in order to provide you a reply.    You get the right answer (and can even use DNSSEC to check it), but the query stream still leaked to the attacker.  This is an active attack (because the attacker terminates the TLS connection and starts a new outbound connection), but the result is equivalent to what a passive attacker would get from port 53 data.

Yes. So doing DoT without DNSSEC to protect against name tampering could allow an active attacker to MITM.

That point should be part of the operational recommendations: sign the name and addresses and ideally use TLSA.
(It also puts similar requirements on resolvers to validate the same data).

Regards,
Brian

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 2 Nov 2019 13:01:31 +0000

> of attack something they agree should be in scope?

This is one threat model, definitely. Another is passive snooping, such by someone who is watching at a point on the resolver's upstream connection to interesting authoritative servers. Another is passive snooping, such by someone who is watching at a point near interesting authoritative servers.

One small modification I would make to your mode is to change #1 from "knowing the expected name of the authoritative" to "knowing an expected identifier of the authoritative", and #2 to "...actually has that identifier". Given the current landscape of resolvers and authoritative servers, using long-lived IP addresses for identification might be better; that would need to be hashed out during protocol discussion.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Nov 2019 06:58:48 -0700

On Sat, Nov 2, 2019 at 6:01 AM Paul Hoffman <[email-masked]> wrote:

> This is one threat model, definitely. Another is passive snooping, such by
> someone who is watching at a point on the resolver's upstream connection to
> interesting authoritative servers. Another is passive snooping, such by
> someone who is watching at a point near interesting authoritative servers.
>

Generally, I would expect that a solution which addressed the active threat
model would also address the passive one.

> One small modification I would make to your mode is to change #1 from
> "knowing the expected name of the authoritative" to "knowing an expected
> identifier of the authoritative", and #2 to "...actually has that
> identifier". Given the current landscape of resolvers and authoritative
> servers, using long-lived IP addresses for identification might be better;
> that would need to be hashed out during protocol discussion.
>

Sure. Let's say "identity"

=Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 2 Nov 2019 14:03:18 +0000

On 11/2/19 9:58 AM, Eric Rescorla wrote:
> Generally, I would expect that a solution which addressed the active threat model would also address the passive one.

Of course, but there are many threat models that have different solutions. The passive threat models might be addressable more quickly than the active threat model.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Nov 2019 11:33:04 -0700

On Sat, Nov 2, 2019 at 7:03 AM Paul Hoffman <[email-masked]> wrote:

> > Generally, I would expect that a solution which addressed the active
> threat model would also address the passive one.
>
> Of course, but there are many threat models that have different solutions.
> The passive threat models might be addressable more quickly than the active
> threat model.
>

Yes, that's why I asked the question of whether we are trying to solve the
active attacker case.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 2 Nov 2019 18:52:36 +0000

Hiya,

> Yes, that's why I asked the question of whether we are trying to solve the

Tackling passive and active attacks are not mutually
exclusive goals.

Experience from SMTP/TLS (as I interpret it anyway)
was that defence against active attacks only really
became tractable a few years after mitigations against
passive attacks had been deployed and clearly hadn't
broken anything. Note that that transition did not require any changes
to SMTP/TLS, though it may have needed
the mail equivalent of HSTS and reporting to have been
defined (it's hard to tell what really motivated folks
to try mitigate active attacks for sure).

Whether or not adot is sufficiently similar is (for me)
an unknown at this point but I'd hope we don't rule that
out.

ISTM that requiring day-1 defence against active attacks was to an
extent responsible for the lack of deployment
of IPsec and DNSSEC, so I hope we keep an eye on that
ball too.

Cheers,
S.

PS: In saying the above, I do ack that a bunch of people
that I respect a lot totally disagree with the whole
idea of opportunistic security (cf. RFC7435). What I
suggest is that we not regurgitate that debate, but just
bear in mind that any of us can be wrong, especially
when we're arguing about foundational stuff that may
really be based on hunches:-)

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Nov 2019 12:58:39 -0700

> Tackling passive and active attacks are not mutually

Nor did I say they were.

> an unknown at this point but I'd hope we don't rule that

I think the primary difference between this case and the TLS case,
where, as I note below, defense against active attacks was required from
the beginning, is the question of whether or not the reference that
the initiator has tells it that it supposed to expect security. In the case
of TLS you have that with the different URI scheme (https) but in
the case of email you do not.

Conversely, what made opportunistic style approaches viable for
SMTP was that there was an existing protocol handshake that
could be conveniently adopted to have upward negotiation (STARTTLS).
This was more of a pain with HTTP, though RFC 2817 does in fact
specify something.

In this case, I think the relevant question is whether there is some
viable mechanism (by which I mean one that people might actually
use) by which recursive resolvers would, in talking to an authoritative
resolver, detect that that resolver supported secure transport and
upgrade. If there is, then it's potentially possible to have some kind
of opportunistic approach. And conversely, whether it's viable
to have the records that point you to the next authoritative convey
that you should expect security. If there is, then it's potentially
possible/better to have a non-opportunistic approach

> of IPsec and DNSSEC,

I don't understand what DNSSEC would do if not defend against active
attack.

so I hope we keep an eye on that
> ball too.

OTOH, TLS had day one defense against active attacks.

-Ekr

---

From: "John Levine" <[email-masked]>
Date: 2 Nov 2019 19:47:08 -0400

In article <CABcZeBOBFFi=[email-masked]> you write:
>could be conveniently adopted to have upward negotiation (STARTTLS). ...

>upgrade.

It's easy enough to imagine an EDNS option that asks whether a server
supports ADoT, that the client can use as a signal to try again on
port 853.  This is roughly the same amount of traffic as using
STARTTLS in SMTP, but I have no idea whether the DNS crowd would think
it's OK, or too horribly slow, or we're not interested because you can
fake it out and force downgrades.  (SMTP also has that last problem,
of course, at least until MTA-STS and/or signed TLSA.)

R's,
John

PS: there's always dnscurve

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Nov 2019 17:02:24 -0700

On Sat, Nov 2, 2019 at 4:47 PM John Levine <[email-masked]> wrote:

> In article <CABcZeBOBFFi=
> [email-masked]> you write:
> port 853.

Sure. One reason you might be sad about this is that it has an extra round
trip.

> PS: there's always dnscurve

Sure. Dnscurve is a variant of the "have a secure reference" approach.

-Ekr

---

From: Warren Kumari <[email-masked]>
Date: Sat, 2 Nov 2019 21:01:27 -0400

On Sat, Nov 2, 2019 at 3:59 PM Eric Rescorla <[email-masked]> wrote:
>
>
>
> On Sat, Nov 2, 2019 at 11:52 AM Stephen Farrell <[email-masked]> wrote:
>>
>>
>> Hiya,
>>
> that you should expect security.. If there is, then it's potentially

I've suggested a number of times, but haven't actually written up,
that you could encode this in the nameserver name - this is somewhat
similar to the dnscrypt idea...

E.g - no DoX expected:
$ dig ns example.com
;; ANSWER SECTION:
example.com. 42923 IN NS b.iana-servers.net.
example.com. 42923 IN NS a.iana-servers.net.

Recursive resolvers should expect DoT:
$ dig ns example.com
;; ANSWER SECTION:
example.com. 42923 IN NS b-dot.iana-servers.net.
example.com. 42923 IN NS a-dot.iana-servers.net.

Yes, I'll be the first to admit that it is hacky, and not it's not
completely foolproof, but it requires an attacker to do more than just
block port 853 to force a downgrade, and also means that resolvers
don't have to probe 853, wait for a timeout and then try 53
instead....

W

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Nov 2019 19:01:22 -0700

> don't have to probe 853, wait for a timeout and then try 53

Can you expand on this? Is the convention that if I see x-dot.example.com,
then I should expect DoT?

-Ekr

---

From: "John R Levine" <[email-masked]>
Date: 3 Nov 2019 00:24:53 -0400

On Sat, 2 Nov 2019, Eric Rescorla wrote:
> Sure. One reason you might be sad about this is that it has an extra round trip.

Indeed, but assuming the stub remembers what it's probed recently, the 
number of extra round trips might not be all that high.  This strikes me 
as an area where some experiments or simulations could be very 
informative.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Warren Kumari <[email-masked]>
Date: Sun, 3 Nov 2019 07:27:19 -0500

> then I should expect DoT?

Yup, that’s it exactly.

As a DNS person, encoding semantics into the name makes me twitch, and I’m
concerned we eventually end up with:
x-dot-doh-ipv4-and-IPv6-I-also-support-tcp-far-our-in-the-uncharted-backwaters-of-the-western-spiral-arm.example.com,
but as a pragmatic and deployment it seem to work.

A suitably positioned *active* attacker could probably still cause a
downgrade (because glue isn’t signed), but it requires much more work on
the attackers part than:
deny I do any any 853
permit ip any any

This also gives us the opportunity for a bikeshed discussion re: what label
to use :-)

w

>> > OTOH, TLS had day one defense against active attacks.
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

---

From: David Conrad <[email-masked]>
Date: Sun, 3 Nov 2019 10:37:56 -0500

Warren,

On Nov 3, 2019, at 7:27 AM, Warren Kumari <[email-masked]> wrote:
> Can you expand on this? Is the convention that if I see x-dot.example.com <http://x-dot.example.com/>, then I should expect DoT?
> 
> Yup, that’s it exactly.
> 
> As a DNS person, encoding semantics into the name makes me twitch, and I’m concerned we eventually end up with:
> x-dot-doh-ipv4-and-IPv6-I-also-support-tcp-far-our-in-the-uncharted-backwaters-of-the-western-spiral-arm.example.com <http://x-dot-doh-ipv4-and-ipv6-i-also-support-tcp-far-our-in-the-uncharted-backwaters-of-the-western-spiral-arm.example.com/>, but as a pragmatic and deployment it seem to work.
> 
> A suitably positioned *active* attacker could probably still cause a downgrade (because glue isn’t signed), but it requires much more work on the attackers part than:
> deny I do any any 853
> permit ip any any
> 
> This also gives us the opportunity for a bikeshed discussion re: what label to use :-)

Oh! Bikeshedding! Yay! You could do x-<ldh-encoded bit string of binary options indicating support for various transport technologies>.example.com!

What’s the emoji for tongue-in-cheek again?

Regards,
-drc

---

From: Paul Wouters <[email-masked]>
Date: Sun, 3 Nov 2019 11:01:53 -0500

> On Nov 3, 2019, at 07:27, Warren Kumari <[email-masked]> wrote:
> 
>> Can you expand on this? Is the convention that if I see x-dot.example.com, then I should expect DoT?
> 
> Yup, that’s it exactly.
> 
> As a DNS person, encoding semantics into the name makes me twitch

It should do more than cause a twitch.

The right way to do this is a DNSKEY flag, which is protected by the signed DS at the parent. Similar to draft-powerbind for the delegation-only domain.

Telling people to make security decisions based on unsigned DNS glue is not a good idea.

If you use DNS to signal security information, you have to accept requiring DNSSEC.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 3 Nov 2019 17:24:38 +0000

Hi Eric,

I mostly agree with your analysis (other than maybe we'd
be better off to more precisely distinguish https vs. tls,
as we figure this out.

Just one clarification:

> I don't understand what DNSSEC would do if not defend against active

What I meant was that the dependency on the parent for
DNSSEC was driven by that requirement for preventing
active attacks on day-1, but the dependency on the parent
making changes has also been a serious obstacle to
deployment.

In contrast, things like dkim, dmarc and mta-sts come
with testing modes and reporting, which I think helps
deployment.

What I'm asking is that we consider those kinds of
make-deployment-easier features as well when figuring
out adot (regardless of whether or not we end up with
an opportunistic approach).

Cheers,
S.

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 4 Nov 2019 17:12:17 +0000

In the -01 I added a parenthetical to address this suggestion and later WG discussion. Not sure if we’re there yet so open to specific wording suggestions.
//from GH repo//
# Threat Model and Problem Statement

Currently, potentially privacy-protective protocols such as DoT provide encryption between the user's stub resolver and a recursive resolver. This provides (1) protection from observation of end user DNS queries and responses as well as (2) protection from on-the-wire modification DNS queries or responses (including potentially forcing a downgrade to an unencrypted communication). Of course, observation and modification are still possible when performed by the recursive resolver, which decrypts queries, serves a response from cache or performs recursion to obtain a response (or synthesizes a response), and then encrypts the response and sends it back to the user's stub resolver.

But observation and modification threats still exist when a recursive resolver must perform DNS recursion, from the root to TLD to authoritative servers. This document specifies requirements for filling those gaps.

From: dns-privacy <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Date: Friday, November 1, 2019 at 2:11 PM
To: "[email-masked]" <[email-masked]>
Subject: [dns-privacy] Threat Model

-Ekr

---

From: Tony Finch <[email-masked]>
Date: Mon, 4 Nov 2019 20:37:14 +0000

Paul Wouters <[email-masked]> wrote:
>
> The right way to do this is a DNSKEY flag, which is protected by the
> signed DS at the parent. Similar to draft-powerbind for the
> delegation-only domain.

That's per-zone, though, whereas DoT support is per-server.

DS records that somehow encode NS target names in their rdata might
work...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
partnership and community in all areas of life

---

From: Paul Wouters <[email-masked]>
Date: Mon, 4 Nov 2019 16:15:45 -0500 (EST)

On Mon, 4 Nov 2019, Tony Finch wrote:

> Subject: Re: [dns-privacy] [Ext] Threat Model
> 

Maybe that's ideal, but one would expect that a zone only rolls this
out once all their nameservers support it. Otherwise, whether or not
resolvers do DoT to authoritative servers would be an odd game of
russian roulette depending on which NS record was followed, something
that could even be tweaked by an attacker, like by stripping glue from
the ones that did support it.

> DS records that somehow encode NS target names in their rdata might

That still leaves too much control at the parent to change it against
the child's wishes. A DNSKEY flag commits the child zone using publication
at its parent without giving the parent a veto.

Paul

---

From: Brian Dickson <[email-masked]>
Date: Mon, 4 Nov 2019 13:36:32 -0800

> That's per-zone, though, whereas DoT support is per-server.

Well, it kind of depends, i.e. yes and no.

E.g. a DNS hosting provider might (or might not) apply the DoT support to
all the zones hosted on a given server, which has the effect of being
per-server, while still being implemented at a per-zone level.

Per-zone also is much friendlier to multi-provider (primary/secondary), in
those cases, i.e. prevents targeted downgrades on such zones (presuming the
secondary actually serves on the DoT port).

The names of the servers (and certificate management) would be orthogonal
to the signaling of DoT support. I would expect the TLSA records would be
per-server and orthogonal to the per-zone signaling of DoT support.

(The analogy would be routing registries and routing announcements. You
have to have the registration done first before the announcement, but the
registration and the announcement are distinct elements. Similar also to DS
and DNSKEY records.)

Brian

---

From: Paul Wouters <[email-masked]>
Date: Mon, 4 Nov 2019 16:56:36 -0500 (EST)

On Mon, 4 Nov 2019, Brian Dickson wrote:

> The names of the servers (and certificate management) would be orthogonal to the signaling of DoT support. I would expect the TLSA records would
> be per-server and orthogonal to the per-zone signaling of DoT support.

Again, that would be russian roulette. If I get an NS RRset with 3
nameservers, and only one of these has a TLSA record, what should I
do ?

1) Pick the TLSA one
2) Pick a random one

For 1) if this protocol is widely deployed, all clients will pick 1) so you just shot your redundancy in the foot.

For 2) the clients get reduced privacy for no good reason, so why would a client do this?

It is really a per-zone property, not a per-nameserver property.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Nov 2019 14:12:40 -0800

On Mon, Nov 4, 2019 at 1:56 PM Paul Wouters <[email-masked]> wrote:

> > The names of the servers (and certificate management) would be
> orthogonal to the signaling of DoT support. I would expect the TLSA records
> would
> For 1) if this protocol is widely deployed, all clients will pick 1) so
> you just shot your redundancy in the foot.
>

This is a good point, and seems like an argument against all of the
opportunistic versions as well, even those with HSTS-style mechanisms.

Suppose I look up a.example.com and get ns1.nameservers.example and
ns2.nameservers.example, and I have talked to ns1 and know it does Dot but
I don't know about ns2. What then? Or say I can't connect to ns1....

-Ekr

Paul

---

From: Brian Dickson <[email-masked]>
Date: Mon, 4 Nov 2019 14:20:40 -0800

> nameservers, and only one of these has a TLSA record, what should I

IMNSHO, that is something the domain owner needs to consider, much more so
than the resolver operator.

Specifically, this is something that should probably go into a BCP about
DoT:

If you plan on doing DoT and using TLSA records, it is RECOMMENDED that the
same level of redundancy for DoT servers is deployed as would be the
general case for DNS (i.e. two minimum).

(Along with an explanation of why not having TLSA records for at least two
distinct server names would create an availability/security weakness.)

Other than the question of just one TLSA, I think the recommendation on
what to do if only a subset of NS RRSET members have TLSA records, is to
try to use all the ones that have TLSA records, repeatedly, before doing
anything else.
The "anything else" could be any of several things, from some variation of
"serve stale" to SERVFAIL to using Do53.

Brian

---

From: "John Levine" <[email-masked]>
Date: 4 Nov 2019 21:40:42 -0500

>> nameservers, and only one of these has a TLSA record, what should I

Dunno about you, but I'd make a note not to hire that provider to run my DNS.

People can set up any sort of DNS badly, and experience has repeatedly
shown that attempts to idiot-proof systems merely brings out more
ingenious idiots.  The more useful question is how hard it is for a
sensible person to set something up sensibly, and in this case the
answer is not very hard.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 4 Nov 2019 18:19:06 -0500

In article <[email-masked]> you write:
>out once all their nameservers support it.

Most of my zones have a secondary run by somebody else, whose software
is never in sync with mine.  It's also fairly common for large operators
to mitigate their DNS risk by spreading DNS across multiple providers.
If you have to wait until every server can do ADoT rather than until
some of them can, that will make deployment a lot slower.

> Otherwise, whether or not

There are plenty of signal schemes that don't fail that way.  See my
recent draft.

>at its parent without giving the parent a veto.

The parent zone always has a veto.  It can remove the NS or DS records if it
doesn't like what the child is doing.

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Nov 2019 11:02:25 +0000

John Levine <[email-masked]> wrote:
> is never in sync with mine.

Yes, also it's operationally much less stressful if you can use a canary
deployment to verify a partial roll-out before full deployment.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Cyclonic 4 to 6, increasing 7 in far northwest. Moderate or
rough. Wintry showers. Good, occasionally poor.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 5 Nov 2019 09:47:45 -0500 (EST)

On Tue, 5 Nov 2019, Warren Kumari wrote:

> $ dig ns a.example.com
> ;; ANSWER SECTION:
> a.example.com. 42923 IN NS ns1-dot.nameservers.example.
> a.example.com. 42923 IN NS ns2.nameservers.example.
>
> Now, if you cannot reach ns1-dot.nameservers.example, whether you fall
> back to ns2.nameservers.example is a matter of client policy /
> paranoia. As this is an *opportunistic* / better than nothing solution
> I'd think that falling back makes sense. This really really isn't a
> replacement for a more secure, downgrade resistant solution (like
> Paul's), but it *is* an incrementally deployable, opportunistic
> convention based solution. We could do it while figuring out a better,
> more secure system...

I guess you need to use ns1-dot and not a TLSA record for
_853._tcp.ns1-dot.nameservers.example.  because no sane implementation
of anything would trust unsigned TLSA records. That also says
something. Opportunistic does not have to mean soft fail.

If you are going to accept a downgrade when under attack, why even
bother with any signaling using name hacks and just try port 853 on
all nameservers, and remember the ones that failed and succeeded for a
little while? Then you truly do not need any coordination between your
nameserver operators at all, for those who depend on secondaries that
they do not control the software of.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Tue, 5 Nov 2019 09:29:14 -0500

On Mon, Nov 4, 2019 at 5:13 PM Eric Rescorla <[email-masked]> wrote:
> This is a good point, and seems like an argument against all of the opportunistic versions as well, even those with HSTS-style mechanisms.
>
> Suppose I look up a.example.com and get ns1.nameservers.example and ns2.nameservers.example, and I have talked to ns1 and know it does Dot but I don't know about ns2. What then? Or say I can't connect to ns1....

$ dig ns a.example.com
;; ANSWER SECTION:

W

---

From: Warren Kumari <[email-masked]>
Date: Tue, 5 Nov 2019 12:21:37 -0500

> they do not control the software of.

Because then I need to probe them on 853 and wait N before trying on port
53, or I will only get any sort of protection for name-servers which I’ve
spoken to recently enough that I have them in cache — that works for e.g:
ns1.google.com, but not ns0.nohats.ca

W

---

From: Paul Wouters <[email-masked]>
Date: Tue, 5 Nov 2019 14:40:43 -0500 (EST)

On Tue, 5 Nov 2019, Warren Kumari wrote:

> Because then I need to probe them on 853 and wait N before trying on port 53, or I will
> only get any sort of protection for name-servers which I’ve spoken to recently enough that
> I have them in cache — that works for e.g: ns1.google.com, but not ns0.nohats.ca

Well, that's how we do things when remembering per-server
characteristics, which we need to do anyway in case of outages.

Like EDNS0 support and DNS COOKIES support is remembered and cached,
why wouldn't resolvers do the same for this property. We didn't put
"ns-edns" out there in name hacks either. Why start now?

Paul

---

From: Warren Kumari <[email-masked]>
Date: Tue, 5 Nov 2019 18:13:45 -0500

> "ns-edns" out there in name hacks either. Why start now?

For things like COOKIES I don't need knowledge of the server *before*
I contact it -- when I want to lookup www.nothat.ca, and get back a
cookie, I've learnt something useful for future connections.

For privacy, I really don't want to have to leak the fact that I'm
looking up secret.nohats.ca because I happen to be the first user who
is (recently) asking for a name on ns0.nohats.ca.
a.ns.facebook.com is popular and so in basically all caches, all the
time - and so users looking that up would get privacy most of the
time.
ns01.kumari.net is (obviously) less popular, and so basically never in
caches -- and so anyone looking up kink.kumari.net will be exposed.

Now, I really don't think it is fair and right that people looking up
Facebook (or Google) get privacy simply because those sites are
popular, and people reaching my personal site don't.
I could get privacy back by moving my DNS to a large commercial DNS
hoster (ns59.domaincontrol.com is in many caches, much of the time),
but this seems like an even worse push.

I'd like some system where I can signal that I support DoT:
1: without my parent having to do anything (like be upgraded to support DoT)

2:  without having people to probe and wait for a timeout

3: with my users first connection protected, so they don't have to
lookup safe.kumari.net (to make sure that the resolver knows that
ns01.kumari.net supports DoT), or something like _dot.kumari.net
before looking up secret.kumari.net.

4: without expecting everyone to support DNSSEC.

I'd like to see something less stupid than ns01-dot.kumari.net, but I
don't really see what else the child controls at the parent (without
having a separate set of info / RR type / encoding stuff in DS, etc)

W

---

From: Brian Dickson <[email-masked]>
Date: Tue, 5 Nov 2019 16:35:49 -0800

> having a separate set of info / RR type / encoding stuff in DS, etc)

So, I'm going to rephrase some stuff, in an attempt to capture what I
believe are either (a) requirements, or (b) changes to DNS, in what you
describe.

Then, I'll ask some leading questions, and make some assertions, and see
where that goes. :-)

So, currently, there is no recursive-to-authoritative privacy standardized,
per se, even if there might be some early implementations (DoT in OTE at
godaddy for example).

The first question is, since no standard yet exists, why NOT include a
requirement for DNSSEC in order to do privacy to the authoritative, even if
only in the secure bootstrap process?
It's all green-field, right? I.e. excluding DNSSEC a priori seems overly
restrictive. (But let's leave that for now. But please answer this
question, it's something I'm interested in.)

Second, there seems to be an inherent leakage of information caused by an
association between the NS name of your domain and the domain and its
children.

Suppose the name server name, was decoupled from the domain you care about,
and all the information about that name server were in a different domain,
where the name of the name server was served from another name server whose
name was an in-bailiwick name for that other domain, and the query for the
name server for the domain you care about was only ever done over an
encrypted connection. (Whew.)

E.g.
kumari.net NS ns-ku.secret-nameserver-12345.net
secret-nameserver-12345.net NS ns1.secret-nameserver-12345.net
ns1.secret-nameserver-12345.net A <ipv4>
ns1.secret-nameserver-12345.net AAAA <ipv6>

Then have records for the DOT bits for both ns-ku and ns1 inside the
secret-nameserver-12345.net zone.
(Pick your poison on what those records would look like, anything from TLSA
records to A/AAAA records to some new RR type, or even SRV records.)

The privacy stuff would be a two-phase privacy bootstrap.
First, do the query to get the needed privacy stuff for
ns1.secret-nameserver-12345.net over a non-private connection.
Then, do the query to get the needed privacy stuff for
ns-ku.secret-nameserver-12345.net over a newly-established DoT connection
based on the previous step.
Third, do the query toward ns-ku.secret-nameserver-12345.net over another
DoT connection based on the previous step, to obtain any records within
kumari.net in a private fashion.

To know that any given query towards secret-nameserver-12345.net was
intended to get the stuff for kumari.net, would require more deductive
reasoning than in your original examples.

Also important is that the only information that would need to be stored on
secret-nameserver-12345.net would be an (arbitrary) nameserver name, plus
A/AAAA glue data, plus whatever other parameters are needed for DoT
signaling.

Thus, it would be very feasible for someone to offer a privacy-enabling
service like secret-nameserver-12345.net, that would provide a
stegonographic cover for all its clients, and those clients would not need
to identify their domains per se, and would eliminate the information
leakage of using a single domain with in-bailiwick name for the name server.

I.e. you would not need to operate secret-nameserver-12345 yourself (but
you could), and if you didn't, you would get a lot more privacy than is
otherwise possible (I think).

Additionally, the bigger and more popular secret-nameserver-12345 is, the
more likely it is in cache, allowing very private bootstrapping of the
privacy-protected DNS for kink.kumari.net.

I think this does #1 and #2, probably does #3, and #4 is open for
discussion.

Thoughts?
Answers?

Brian

---

From: Dan Wing <[email-masked]>
Date: Tue, 5 Nov 2019 19:21:41 -0800

On Nov 5, 2019, at 3:13 PM, Warren Kumari <[email-masked]> wrote:

...
> having a separate set of info / RR type / encoding stuff in DS, etc)

Perhaps encode feature flags into the last digits of the SOA's Expire time?  For example kumari.net <http://kumari.net/> has an expire time of 1209600, and those last two (decimal) digits could be used for binary encoding feature flags, so 1209601 = DoT, 1209602 = DoH, 1209603 = DoT and DoH, and so on.  This gives us 6 feature flags we could shove into Expire time.

-d

---

From: Mark Andrews <[email-masked]>
Date: Wed, 6 Nov 2019 15:42:00 +1100

You can always send a QUERY with no question.  It’s not perfect, as it is subject
to downgrade attacks, but does allow you to probe server capabilities.

% dig +ednsopt=100 +header-only +qr

; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>> +ednsopt +header-only +qr
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38660
;; flags: rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ab59773fd258541b
; OPT=100
;; QUESTION SECTION:

;; QUERY SIZE: 39

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38660
;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ab59773fd258541b010000005dc24d3939228b15d289bab4 (good)
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 06 15:34:01 AEDT 2019
;; MSG SIZE  rcvd: 51

% 

> On 6 Nov 2019, at 10:13, Warren Kumari <[email-masked]> wrote:
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 06 Nov 2019 10:24:06 +0100

Moin!

> 1: without my parent having to do anything (like be upgraded to 
Why does the parent to be upgraded to DoT? It can just indicate a DoT 
server for a child. These are normal DNS semantics.

> 2:  without having people to probe and wait for a timeout
Again resolution follows the delegation, so that is the best place to 
put this in.

> before looking up secret.kumari.net.
Well as long as you are ok with that someone wants to something in 
kumari.net that should work. However maybe it is good to remind people 
that public DNS data is public so keeping something secret is hard to 
impossible. Also there has been some research presented at the ANRW 
workshop that even when hiding all DNS traffic from an observer it still 
is possible to digest what user visited by only looking at the IP 
addresses. ( https://irtf.org/anrw/2019/program.html - What Can You 
Learn from an IP). As said before if we really want privacy for users we 
have to fully encrypt and obfuscate layer 3.

> 4: without expecting everyone to support DNSSEC.
Really. I can not see how we design something new that does not take 
DNSSEC into account. That would negate a lot of hard work done by a lot 
of people over decades. Would you design something new without taking 
IPv6 into account?

So long
-Ralf
—--
Ralf Weber

---

From: Hugo Connery <[email-masked]>
Date: Wed, 6 Nov 2019 14:02:45 +0100

> they do not control the software of.

If the initial goal, as suggested by Stephen, is to deploy an 
opportunitistic DoT to encourage deployment, then Paul's suggestion
above which de-couples the recursive and authoritative seems wise.

This gets "the ball further down the road" while deciding about a
more rigorous solution in which recursive resolvers attempt to honour
client policy (do fallback, dont fallback, etc.) and how authoritatives
advertise their DoT service is developed.

Regards,
-- 
Hugo Connery, Head of IT, Dept. Environmental Engineering
Technical University of Denmark, http://www.env.dtu.dk

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Nov 2019 09:15:01 -0500

> On Nov 6, 2019, at 04:24, Ralf Weber <[email-masked]> wrote:
> 
> 
> Really. I can not see how we design something new that does not take DNSSEC into account.

Indeed. The longer we treat DNSSEC as optional, the longer we will be faced with adoption problems, exactly as with IPv6.

We talk a lot about the DNS camel, but the “avoid DNSSEC” camel has quite the number of pages in RFCs now.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 6 Nov 2019 14:48:35 +0000

Hiya,

> We talk a lot about the DNS camel, but the “avoid DNSSEC” camel has quite the number of pages in RFCs now.

Interesting. I read Warren's text as being "don't require
DNSSEC having been deployed" while you and Ralf seem to be
reading the same text as "don't take DNSSEC into account"
or "avoid DNSSEC."

I'm fine with Warren's text FWIW. ISTM that ~1% deployment
after this elapsed time means that depending on DNSSEC
deployment is just... unwise. ("Unwise" wasn't the first
word I typed there btw;-) Being to be able to benefit
from DNSSEC deployment is a good thing, but a different
thing. I also think trying to avoid or ignore DNSSEC is
almost but not quite as unwise as requiring DNSSEC
deployment.

Maybe these different interpretations of the same text
are indicators that many of us are reading too much
between too many lines?

Cheers,
S.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Nov 2019 16:21:41 +0000

Given that we are (still supposedly) talking about requirements and not solutions, I would be unhappy with a requirement that prevents a resolver that is not validating from being able to use encrypted transport to authoritative servers. Any protocol we develop for ADoT capability discovery should prevent downgrade attacks but should also work fine for resolvers that do not validate.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Wed, 6 Nov 2019 09:04:44 -0800

On Wed, Nov 6, 2019 at 8:21 AM Paul Hoffman <[email-masked]> wrote:

> Given that we are (still supposedly) talking about requirements and not
> solutions, I would be unhappy with a requirement that prevents a resolver
> that is not validating from being able to use encrypted transport to
> authoritative servers. Any protocol we develop for ADoT capability
> discovery should prevent downgrade attacks but should also work fine for
> resolvers that do not validate.
>

Why?

Or rather, let me put together a straw-man to attack.

Suppose the requirement (for the protocol for establishing the encrypted
transport for actual ADoT or for discovery of ADoT parameters) was that
*for this record* the record must be signed and must be validated, but that
it placed no broader requirement on validation.

I.e. TSLA for cert validation for the TLS connections used, which would
require DNSSEC validation (mandatory per DANE RFCs).

That would mean resolvers that don't validate *generally*, but do follow
the protocol (and validate very specific records) would would fine. Would
that be an unhappy-making requirement, or would you be okay with that
hair-splitting on validation?

Given that presumably *some* changes would need to be made to resolvers for
ADoT, IMHO the particulars of *what* changes should all be open to
discussion.

Brian

---

From: Ted Hardie <[email-masked]>
Date: Wed, 6 Nov 2019 09:30:48 -0800

In-line.

> it placed no broader requirement on validation.

It seems odd to have the code and operations to do this on both signing and
validation , but then use it intermittently.  That seems both hard to
reason about and difficult to explain.

> hair-splitting on validation?

I don’t think this would be something to recommend, personally.

Ted

>
> Given that presumably *some* changes would need to be made to resolvers
> for ADoT, IMHO the particulars of *what* changes should all be open to
> discussion.
>
> Brian

---

From: Brian Dickson <[email-masked]>
Date: Wed, 6 Nov 2019 09:45:28 -0800

On Wed, Nov 6, 2019 at 9:31 AM Ted Hardie <[email-masked]> wrote:

> In-line.
>
> On Wed, Nov 6, 2019 at 9:05 AM Brian Dickson <
> [email-masked]> wrote:
>
>>
>>
> It seems odd to have the code and operations to do this on both signing
> and validation , but then use it intermittently.  That seems both hard to

I was interested in Paul's reason for "do not validate", as to whether it
was the concerns of generally validating everything, versus having the code
and operations that do the validation.
I.e., is it the concern about some zones having signing errors, independent
from the ADoT thing?

More recent operational results have show vastly improved levels of correct
operation of DNSSEC, and many fewer problems showing up, although I don't
track that myself and don't have references handy.
(I think there was a thread recently on one of the relevant lists to that
effect, though.)
I.e. I don't think aversion to validation generally is rational, but I also
don't like all-or-nothing when it comes to validation. I see this as likely
being an MTI (mandatory to implement) thing, with knobs to allow operators
to disable (against "medical" advice, as it were).

> I don’t think this would be something to recommend, personally.

Exactly, you have very clearly made my point for me between your two
comments. :-)

---

From: Paul Wouters <[email-masked]>
Date: Fri, 8 Nov 2019 16:37:04 -0500 (EST)

On Wed, 6 Nov 2019, Paul Hoffman wrote:

> Given that we are (still supposedly) talking about requirements and not solutions, I would be unhappy with a requirement that prevents a resolver that is not validating

Why would a _resolver_ not be validating ?

I understand the reasons for web applications that do not want to do
validating, though I disagree with those. But for actual DNS resolvers,
running as DNS caching server on either laptop or in an enterprise, I
see no valid reason why it should not be validating at this point.

> Any protocol we develop for ADoT capability discovery should prevent downgrade attacks but should also work fine for resolvers that do not validate.

I strongly disagree. Resolvers towards Authoritative servers are core
infrastructure, and that core should have no problems using the latest
DNS RFC's.

Paul

---

From: Bob Harold <[email-masked]>
Date: Fri, 8 Nov 2019 17:06:22 -0500

On Fri, Nov 8, 2019 at 4:37 PM Paul Wouters <[email-masked]> wrote:

> that is not validating
> > Any protocol we develop for ADoT capability discovery should prevent
> downgrade attacks but should also work fine for resolvers that do not
> validate.
>

I hate to admit it, and this is a little off topic, but my resolvers are
not (yet) validating.
Is there a setting that will attempt to validate, and log if it fails, but
still answer the users?
I hear that there are occasional sites that fail validation, and would like
to know what will break if and when I begin to validate.
I will also need to monitor the added load on the servers, although I don't
expect it to be a problem.
I realize that not everyone agrees with this level of
caution/fear/lack-of-backbone (I am sure there are other descriptions
people would prefer).

-- 
Bob Harold

---

From: Paul Wouters <[email-masked]>
Date: Fri, 8 Nov 2019 18:11:01 -0500

> On Nov 8, 2019, at 17:06, Bob Harold <[email-masked]> wrote:
> 
> 
> I hate to admit it, and this is a little off topic, but my resolvers are not (yet) validating.

Then your resolvers’ configuration is years out of date. All resolvers these days ship with validation enabled.

> Is there a setting that will attempt to validate, and log if it fails, but still answer the users?

At that point, everyone using 8.8.8.8 or 9.9.9.9 or 1.1.1.1 or any other non-opendns resolver would not be able to access that domain. Why would you want to override that?

> I hear that there are occasional sites that fail validation, and would like to know what will break if and when I begin to validate.

Nothing that the vast majority of users would already not be able to see.

> I will also need to monitor the added load on the servers, although I don't expect it to be a problem.

That’s not an issue.

> I realize that not everyone agrees with this level of caution/fear/lack-of-backbone (I am sure there are other descriptions people would prefer).

It’s far too late for that level of concern by you.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 9 Nov 2019 00:17:32 +0000

Hi Paul,

On 08/11/2019 23:11, Paul Wouters wrote:
>> caution/fear/lack-of-backbone (I am sure there are other
>> descriptions people would prefer).
It seems odd that you're telling someone what they
ought not be worried about. Wouldn't it be better
to be convincing that there's nothing to worry about?
(E.g. via stats.)

S.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 8 Nov 2019 17:13:44 -0800

> to be convincing that there's nothing to worry about?

I was curious as to whether there are any easy-to-find stats or other
information on validation failures.
(Short summary: not a lot, not detailed, mostly anecdotal or summary
information.)

The closest thing to stats I could find were:
https://www.theregister.co.uk/2018/02/28/dutch_name_authority_dnssec_validation_errors_can_be_eliminated/

The relevant information was that "The rate of validation error is now 30
per million DNSSEC lookups."

I'd say that is low enough to not worry.

More anecdotal stuff is at https://ianix.com/pub/dnssec-outages.html which
lumps together information about TLD failures (now very rare), sites with
failures (becoming increasingly uncommon and having smaller impact), and
durations (typically a week or less on average, but again, this is
anecdotal not statistical.)

My view is the pendulum is swinging in the other direction, i.e. that the
next push needs to come (and will come) from the signing of domains rather
than validating by resolvers, for leading aggregate DNSSEC uptake.

The support for DNSSEC signing in software, including management of
automated unattended signing, has drastically improved, to the point where
IMHO you would have to try to find software or operators that don't do
things to facilitate reliable signing.

YMMV, of course. But, fear of rampant validation failures is entirely
misplaced at this point. Enough validation is being done, that such
failures need to be considered the responsibility of the signers, not the
validators. Sign, by all means, but expect that resolvers will validate,
and take appropriate measures to monitor and alert on failures.

Brian

---

From: Paul Ebersman <[email-masked]>
Date: Fri, 08 Nov 2019 20:51:33 -0500

stephen> It seems odd that you're telling someone what they ought not be
stephen> worried about. Wouldn't it be better to be convincing that
stephen> there's nothing to worry about?  (E.g. via stats.)

It's a few years out of date but this has actually improved. I was on
the DNS team at comcast. I've confirmed that this is still more or less
what they see.

For 500-600 billion queries per day, 1-2 dozen DNSSEC related failures
per month (modulo a few folks in .mil or .gov that have NTAs for long
standing failures). That's with validation on all queries.

That's in the below noise range. I wish I had packet drop rates in that
range. ;)

---

From: Paul Wouters <[email-masked]>
Date: Fri, 8 Nov 2019 21:16:38 -0500

> On Nov 8, 2019, at 20:13, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> 
> More anecdotal stuff is at https://ianix.com/pub/dnssec-outages.html which lumps together information about TLD failures (now very rare), sites with failures (becoming increasingly uncommon and having smaller impact), and durations (typically a week or less on average, but again, this is anecdotal not statistical.)

I have on a few occasions explained to the people running this site that they were wrong to blame dnssec. Some listed events were generic outages wrongly blamed on dnssec. No corrections were ever made. The side is extremely subjectively anti-dnssec. 

> 
> 
> YMMV, of course. But, fear of rampant validation failures is entirely misplaced at this point. Enough validation is being done, that such failures need to be considered the responsibility of the signers, not the validators.

Exactly, and why I quoted 8.8.8.8, 1.1.1.1 and 9.9.9.9. So many people are behind dnssec validators that validation failure would lead to a quick outage notification by tools or humans.

Paul

---

From: Bob Harold <[email-masked]>
Date: Mon, 11 Nov 2019 11:03:11 -0500

On Fri, Nov 8, 2019 at 9:17 PM Paul Wouters <[email-masked]> wrote:

> I have on a few occasions explained to the people running this site that
> they were wrong to blame dnssec. Some listed events were generic outages
> wrongly blamed on dnssec. No corrections were ever made. The side is
> extremely subjectively anti-dnssec.
>
>
>
> validators.
> Exactly, and why I quoted 8.8.8.8, 1.1.1.1 and 9.9.9.9. So many people are
> behind dnssec validators that validation failure would lead to a quick
> outage notification by tools or humans.
>
> Paul
>

Thanks to everyone for the info and recommendations.  I need to figure out
how to alert on validation failures, and then enable validation.

-- 
Bob Harold

---

From: [email-masked]
Date: Mon, 11 Nov 2019 17:23:06 +0100 (CET)

> how to alert on validation failures, and then enable validation.

You may want to investigate PowerDNS Recursor and its "log-fail" setting:

"In this mode, the recursor will attempt to validate all data it
retrieves from authoritative servers, regardless of the client's DNSSEC
desires, and will log the validation result."

See https://doc.powerdns.com/recursor/dnssec.html

Steinar Haug, AS2116