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