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

[Ben Schwartz <[e-mail]>]

On Fri, Nov 12, 2021 at 2:38 AM tirumal reddy <[e-mail]> wrote:

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

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

There have occasionally been suggestions in this working group that clients
might want to run full resolvers locally for privacy reasons.  However, I
was specifically referring to the problem of resolving full DNSSEC chains
as a stub.  Resolvers do not ordinarily provide the full chain to the stub
(absent RFC 7901), so validation requires the stub to walk "up" the chain,
querying for DNSKEY and DS records.  This is not easy to do correctly and
is not available in most stub resolver implementations.  It may be simpler
for the client to walk "down" the chain using a standard iterative resolver
implementation.