[dns-operations] Cloudflare TYPE65283

[Emmanuel Fusté]

Le 27/03/2023 à 14:34, Petr Špaček a écrit :
> On 27. 03. 23 13:31, Emmanuel Fusté wrote:
>> Le 27/03/2023 à 12:37, Emmanuel Fusté a écrit :
>>> Le 27/03/2023 à 12:14, Joe Abley a écrit :
>>>> Hi Emmanuel,
>>>>
>>>> On Mon, Mar 27, 2023 at 10:51, Emmanuel Fusté 
>>>> <manu.fuste at gmail.com> wrote:
>>>>> Cloudflare start to return TYPE65283 in their NSEC records for 
>>>>> "compact
>>>>> DNSSEC denial of existence"/"minimal lies" for NXDOMAINs.
>>>>> It actually break "minimal lies" NXDOMAIN established decoding
>>>>> implementations.
>>>>> Does someone know the TYPE65283 usage/purpose in this context ?
>>>>
>>>> If a compact negative response includes an NSEC RR whose type 
>>>> bitmap only includes NSEC and RRSIG, the response is is 
>>>> indistuishable from the case where the name exists but is an empty 
>>>> non-terminal. Adding a special entry in the type bitmap avoids that 
>>>> ambiguity and as a bonus provides an NXDOMAINish signal as a kind 
>>>> of compromise to those consumers who are all pitchforky about the 
>>>> RCODE. The spec currently calls that special type NXNAME.
>>>>
>>>> https://www.ietf.org/archive/id/draft-huque-dnsop-compact-lies-01.txt 
>>>> <https://www.ietf.org/archive/id/draft-huque-dnsop-compact-lies-01.txt>
>>>>
>>>> The spec is still a work in progress and the NXNAME type does not 
>>>> have a codepoint. I believe TYPE65283 is being used as a 
>>>> placeholder. I think Christian made a comment to that effect on 
>>>> this list last week, although I think he may not have mentioned the 
>>>> specific RRTYPE that was to be used.
>>>>
>>>> If this has caused something to break, more details would be good 
>>>> to hear! 
......
>> Ok, replying to myself.
>> TYPE65283 is as you stated the place holder for a future NXNAME.
>> So they silently break their previous implementation to implement 
>> half of this this draft.
>> Their previous NXDOMAIN implementation correspond to draft ENT case, 
>> but they still implement their old way for ENT.
>> Thank you for the pointer.
>
> Could you elaborate on the type of breakage you mentioned?
>
> What got broken, specifically?
>
Client side previous draft NXDOMAIN status decoding as originally 
encoded by Cloudflare.
Having application relying on the NXDOMAIN status passed by the API, we 
where forced to add simple minimal lies decoding on the stub resolver 
(we don't want to disable DNSSEC validation on our trusted resolver or 
do special treatments on it for theses clients).
The decoding is based on exactly the presence of RRSIG and NSEC in the 
NSEC record.
The NS1 extension for restoring simple ENT identification is compatible 
with this scheme as for ENT you get RRSIG NSEC and TYPE65281.

Now I need to explicitly strip (or special case) TYPE65283 to restore 
NXDOMAIN identification from Cloudflare and still identify NXDOMAIN on 
NS1 and NXDOMAIN or ENT on Route53.
If Cloudflare switch to this draft for the ENT case too, it will became 
as worse as Route53 and only NS1 will give distinguishable real NXDOMAIN.
Or ALL compact lies response implementer should switch to this new draft 
and be known to have switched.

I am missing something? (truly possible :-) )

Emmanuel.