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

[Ted Hardie <[e-mail]>]

On Wed, Nov 10, 2021 at 7:48 PM 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.
> * Same as above but requiring AD=1 in the response.
> * Perform full iterative resolution for this NS query, requiring DNSSEC.
> * etc.
>
>
This seems like it both provides too many options and like it is too easy
for someone to misunderstand or deliberately misconstrue what independent
validation counts.  I would prefer picking one or two that are fully
described in the eventual draft, with what amounts to
mandatory-to-implement language (e.g. one for v6-available and one for
v6-unavailable situations).

Obviously, we might not be able to get to that level of common practice,
but I think it will be easier for everyone if we can get close; otherwise
there will be a lot of code paths and a real risk that nothing at all gets
wide deployment.

Just my two cents,

Ted




> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>