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

[tirumal reddy <[e-mail]>]

On Thu, 11 Nov 2021 at 17:39, Ben Schwartz <[e-mail]> wrote:

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

Works for me.


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

Okay.


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

I don't get how iterative resolution is better for the stub resolver than
the typical recursive mode.

-Tiru