Subject: [Add] canary domain and recursion

From: Manu Bretelle <[email-masked]>
Date: Tue, 19 Nov 2019 14:16:27 +0800

Hi all,

One of the potential issue with a standard domain, is that the local
network will perform recursion to learn its records.

This basically allow anyone upstream/on-path from the resolver to intercept
and change the result to their liking.

If the intent is to detect local network policy, parental control, is it
safe to assume that we want the policy to be performed by the recursive
resolver?

How about signaling this through .test domain [0] or similar? The resolver
is not supposed to query/lookup authoritative servers for it.
Someone wanting to disable DoH, would be able to return answers for A/AAAA,
NXDOMAIN would mean that there is no intent to disable it.

Administrator can set the policy at the host level (adding entries to
/etc/hosts and the likes). Parental control for home users could do that at
the CPE level, parental control for mobile phone that often rely on VPN to
send DNS requests to their servers could handle those requests from the
same endpoint.
Enterprises, if not relying on MDM or such could do the same by configuring
their resolvers to return answers for those names.

Hopefully, this could isolate the policy decision to the first DNS server
on path and limit anyone upstream to be able to influence the canary domain.

Thoughts?
Manu

[0] https://tools.ietf.org/html/rfc6761#section-6.2

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 19 Nov 2019 15:00:43 +0800

Moin!

> and change the result to their liking.
Not if you DNSSEC sign it. Then the last resolver still can NXD it, but
nobody in the way can as it would not validate.

> NXDOMAIN would mean that there is no intent to disable it.
We can do this, but it would require changes in the software as nothing is
defined for these. .arpa might be better, but the problem with the
software is the same. And you can certainly not sign .test, but you might
be able to sign something in .arpa.

So long
-Ralf
—--
Ralf Weber

---

From: Petr Špaček <[email-masked]>
Date: Tue, 19 Nov 2019 08:10:37 +0100

> nobody in the way can as it would not validate.

I agree with Ralf.

>> NXDOMAIN would mean that there is no intent to disable it.

Asking for a new special-use name is usually asking for trouble for two reasons: Getting special-name reservation involves too much politics, and getting it deployed requires changes in all DNS stacks. Please let's use a normal DNS delegation.

Petr Špaček  @  CZ.NIC

---

From: Manu Bretelle <[email-masked]>
Date: Tue, 19 Nov 2019 16:15:16 +0800

On Tue, Nov 19, 2019 at 3:10 PM Petr Špaček <[email-masked]> wrote:

> Asking for a new special-use name is usually asking for trouble for two
> reasons: Getting special-name reservation involves too much politics, and
> getting it deployed requires changes in all DNS stacks. Please let's use a
> normal DNS delegation.

I am not saying a new special domain should be assigned, but leveraging
something like .test, which, to my understanding, is already assigned as a
special domain that a resolver should not query authoritative servers for.

> > be able to sign something in .arpa.

Point taken. Mainly if the handling of .test is not already widely adopted.

Manu

>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Jim Reid <[email-masked]>
Date: Tue, 19 Nov 2019 08:38:56 +0000

> On 19 Nov 2019, at 07:10, Petr Špaček <[email-masked]> wrote:
> 

It was pointed out at the ABCD BoF -- don't know if you followed that Petr -- that it would be a lot easier to put a canary domain under .arpa.

---

From: Petr Špaček <[email-masked]>
Date: Tue, 19 Nov 2019 09:46:08 +0100

On 19. 11. 19 9:15, Manu Bretelle wrote:
> 
> 
> On Tue, Nov 19, 2019 at 3:10 PM Petr Špaček <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>     >
> I am not saying a new special domain should be assigned, but leveraging something like .test, which, to my understanding, is already assigned as a special domain that a resolver should not query authoritative servers for.

The problem with special domains is that ... their are special/for a specific purpose :-)
Most importantly RFC 6761 does not mention forwarding which makes it difficult to rely on "test." domain behavior.

I would expect that "test." domain would not work on organization level because the "first hop" resolver would generate NXDOMAIN, without forwarding the query to the central resolver, which would make centrally-configured answer unavailable and so on.

Simply I do not see sufficient benefit in exploring this special-domain rat hole, normal domain should work for this purpose just fine.

Petr Špaček  @  CZ.NIC

P.S. This probably boils down to non-standard nature of forwarding, which practically means that half of DNS resolver behavior is not explicitly specified anywhere.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Nov 2019 04:12:40 -0500

> Simply I do not see sufficient benefit in exploring this special-domain rat hole, normal domain should work for this purpose just fine.

The problem with normal domains is that their registration is not permanent.

---

From: Andy Grover <[email-masked]>
Date: Tue, 19 Nov 2019 18:04:50 +0800

> It was pointed out at the ABCD BoF -- don't know if you followed that Petr -- that it would be a lot easier to put a canary domain under .arpa.

Agree .arpa could be a good fit. There's already precedent with
ipv4only.arpa, in rfc 7050.

If the logic is "resolve success means no canary" then should not be
required changes to DNS stacks. Only resolvers wishing to indicate local
policy would need to be configured to modify the result for the canary
domain.

-- Andy

---

From: Petr Špaček <[email-masked]>
Date: Tue, 19 Nov 2019 11:53:02 +0100

On 19. 11. 19 10:12, Ted Lemon wrote:
> On Nov 19, 2019, at 3:46 AM, Petr Špaček <[email-masked] <mailto:[email-masked]>> wrote:

In my eyes that's not sufficient to justify overhead of getting yet another special-domain name, especially if we want to see it deployed in this decade.

-- 
Petr Špaček  @  CZ.NIC

---

From: Andy Grover <[email-masked]>
Date: Tue, 19 Nov 2019 18:58:48 +0800

> In my eyes that's not sufficient to justify overhead of getting yet another special-domain name, especially if we want to see it deployed in this decade.

Why would allocating a domain under .arpa take so long? IAB manages it.

https://tools.ietf.org/html/rfc3172

-- Andy

---

From: Jim Reid <[email-masked]>
Date: Tue, 19 Nov 2019 11:06:18 +0000

> On 19 Nov 2019, at 10:58, Andy Grover <[email-masked]> wrote:
> 
> Why would allocating a domain under .arpa take so long?

It wouldn't. Petr seems to be thinking about a different type of special-use domain name that *didn't* involve .arpa: ie a label that goes in the root or on to a magic list of special TLD strings that will never ever be created..

---

From: Petr Špaček <[email-masked]>
Date: Tue, 19 Nov 2019 12:09:03 +0100

> https://tools.ietf.org/html/rfc3172

Maybe there is a terminological disconnect: I was referring to special-use names as defined in RFC 6761 - these are nightmare.

I'm not objecting to getting a normal DNS mechanisms (from protocol and DNS-resolver-code point of view!). If RFC 3172 allows us to get that in near future then go for it but we will have to live couple years or more with use-application-dns.net anyway.

-- 
Petr Špaček  @  CZ.NIC

---

From: Jim Reid <[email-masked]>
Date: Tue, 19 Nov 2019 11:10:30 +0000

> On 19 Nov 2019, at 11:09, Petr Špaček <[email-masked]> wrote:
> 

Indeed. And the mood of the room in dsnops this evening was *not* to go down that path.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Nov 2019 06:17:22 -0500

On Nov 19, 2019, at 6:09 AM, Petr Špaček <[email-masked]> wrote:
> I'm not objecting to getting a normal DNS mechanisms (from protocol and DNS-resolver-code point of view!). If RFC 3172 allows us to get that in near future then go for it but we will have to live couple years or more with use-application-dns.net <http://use-application-dns.net/> anyway.

Special-use names are just names that are treated specially.   The controversy was over special-use top-level names, because these had issues of who has control over the name.   canary.arpa would be controlled by the IAB.   Allocating home.arpa was trivial once we decided to do that instead of home.

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 19 Nov 2019 23:42:46 -0500

(DNSOP co-chair hat on)

> On Nov 19, 2019, at 6:17 AM, Ted Lemon <[email-masked]> wrote:
> 
> On Nov 19, 2019, at 6:09 AM, Petr Špaček <[email-masked] <mailto:[email-masked]>> wrote:

+1. The easy case is “there’s a standards-track RFC that specifies a SLD under .arpa with the following easily-described behavior” (signed delegation, unsigned delegation, non-delegation with commitment not to delegate, etc.). Examples include ipv4only.arpa and home.arpa. 

Standards track is required for the IAB and IANA to have the authority to make the change in .arpa, per RFC 3172.

People have a habit of thinking “special use name” implies top-level label (“TLD”). Such cases are indeed challenging, because they involve either a delegation of a name in the root zone or a commitment not to delegate a name in the root zone, and the IETF doesn’t control the root zone. However, there’s no reason to assume a special use name is a top-level name.

Suzanne

---

From: Ted Hardie <[email-masked]>
Date: Wed, 20 Nov 2019 14:08:23 +0800

Just to add an additional citation, the IAB's most recent statement on this
usage of .arpa is at:
https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/

regards,

Ted

On Wed, Nov 20, 2019 at 12:42 PM Suzanne Woolf <[email-masked]>
wrote:

> Maybe there is a terminological disconnect: I was referring to special-use
> names as defined in RFC 6761 - these are nightmare.
>
> I'm not objecting to getting a normal DNS mechanisms (from protocol and
> DNS-resolver-code point of view!). If RFC 3172 allows us to get that in
> near future then go for it but we will have to live couple years or more
> with use-application-dns.net anyway.
>
>
> Special-use names are just names that are treated specially.   The
> controversy was over special-use top-level names, because these had issues
> of who has control over the name.   canary.arpa would be controlled by the
> IAB.   Allocating home.arpa was trivial once we decided to do that instead
> of home.
>
>
> +1. The easy case is “there’s a standards-track RFC that specifies a SLD
> under .arpa with the following easily-described behavior” (signed
> delegation, unsigned delegation, non-delegation with commitment not to
> delegate, etc.). Examples include ipv4only.arpa and home.arpa.
>
> People have a habit of thinking “special use name” implies top-level label
> (“TLD”). Such cases are indeed challenging, because they involve either a
> delegation of a name in the root zone or a commitment not to delegate a
> name in the root zone, and the IETF doesn’t control the root zone. However,
> there’s no reason to assume a special use name is a top-level name.
>
>
> Suzanne
>
>
>
> --
> Add mailing list
> [email-masked]

---

From: Bob Harold <[email-masked]>
Date: Wed, 20 Nov 2019 10:53:05 -0500

Corrected URL:

(displayed URL below is correct, but the link has an extra dot after iab)

-- 
Bob Harold

On Wed, Nov 20, 2019 at 1:09 AM Ted Hardie <[email-masked]> wrote:

> Just to add an additional citation, the IAB's most recent statement on
> this usage of .arpa is at:
> <https://www.iab..org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/>
>
> regards,
>
> Ted
>
>> Maybe there is a terminological disconnect: I was referring to
>> special-use names as defined in RFC 6761 - these are nightmare.
>>
>> People have a habit of thinking “special use name” implies top-level
>> label (“TLD”). Such cases are indeed challenging, because they involve
>> either a delegation of a name in the root zone or a commitment not to
>> delegate a name in the root zone, and the IETF doesn’t control the root
>> zone. However, there’s no reason to assume a special use name is a
>> top-level name.
>>
>>
>> Suzanne
>>
>>
>>
>> --
>> Add mailing list
>> [email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Thu, 21 Nov 2019 12:57:16 +0800

> > nobody in the way can as it would not validate.

.... assuming that they validate.

In an ideal world, everybody validates, but until then someone
upstream could use this to downgrade the connection - this is a poor
failure mode, but perhaps that is just more impetus for local
validation (which also doesn't really work, because it's unclear who
exactly up the path should be allowed to do this).

> Asking for a new special-use name is usually asking for trouble for two reasons: Getting special-name reservation involves too much politics, and getting it deployed requires changes in all DNS sta…

I really dislike this entire opt-out solution, but if it is used,
something under .arpa (like others have suggested downstream) seems
less bad....

-- 
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: "Livingood, Jason" <[email-masked]>
Date: Thu, 21 Nov 2019 06:05:08 +0000

This presentation from Roy Arends may be of interest on the subject of special use domains:
https://datatracker.ietf.org/meeting/106/materials/slides-106-dnsop-sessa-draft-arends-private-use-tld

Jason

On 11/19/19, 6:53 PM, "Add on behalf of Petr Špaček" <[email-masked] on behalf of [email-masked]> wrote:

    --
    Petr Špaček  @  CZ.NIC

    --
    Add mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/add__;!rx_L75ITgOQ!TslM0ZIZF5gy7_Qsjd2svEk1G1qkb6NvSS5g5p2kEL5jLX0c8BaW08l-hjpIgRKAWrkezw$

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 21 Nov 2019 07:26:23 +0100 (CET)

> Il 21 novembre 2019 05:57 Warren Kumari <[email-masked]> ha scritto:
> 
> something under .arpa (like others have suggested downstream) seems less bad....

If I may broaden the discussion a little... 

The introduction of the canary domain was a positive and appreciated step by Mozilla to deal with the immediate problems caused by their DoH deployment model. At the same time, however, it is a conceptual nonsense: if you pick a deployment model that bypasses the local network and resolver because you do not trust them, then it does not make sense to ask them whether you should actually turn DoH on or not.

(Personally, I think that Mozilla's need for this mechanism is also a sign that the entire deployment model is conceptually flawed, but I do not ask them to share this conclusion.)

It is just a matter of time before some entity that uses the local resolver in ways Mozilla do not like turns the canary on, and then they will have to implement additional logic to distinguish proper and improper uses of the canary, or give up the entire mechanism altogether.

So, before we get to that point, we should already think at what could be a better way to deal with a problem which could be formulated as "distinguishing between good and bad local networks" or "getting policy indications from the local network in a secure, authenticated way that could also allow the client to take decisions on whether to accept or reject them".

Possibly, a good local resolver discovery mechanism could provide a solution to this problem, at least in part.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Andrew Campling <[email-masked]>
Date: Thu, 21 Nov 2019 06:46:37 +0000

> On 21 November 2019 14:26 Vittorio Bertola <[email-masked]> wrote:
>

I agree that an alternate approach would be preferred and that moving to a local resolver discovery mechanism seems like the right place to start.  Such a solution would have the advantage of likely fitting better with the approaches taken by Google and Microsoft too.  A consistent approach would be most helpful.  

Andrew

---

From: Andy Grover <[email-masked]>
Date: Thu, 21 Nov 2019 15:15:20 +0800

On 11/21/19 2:26 PM, Vittorio Bertola wrote:
> The introduction of the canary domain was a positive and appreciated
> step by Mozilla to deal with the immediate problems caused by their
> DoH deployment model. At the same time, however, it is a conceptual
> nonsense: if you pick a deployment model that bypasses the local
> network and resolver because you do not trust them, then it does not
> make sense to ask them whether you should actually turn DoH on or
> not.
Because the owner of the local network is often not the one running the
recursive resolver the network is using, usually the ISP runs it. If the
owner wants parental controls to work instead of secure DNS, then that
should be honored. The local network owner can block the canary via
something on their gateway, or maybe the ISP has some setting for
enabling DNS-based parental controls, and doing this also blocks the
canary -- for that customer only.

As you note below, the scheme falls apart if the ISP blocks the canary
for all customers. Since the canary would no longer be an accurate
heuristic for the wishes of the local network, it would make sense for
the application to stop honoring the canary for that ISP.

Therefore it would not be in the interest of the ISP to block the canary
for customers others than those that explicitly opt in to parental controls.

> (Personally, I think that Mozilla's need for this mechanism is also a
> sign that the entire deployment model is conceptually flawed, but I
> do not ask them to share this conclusion.)
> 
> It is just a matter of time before some entity that uses the local 
> resolver in ways Mozilla do not like turns the canary on, and then
> they will have to implement additional logic to distinguish proper
> and improper uses of the canary, or give up the entire mechanism
> altogether.

Give it up at least for that ISP.

> So, before we get to that point, we should already think at what 
> could be a better way to deal with a problem which could be 
> formulated as "distinguishing between good and bad local networks"
> or "getting policy indications from the local network in a secure,
> authenticated way that could also allow the client to take decisions
> on whether to accept or reject them".
I'm sure there are better ways, which I'm hoping we can work on
designing here.

> Possibly, a good local resolver discovery mechanism could provide a 
> solution to this problem, at least in part.
I don't know if it helps this particular problem, but it certainly seems
to be an important piece that is missing.

Regards -- Andy