[dns-operations] Cloudflare TYPE65283

[Petr Špaček]

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

You got me curious: What is the use-case depending on this? I mean, from 
reading the DNS spec _alone_ it's not clear why any of variants in use 
should cause serious problems if it's done correctly.

-- 
Petr Špaček
Internet Systems Consortium