[dns-operations] Cloudflare TYPE65283

[Emmanuel Fusté]

Le 27/03/2023 à 19:19, Viktor Dukhovni a écrit :
> On Mon, Mar 27, 2023 at 06:30:02PM +0200, Emmanuel Fusté wrote:
>
>>> Do you have a list of operators that currently return just "RRSIG NSEC"
>>> for ENTs?  Do you [know] what software they are running?
>> I double check: route53/AWS currently return just "RRSIG NSEC"for ENTs.
> Anyone else?
Need to investigate in my dataset, but from the tree I know for sure 
(Cloudlfare, NS1, Route53), it is the only one doing this.
>
>> Even worse, it seems that they infer answers to non edns or cleared DO
>> bit questions from a internal DNSSEC response even for non DNSSEC
>> enabled zone:
> I am struggling to understand this, can you give an example?

This is just a (perhaps bad) AWS implementation guessing of why ENT is 
broken on AWS on non DNSSEC zones or non DNSSEC answers as for DNSSEC 
client you could not distinguish ENTs and NXDOMAINs too.

Take an ENT for witch AWS return "RRSIG NSEC" when requested with the DO 
bit.
Do the same request without the DO bit, you will get NXDOMAIN status.

The result is consistent : broken ENT with or without DNSSEC, as it 
would be if you do the minimal response decoding client side to 
synthesize the NXDOMAIN status for your application.

We could imagine anything "explaining" this consistency in the 
implementation, but it deserve no purpose I agree.
>> - they currently return NXDOMAIN for ENT on apparently non DNSSEC signed
>> zones.
> The ENT handling at AWS has been known to be broken for some time.
>
>      https://twitter.com/VDukhovni/status/1443681398905360384
>      https://twitter.com/VDukhovni/status/1445236728269258753
>
>>> The only other option is to introduce yet another sentinel that signals
>>> that the node in question is an ENT, so that the bare "RRSIG NSEC"
>>> combination is ultimately never used.
>> Yes it was my conclusion too.
> I am not entirely keen on yet another sentinel, but feel free to suggest it.
> The draft is currently under discussion.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20230327/2755cf28/attachment.html>