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

On Thu, 11 Nov 2021 at 01:18, Ben Schwartz <bemasc=
40google.com@dmarc.ietf.org> wrote:

>
>
> On Wed, Nov 10, 2021 at 12:43 PM Dan Wing <danwing@gmail.com> 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.

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

-Tiru

> * etc.
>
> If a network signs their domains, any participating clients will accept
> the delegation.  Otherwise, some compliant clients might ignore the
> instruction because it fails their validity check.  That seems fine to me.
> Many clients won't implement this at all, so operators already can't rely
> on it unless they have knowledge of a specific client's behavior.
>
> **This is harder than it sounds due to chain-walking, loose consistency,
> etc.
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>