Re: [Add] some background on split DNS with DNSSEC

[Ben Schwartz <[e-mail]>]

On Thu, Nov 11, 2021 at 1:01 AM tirumal reddy <[e-mail]> wrote:

> On Thu, 11 Nov 2021 at 01:18, Ben Schwartz <bemasc=
> [e-mail]> wrote:
>
>>
>>
>> On Wed, Nov 10, 2021 at 12:43 PM Dan Wing <[e-mail]> wrote:
>>
>>> On item 3,
>>>
>>> We could use DNSSEC to prove the PvD dnsZones is truthful to avoid
>>> asking the same question of the public DNS.
>>>
>>> However, we already need IPv6 (for RFC8801's PvD) and adding a DNSSEC
>>> requirement means we are deeper in the "room of non-deployability", a
>>> dreaded space for our D&D character.  That's why split-dns queries the
>>> public DNS:  the procedure in split-dns establishes a *similar* proof of
>>> domain ownership as DNSSEC could have provided.
>>>
>>
>> I think the right approach for this draft is to say that the client
>> should acquire independent confirmation of the delegation's validity before
>> proceeding, and not get too specific about how it should do that.  Valid
>> client behaviors should include:
>> * Send the NS query through the network's resolver and require a valid
>> DNSSEC signature chain**.
>> * Send the NS query through a trusted third-party resolver over a secure
>> channel.
>>
>
> Yes, first try DNSSEC and if it fails, fallback to a third-party resolver
> for the dnsZones domains. It allows the network admin to either deploy
> DNSSEC for split-horizon domains or use the existing mechanism proposed in
> the draft depending on the operational feasibility. It will also work for
> clients not validating DNSSEC. We will update the draft.
>

The group is not chartered to specify client or network operator resolver
selection policy, so I don't think it is a good idea to try to specify this
in the draft.  In my view, the important thing is to provide the mechanism
(normative) and inform each party of the relevant security considerations.


> * Same as above but requiring AD=1 in the response.
>> * Perform full iterative resolution for this NS query, requiring DNSSEC.
>>
>
> Please clarify the need for the above two mechanisms.
>

The first is effectively "delegated DNSSEC validation".  This is useful for
a client whose threat model includes network attackers on the public
internet, if it doesn't want to implement full DNSSEC validation locally.

The second is a valid client behavior.  It will work, and under our charter
we can't rule it out.  It also might work better in practice than
DNSSEC-via-network-resolver because stub-side DNSSEC validation is
nontrivial due to the need for chain walking.