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é
<[email protected]> 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
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
