Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-add-enterprise-split-dns-00.txt

From: tirumal reddy <[email-masked]>
Date: Mon, 1 Mar 2021 19:09:17 +0530

Hi Ben,

Please see inline

On Fri, 26 Feb 2021 at 20:54, Ben Schwartz <[email-masked]> wrote:

>
>
> On Fri, Feb 26, 2021 at 5:09 AM tirumal reddy <[email-masked]> wrote:
>
>> Hi Ben,
>>
>> Thanks for the review. Please see inline.
>>
>> On Wed, 24 Feb 2021 at 02:20, Ben Schwartz <[email-masked]> wrote:
>>
>>> This draft contains a large amount of veiled policy argumentation and
>>> outright specification of client policy.  That material is out of scope for
>>> this working group.
>>>
>>
>> PvD can be used to provide the network configuration information, see
>> https://tools.ietf.org/html/rfc7556. If the WG thinks it is useful but
>> not in scope, we can discuss to enhance the scope; otherwise will remove
>> the text.
>>
>
> The Introduction section largely discusses access policies and how
> networks can override the client's preferences.  This is not in-scope.
> Additionally, the normative text contains requirements like
>
>    For each dnsZones entry, the client MUST use the network-provided DNS
>    servers as the only resolvers for the listed domains and its
>    subdomains and it MUST NOT attempt to resolve the provided DNS
>    domains using public resolvers.
>
> That's explicitly specifying client policy, which is out of scope for ADD.
>

That's a fair point, will remove the normative text.

>
>
>>
>>> Apart from that issue, the draft's quote from RFC 2826 quite expressly
>>> forbids the technical approach taken in this draft.  RFC 2826 says
>>> "if [private networks] wish to make use of names uniquely defined for
>>> the global Internet, they have to fetch that information from the global
>>> DNS naming hierarchy".  RFC 2826 later clarifies
>>>
>>> > The
>>> > requirement for uniqueness within a domain further implies that there
>>> > be some mechanism to prevent name conflicts within a domain.  In DNS
>>> > this is accomplished by assigning a single owner or maintainer to
>>> > every domain, including the root domain, who is responsible for
>>> > ensuring that each sub-domain of that domain has the proper records
>>> > associated with it.  This is a technical requirement, not a policy
>>> > choice.
>>>
>>> In my view, any draft that defines a modified lookup procedure must
>>> therefore ensure that it is not altering the party who controls the
>>> contents of any defined global domain.  This could work by first checking
>>> that a given name does not exist in the global namespace, or by providing
>>> evidence that the local network operator is the party responsible for the
>>> global name.
>>>
>>
>> If the client queries a public resolver to check if the private DNS names
>> exist in the global namespace, it would leak the private sensitive names
>>
>
> Yes
>
>
>> to the public resolver and adversely impact privacy.
>>
>
> I disagree.  The client has a choice of resolvers to which to send its
> queries.  That choice impacts their privacy, and so the client makes that
> choice on the basis of their perception of the resolvers' privacy posture.
> If the client chooses to direct queries to a public resolver, it is because
> they have decided that this choice is not adverse to their privacy.
>

I partially agree, it also adversely impacts the privacy of the enterprise
network (leaking the private domains names to a public resolver).

>
>
>> Alternatively the client can use bloom-filter of well-known domains to
>> check if the name does not exist in the global namespace
>>
>
> This is a fun idea!  I think this is a research topic for now but it's a
> good puzzle.  While we're talking about tricky ways to find nonexistent
> domains, you could also imagine using NSEC to prove the nonexistence of a
> name in a zone without revealing the name to the resolver. (Even better
> with NSEC3.)
>

Yes, authenticated denial of existence using NSEC3 is a good way to prove
the domains do not exist in the global DNS. We will update the draft.

I suggested bloom-filter to avoid leaking the sensitive private domain
names to a public resolver. Any specific reason for saying it is a research
topic when browsers like Chrome already use it identifying
malicious domains ?

> ...
>
>> I did not get the latter part of the comment : How would the local
>> network operator provide evidence that it claims authority over a global
>> name ?
>>
>
> The simplest way would be to do an NS query for a zone, and see that one
> of the listed nameservers is the network's local DNS server.
>

The Enterprise nameservers and network-provided resolvers need not be
co-located on the same IP address. How would this proposed mechanism work ?

>
> Further, it is quite common in split DNS for an authoritative server to
>> give different responses to queries from the Internet than queries from
>> devices attached to the network (see
>> https://tools.ietf.org/html/rfc6950#section-4).
>>
>
> Yes, that seems fine.
>

Okay but NSEC3 would not work in this case. How would the client determine
if the domain is indeed owned by the network ?

Cheers,
-Tiru

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 1 Mar 2021 09:53:35 -0500

On Mon, Mar 1, 2021 at 8:39 AM tirumal reddy <[email-masked]> wrote:
...

> That's a fair point, will remove the normative text.

Thanks!

...

> network (leaking the private domains names to a public resolver).

In my view, "privacy" is a concept that only applies to individual human
beings.  Networks and organizations don't have a "privacy" interest.

Network administrators may be trying to keep these names "confidential".  I
don't think we should be trying to support this use case, because it is
extremely fragile and likely to backfire, but I understand that some people
feel it is worthwhile.

> topic when browsers like Chrome already use it identifying

In this context, I believe you are proposing to ship every client with a
Bloom filter representing all domains in the DNS.  This filter must have
broad enough coverage to detect most attempts to override a third-party
domain, and a low enough false positive rate to accept most nonexistent
names.  It must be updated regularly as new names are added to the DNS.
Specified this way, I believe this is not practical to implement.

Perhaps there is some alternative formulation that makes this more
practical (e.g. hierarchical filters by label, fallback checks on a
positive result, differential updates, etc.) but it's not clear to me that
this can actually be implemented.  I think it's an interesting research
project but far from standardization.

The "Safe Browsing" use case is considerably easier due to the smaller set
size (only malicious domains) and good false-positive mitigations (fetch a
chunk of the full set for an exact match check).

...
> co-located on the same IP address. How would this proposed mechanism work ?

It might be best to identify servers by name, matching the NS name to the
name specified in DHCP (as in your "home" draft).

> if the domain is indeed owned by the network ?

As above, using the NS record (or any similar means to show that this
resolver is actually authoritative for the domain).

---

From: Paul Vixie <[email-masked]>
Date: Mon, 1 Mar 2021 18:26:08 +0000

> beings.  Networks and organizations don't have a "privacy" interest.

it is my organization's policy that my individual humans (family, customers,
employees, visitors) have privacy. so, this distinction is non-operative.

> extremely fragile and likely to backfire, but I understand that some people

for some of us it's a must-have, and the fragility must be embraced & limited.

-- 
Paul Vixie

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Mar 2021 21:33:17 +0000

Hiya,

> employees, visitors) have privacy. so, this distinction is non-operative.

I strongly disagree with Paul/Tiru and strongly agree with
Ben.

To the extent I understand it at all, privacy is not a thing
that can be enjoyed by corporations or computer networks of
any kind.

Corporations may or may not have policies related to the
privacy of people they employ or that use their networks, but
that doesn't imply that the thing controlling the policy can
be said to enjoy or want privacy itself. (And practically,
I've never ever come across a network or corporate policy
that didn't set out to at least somewhat reduce the privacy
of employees or users.)

Corporations clearly do have confidentiality requirements,
but that's not at all the same thing.

The reason I call this out is that I've seen a number of
cases where such claims were made that seemed dubious to me
in that accepting those claims, and that proposed equivalence
(in language), seemed tantamount to accepting that corporate
requirements for confidentiality trump the human need for
privacy. And I don't accept that.

Cheers,
S.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 2 Mar 2021 03:21:29 +0000

On Mon, Mar 01, 2021 at 09:33:17PM +0000, Stephen Farrell wrote:
> > it is my organization's policy that my individual humans (family,
> > customers, employees, visitors) have privacy. ...
> 

i re-read what i wrote, then i read how you answered, then i did it
again, two more times. i conclude that you are not disagreeing with
what i wrote, though you claim to be.

> be said to enjoy or want privacy itself. ...

i did not say what you're arguing against here, even though you seem
to claim that i have.

> but that's not at all the same thing.

which was not the topic of my remarks.

> privacy. And I don't accept that.

at this point i don't know what you're talking about, much less what
you won't accept.

-- 
Paul Vixie

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 2 Mar 2021 11:00:21 +0100 (CET)

> Il 02/03/2021 04:21 Paul Vixie <[email-masked]> ha scritto:
> 
>  

You seem to be discussing around word meanings. "Privacy" in the stricter sense of protection of personal information is a prerogative of physical persons, while "privacy" in the broader sense of confidentiality of communications applies to any entity, both legal and physical. By the way, confidentiality of communications is also a constitutional right in many jurisdictions.

I would rather focus the discussion on the substantial issue of whether the leak of private names onto the public DNS infrastructure is a problem or not - I'd say it is, for security reasons first of all.

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

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 2 Mar 2021 10:17:45 -0500

On Tue, Mar 2, 2021 at 5:01 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:
...

> I would rather focus the discussion on the substantial issue of whether
> the leak of private names onto the public DNS infrastructure is a problem
> or not - I'd say it is, for security reasons first of all.
>

Your phrasing assumes the existence of "private names" whose publication
would constitute a "leak".  Yes, if your security model makes this
assumption, then you will have a problem when it fails.

In my view, this is a bad security model for typical user devices.  Users
have a tendency to move their devices between networks, misspell the secret
names, try to access corporate services from their home computer, etc.  I
am reminded of the adage: "there is no such thing as a widely shared
secret".  (For IoT deployments and limited-function user terminals, it
might be a less dangerous assumption.)

Luckily, we don't need to reach consensus on this point.  We are limited by
charter not to tell clients or administrators how to run their devices and
networks.  If the network and devices are all managed by the same entity,
then they are free to pursue whatever configuration they like.

---

From: Joe Abley <[email-masked]>
Date: Tue, 2 Mar 2021 10:59:54 -0500

Hi Ben,

On Mar 2, 2021, at 10:18, Ben Schwartz <bemasc=[email-masked]> wrote:

> On Tue, Mar 2, 2021 at 5:01 AM Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> ...
> Your phrasing assumes the existence of "private names" whose publication would constitute a "leak".  Yes, if your security model makes this assumption, then you will have a problem when it fails.

It seems to me that many security models make this assumption. The use of private namespaces is commonplace in many kinds of network (not just enterprise networks). Collisions between different such namespaces, and between such namespaces and the global namespace are frequent and are known to pose threats. I agree that the nature of those threats depends very much on context and circumstances.

Are you saying that you doubt the existence of "private names", or that you don't like them?

Joe

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 2 Mar 2021 11:15:00 -0500

On Tue, Mar 2, 2021 at 11:00 AM Joe Abley <[email-masked]> wrote:
...

> Are you saying that you doubt the existence of "private names", or that

Neither, in this thread.  I am saying that if your network contains
internal-only resources identified by DNS names, you shouldn't base your
security on the assumption that those names are secret.  Given enough time,
the probability of an attacker learning those names approaches 1.  If you
want to keep a secret, like a password or a private key, it has to be
shared narrowly and rotated regularly.

I also think this topic is largely out of scope for ADD.

---

From: tjw ietf <[email-masked]>
Date: Tue, 2 Mar 2021 11:28:33 -0500

I agree with Ben here on scope 

I Would argue that split view DNS is an attack vector in waiting. 

Tim

Sent from my iPhone

> On Mar 2, 2021, at 11:15, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 
> Neither, in this thread.  I am saying that if your network contains internal-only resources identified by DNS names, you shouldn't base your security on the assumption that those names are secret.  Given enough time, the probability of an attacker learning those names approaches 1.  If you want to keep a secret, like a password or a private key, it has to be shared narrowly and rotated regularly.
> 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: Jim Reid <[email-masked]>
Date: Tue, 2 Mar 2021 16:47:20 +0000

> On 2 Mar 2021, at 16:15, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> Neither, in this thread.  I am saying that if your network contains internal-only resources identified by DNS names, you shouldn't base your security on the assumption that those names are secret.

I very much doubt anyone is saying otherwise.

If anything, DoH deployment pretty much guarantees the non-security of internal names because the use of third-party resolvers (think Firefox’s TRR list) will surely leak those names to the outside.

> I also think this topic is largely out of scope for ADD.

If “this topic” is the security of internal-only names, I agree. If the topic is discovery of resolvers in networks which use internal-only names and/or split DNS, IMO that is in scope for this WG.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 3 Mar 2021 06:23:02 +0000

> > or not - I'd say it is, for security reasons first of all.

i wouldn't have put my concern in quite that form. all private identifier
uses are leaky, as any ISP who looks at their RFC 1918 outbound traffic
can demonstrate. or, consider RFC 6305. fortunately, ben's response moved

> assumption, then you will have a problem when it fails.

if the leak is accidental, there's an opportunity to detect it and learn
from it. when it is engineered, not so. it's the latter case i'd prefer to
discuss.

> In my view, this is a bad security model for typical user devices.

i'm pretty sure you don't want to be seen forcing other network operators
to use or abandon security policies or network management technologies
according to your preferences. after all, others may have concerns,
constraints, or powers that you know nothing about.

> then they are free to pursue whatever configuration they like.

so, there it is, the central knot in the woodwork. noone is asking for what
you're arguing against, and what you're arguing for is a misapplication of the
charter.

of course noone can force a network operator to adopt new ways. no protocol
signaling can have that outcome, and therefore noone asking for it should be
thought to have that goal.

the WG charter does not forbid the expression of policy for other purposes
than coercion. informative policy can inform cooperation by cooperators, who
might not know what's wanted of them otherwise.

for those of us operating managed private networks, we need that informative
cooperation signaling. most real security is pretty dry. we scale it with a
lot of accounting tricks, like this one: anomaly detection.

please don't oppose the definition of signals which help a network operator
inform their users what the policy is. stop saying it can't be enforced,
because enforcement is only a tertiary goal. the secondary goal is to know
who is cooperating and who is not. the primary goal is to make cooperation
a realistic objective even at scale.

all of that is in-charter.

-- 
Paul Vixie

---

From: Alec Muffett <[email-masked]>
Date: Wed, 3 Mar 2021 07:55:39 +0000

On Tue, 2 Mar 2021 at 16:47, Jim Reid <[email-masked]> wrote:

> security on the assumption that those names are secret.
>

I agree with this, however I also recognise that some people assume that
internal domain names/subdomains are opaque to the public.

Back at Sun Microsystems we had several new offices "outed" by the
decentralised MTA-derived habit of using subdomains (e.g.
[email-masked]) in email addresses.

That said, I would like to observe:

If anything, DoH deployment pretty much guarantees the non-security of
> internal names because the use of third-party resolvers (think Firefox’s
> TRR list) will surely leak those names to the outside.
>

I do wish that people on this list would at least try to contextualise such
sweeping statements in terms of proper enterprise threat models, behaviour,
and capabilities, rather than just dunk on technologies like DoH.

Just as the enterprise administrator has a choice to be sensible and to
configure MTAs to not leak internal subdomains in email addresses and
headers, it is - or should be - possible for enterprise administrators to
use the nowadays-reasonably-inevitable MDM / device management solutions to
scamper over the configurations of their managed devices, and to get them
to use sanctioned resolvers.

If such function does not yet exist, we enterprise administrators should
demand it.

One could equally make the argument that DoH enables *better* privacy,
since - by virtue of MDM - it could enable enterprise-managed laptops which
visit coffee shops to use the enterprise's specific, internet-connected,
split-horizon resolver, under authentication, from anywhere in the world,
and without the risk of these internal domains being leaked to some random
ISP resolver which kicks them upwards to a root so that they risk landing
in DNSDB.

Often this list seems to prefer to argue the risk of everything, as opposed
to seeing the potential for DoH (other technologies?) as part of a
beneficial solution.  I find this approach disturbing.

 - alec

-- 
https://alecmuffett.com/about

---

From: tirumal reddy <[email-masked]>
Date: Wed, 3 Mar 2021 17:44:03 +0530

On Mon, 1 Mar 2021 at 20:23, Ben Schwartz <[email-masked]> wrote:

>> I partially agree, it also adversely impacts the privacy of the
>> enterprise network (leaking the private domains names to a public resolver).
>>
>
> Network administrators may be trying to keep these names "confidential".
> I don't think we should be trying to support this use case, because it is
> Bloom filter representing all domains in the DNS.
>

No, I am proposing to only store the top well-known domains and TLDs (e.g.,
see http://s3-us-west-1.amazonaws.com/umbrella-static/index.html) and the
filter is periodically regularly.

> This filter must have broad enough coverage to detect most attempts to
> override a third-party domain, and a low enough false positive rate to
> accept most nonexistent names.  It must be updated regularly as new names
> are added to the DNS.  Specified this way, I believe this is not practical
> to implement.
>

I don't think the above technique would work in a scenario where an
organization has multiple secondary-level domains (e.g., due to
mergers/acquisitions).

-Tiru

>>>> give different responses to queries from the Internet than queries
>>>> from devices attached to the network (see
>> Okay but NSEC3 would not work in this case. How would the client
>> determine if the domain is indeed owned by the network ?
>>
>

---

From: tirumal reddy <[email-masked]>
Date: Wed, 3 Mar 2021 19:50:28 +0530

On Fri, 26 Feb 2021 at 19:59, Bob Harold <[email-masked]> wrote:

> There are a few sections that say something like:
>
>    If SplitDNSAllowed is set to false, the client should not trust the
>    SplitDNSAllowed key in case of connecting to unknown or untrusted
>    networks (e.g., coffee shops or hotel networks).  For example, if
>    SplitDNSAllowed is set to false, client can choose to use a alternate
>  network to resolve the global domain names.
>
>
>
> But I see no way for a client to know whether it is in an untrusted
> network or not.
>

The scope of the draft is restricted to explicitly trusted networks. It is
similar to the way users disable VPN connection in specific networks and
VPN connection is enabled by default in other networks.

-Tiru

> --
> Bob Harold
>
>
> On Tue, Feb 23, 2021 at 3:59 AM tirumal reddy <[email-masked]> wrote:
>
>> Hi all,
>>
>>
>> https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-00
>> discusses a mechanism to inform endpoints of split-horizon DNS and their
>> DNS domains, and is compatible with encrypted DNS. It addresses the use
>> cases of DNS configuration on explicitly trusted networks presented at ADD
>> interim (please see slides 7 to 9 in
>> https://datatracker.ietf.org/meeting/interim-2021-add-01/materials/slides-interim-2021-add-01-sessa-draft-box-add-requirements-design-slides-00.pdf
>> ).
>>
>>
>> Please review the draft and provide your valuable comments.
>>
>> Cheers,
>> -Tiru
>>
>> ---------- Forwarded message ---------
>> From: <[email-masked]>
>> Date: Sun, 21 Feb 2021 at 12:16
>> Subject: New Version Notification for
>> draft-reddy-add-enterprise-split-dns-00.txt
>> To: Tirumaleswar Reddy.K <[email-masked]>, Dan Wing <[email-masked]
>> >
>>
>>
>>
>> A new version of I-D, draft-reddy-add-enterprise-split-dns-00.txt
>> has been successfully submitted by Tirumaleswar Reddy and posted to the
>> IETF repository.
>>
>> Name:           draft-reddy-add-enterprise-split-dns
>> Revision:       00
>> Title:          Split-Horizon DNS Configuration in Enterprise Networks
>> Document date:  2021-02-20
>> Group:          Individual Submission
>> Pages:          12
>> URL:
>> https://www.ietf.org/archive/id/draft-reddy-add-enterprise-split-dns-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns
>> Htmlized:
>> https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-00
>>
>>
>> Abstract:
>>    When split-horizon DNS is deployed by an enterprise, certain
>>    enterprise domains are only resolvable by querying the network-
>>    provided DNS server.  DNS clients which use DNS servers not provided
>>    by the network need to route those DNS domain queries to the network-
>>    provided DNS server.  This document informs DNS clients of split-
>>    horizon DNS, their DNS domains, and is compatible with encrypted DNS.
>>
>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 3 Mar 2021 10:10:26 -0500

...

> No, I am proposing to only store the top well-known domains and TLDs
> (e.g., see http://s3-us-west-1.amazonaws.com/umbrella-static/index.html)
> and the filter is periodically regularly.
>

Yes, I understand.  The level of confidence in this mechanism depends on
the degree of coverage.  Including all domains is impossible, but the
fraction of domains included (perhaps weighted by popularity) is the
measure of the filter's completeness.  Using a top-N domains list of some
kind is one potential approach.  However, it's not clear to me that there
is a value of N for which this would be both efficient and effective.

...

> I did not get the latter part of the comment : How would the local network
>>>>> operator provide evidence that it claims authority over a global name ?
>>>>>
>>>>
>>>> The simplest way would be to do an NS query for a zone, and see that
>>>> one of the listed nameservers is the network's local DNS server.
>>>>
>>>

It should work fine: you can list multiple resolvers in DHCP or RA-RDNSS.
The client can query NS for a domain and intersect the NS RRSet with the
local resolver list.  If one of the local resolvers is authoritative for
some domain, the client can direct its queries to that resolver.

With named resolvers (as in the "home" draft), you can even do this using a
single local resolver IP that has multiple names.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 3 Mar 2021 10:30:19 -0500 (EST)

On Wed, 3 Mar 2021, Ben Schwartz wrote:

>             In this context, I believe you are proposing to ship every client with a Bloom filter representing all domains in the DNS. 
> 
> 
> No, I am proposing to only store the top well-known domains and TLDs (e.g., see http://s3-us-west-1.amazonaws.com/umbrella-static/index.html) and the
> Yes, I understand.  The level of confidence in this mechanism depends on the degree of coverage.  Including all domains is impossible, but the fraction of
> domains included (perhaps weighted by popularity) is the measure of the filter's completeness.  Using a top-N domains list of some kind is one potential
> approach.  However, it's not clear to me that there is a value of N for which this would be both efficient and effective.

A solution like this seems a poor fit for a protocol, and also puts a
strong presumption on the client being able to handle such large inputs,
which is clearly not going to be true for IoT devices.

Furhtermore, making assumptions on how people serve zones within the
enterprise seems a shaky basis for a protocol as well.

Paul

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 3 Mar 2021 13:06:43 -0500

> enterprise seems a shaky basis for a protocol as well.

This right here what Mr Wouters says.

It's 2021 (I had to double check) and I strongly feel that most enterprises
operations have moved away from split-view DNS.

tim

---

From: Paul Wouters <[email-masked]>
Date: Wed, 3 Mar 2021 15:32:49 -0500 (EST)

> operations have moved away from split-view DNS. 

Only for those drinking the BeyondCorp kool-aid :)

If an enterprise outsources all their email, calendars, and document
management to the cloud providers, surely there is a no strong need
for a split-DNS (or VPN) anymore for devices attaching themselves to
the internet. But there is also no signalling for DNS that is relevant
here. Based on IP they can see you are just connecting to Azure or
Google or Amazon. No need to eavesdrop on DNS for "gmail.com" or
"docs.google.com".

For a lot of enterprises, their cloud development will surely use
private IP and private namespace based DNS names that they don't want
to put into public DNS, so there you will have a strong desire for
split-DNS. But there will likely not be any human-based devices in
that network, so I think there is also not much relevant DNS signaling
happening there - everything is controlled and trusted via network
credentials. And these virtual/cloud containers are all connected using
link layer security (eg MacSEC) or IP layer security (eg IPsec) so
no real win for encrypted DNS anyway.

For connecting to hotel and coffee shop networks, nothing they say
matters. You can't even tell if the starbucks wifi you are joining
inside the starbucks is actually the starbucks wifi or a rogue
device placed at the coffeeshop. You should only use their DNS to
get past the captive portal and then setup a non-split VPN to
someplace you trust. So in that case there is also no relevant DNS
signaling happening.

Which is why I see not much use for these ADD DNS signals, as I
explained during the charter discussions of this WG.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Thu, 4 Mar 2021 04:32:53 +0000

On Wed, Mar 03, 2021 at 01:06:43PM -0500, Tim Wicinski wrote:
> It's 2021 (...) and I strongly feel that most enterprises

how can this matter, even if it were true? (it's not.)

-- 
Paul Vixie

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 4 Mar 2021 09:26:29 +0100

> On Mar 4, 2021, at 5:32 AM, Paul Vixie <[email-masked]> wrote:
> 

Vixie is absolutely correct.  Split-horizon DNS is prevalent throughout enterprise, and is unfortunately many enterprises believe it to be a necessary security measure.  I mean, it’s not a bad security-through-obscurity layer in a layered defense, but if that’s actually your goal, you put it in a different zone, so it looks like you know what you’re doing.  Which they invariably don’t.  But that’s another story.

                                -Bill

---

From: tirumal reddy <[email-masked]>
Date: Thu, 4 Mar 2021 18:29:13 +0530

> is a value of N for which this would be both efficient and effective.

A value of top 100000 domains would approximately consume around 410 KiB. A
successful attack requires listing of N+1 domains and to keep dnsZones
updated as the top-N domains list changes.

Anyways, I agree it is not a full-proof technique but can potentially
detect a simple attack to list well-known domains.

>>> It might be best to identify servers by name, matching the NS name to
>>> the name specified in DHCP (as in your "home" draft).
>>>
>>

> With named resolvers (as in the "home" draft), you can even do this using
> a single local resolver IP that has multiple names.
>

Are you suggesting the local resolver certificate to have multiple names
in subjectAltName extension ?
If the discovered DNS server certificate is used to claim authority, what
is the need for NS lookup ?

-Tiru

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 4 Mar 2021 09:58:31 -0500

On Thu, Mar 4, 2021 at 7:59 AM tirumal reddy <[email-masked]> wrote:
...

>> It should work fine: you can list multiple resolvers in DHCP or
>> RA-RDNSS.  The client can query NS for a domain and intersect the NS RRSet
>> with the local resolver list.  If one of the local resolvers is
>> authoritative for some domain, the client can direct its queries to that
>> resolver.
>>
>

That's an option.  You can also use SNI-based dispatching with separate
certificates.

> is the need for NS lookup ?

The NS lookup allows support for the case where the nameserver is
out-of-bailiwick.  It also aligns architecturally with the standard
recursive resolution procedure.

Suppose we want to offer local-only names under internal.corp1.example.
The PvD would indicate that *.internal.corp1.example are internal names.
The client would verify by doing an NS query for internal.corp1.example.
Suppose the NS record indicates that the nameserver is ns1.corp2.example.
The client would then connect to the local resolver whose name is
ns.corp2.example, authenticate it, and use it for queries in that subtree.

It might be possible to avoid the NS lookup by giving the resolver the name
of the parent zone (internal.corp1.example), but I think giving it the
nameserver name is clearer, operationally preferable, and likely to align
better with protocol development now under way in DPRIVE.

---

From: tirumal reddy <[email-masked]>
Date: Fri, 5 Mar 2021 16:54:40 +0530

On Thu, 4 Mar 2021 at 20:28, Ben Schwartz <[email-masked]> wrote:

>>> With named resolvers (as in the "home" draft), you can even do this
>>> using a single local resolver IP that has multiple names.
>>>
>>

Yes.

> ns.corp2.example, authenticate it, and use it for queries in that subtree.

Sounds good to me, will update draft.  Thanks.

>
> It might be possible to avoid the NS lookup by giving the resolver the
> name of the parent zone (internal.corp1.example), but I think giving it the

How does it align with the protocol development work in DPRIVE (are you
referring to authenticated encryption between recursive and authoritative
servers) ?

-Tiru

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 5 Mar 2021 09:20:53 -0500

...

> referring to authenticated encryption between recursive and authoritative

Yes.  Most of the proposals in DPRIVE assume that the resolver will
authenticate the nameserver to the name in the NS record.