[dns-operations] Cloudflare TYPE65283

[Petr Špaček]

On 27. 03. 23 15:27, Emmanuel Fusté wrote:
> 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.

Thank you, that explains it!

I simply did not expect changes to draft implementations to be called 
"breakage".

-- 
Petr Špaček
Internet Systems Consortium