[dns-operations] Cloudflare TYPE65283

[Emmanuel Fusté]

Le 27/03/2023 à 15:38, Petr Špaček a écrit :
> 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".
>
Yes, I perfectly understand this position toward drafts in the common 
IETF sense/usage.
But as these drafts where and are imposed to us unilaterally on the 
whole Internet since years by majors DNS service providers they are 
sadly de-facto standards.

Emmanuel.