On 2024-10-24 09:28 +11, Jen Linkova <furr...@gmail.com> wrote:
> On Tue, Oct 22, 2024 at 1:42 AM Florian Obser <florian+i...@narrans.de> wrote:
>> It occurred to me that a validating stub resolver still needs to know if
>> its upstream is messing with DNS. With RFC9606 we can just ask the
>> resolver what it's doing, so I put up
>> https://datatracker.ietf.org/doc/draft-fobser-resinfo-dns64/
>>
>> A validating stub can then avoid that resolver or do more fancy things
>> like spotting that the resolver did DNS64 synthesis, ignore that answer
>> and do its own synthesis using the 8781 prefix...
>
> Do you think it might be useful to explain those scenarios in the draft?
> Because an uneducated reader (like me) might wonder "why does the
> resolver need to know" and "what problem does this new feature
> solve?".
Yes, thanks for requesting this. Turns out I was wrong, I'm always
forgetting about the CD (checking disabled) flag.
I went back to RFC 6147 and re-read
5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode
All the way at the end it has:
3. If the CD bit is set and DO is set, then vDNS64 MAY perform
validation, but MUST NOT perform synthesis. It MUST return the
data to the query initiator, just like a regular recursive
resolver, and depend on the client to do the validation and the
synthesis itself.
I also went back to check my code and it does the right thing. Basically
a validating DNS client that talks to an upstream resolver MUST set DO
and CD if it wants to do its own validation. That is true regardless of
DNS64.
I'm preparing an -02 that rips out all the DNSSEC commentary to not have
a draft with misleading information lingering. Maybe someone over in ADD
still has use for this, but I only need PREF64. 7050 can just go away ;)
Thanks,
Florian
>
> P.S. Thank you for posting -01 and removing yet another way to
> discover the prefix ;)
>
> --
> Cheers, Jen Linkova
--
In my defence, I have been left unsupervised.
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
