Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compact DNSSEC Denial of Existence support #857

Open
Tazmaniac opened this issue Nov 7, 2022 · 3 comments
Open

Compact DNSSEC Denial of Existence support #857

Tazmaniac opened this issue Nov 7, 2022 · 3 comments
Labels
Enhancement Request Future A longer term issue, possibly addressed in the future.

Comments

@Tazmaniac
Copy link

Tazmaniac commented Nov 7, 2022

Would you mind implementing NXDOMAIN synthesis in case of "Black Lies" presence ?

Motivation
Compact DNSSEC Denial of Existence or "Black Lies" is a Cloudflare proprietary DNSSEC protocol modification unilaterally deployed in their infrastructures and later adopted by other big actors ( Route53, NS1).

Black Lies are "mostly" compatible with DNSSEC. They don't break validation but have two impacts:

  • Non existent entry no longer generate NXDOMAIN status code.
  • ENT (Empty Non Terminal) entry are no longer distinguishable from NXDOMAIN (Route53), difficult to identify reliably (Cloudflare) or need additional support to be identified (NS1)

As we don't control how the resolver used will do iterative query for specific destinations (Cloudflare correctly generate NXDOMAIN for queries without EDNS or DO bit), and because good resolvers do requests with EDNS and DO bit (and do validation), we should implement black lies decoding to properly return NXDOMAIN to applications witch rely on this status code.
Applications relying on ENT identification are rare and distinguish-ability between NXDOMAIN and real NODATA is the same (Cloudflare, NS1): NSEC bitmap exactly covering "RRSIG NSEC" types.

The "Black Lies" hack could not be properly fixed/addressed on the resolvers(servers) side, but is a reality with which we should live until the implementers change their mind or is superseded by a new better standardized mechanism.
Client code that rely on obtaining correct DNS response codes needs a reliable way of inferring the real response status in spite of these hacks. Having this possibility on the client side, on the stub resolver is sadly the only viable option today.

Describe the solution you'd like.
Having an option on the stub resolver (like "raise_on_blacklies") which when true:

  • imply EDNS0 and DO on the resolver configuration or error out.
  • blacklies detection/decoding on NODATA condition is performed and NXDOMAIN is raised in case of successful decoding.

Reference:
https://github.com/shuque/blrcode
https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00
https://datatracker.ietf.org/doc/html/draft-huque-dnsop-blacklies-ent-01

@rthalley
Copy link
Owner

I will consider something like this in the dnspython 2.4 timeframe, as while "minimal lies" is generally not a problem, it can cause issues if using search lists (which I don't recommend, but which are sometimes needed).

@rthalley
Copy link
Owner

rthalley commented Nov 3, 2023

Just an update that I haven't forgotten about this ticket. There is active IETF work in this area, we will see what happens.

@Tazmaniac
Copy link
Author

Thank you.
For those following this ticket see : https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-compact-denial-of-existence-01
There is very promising progress.

It is urgent to wait as the current in the field status is a complete mess with implementations indistinguishable from others.
Anyway there is light at the end of the tunnel as qname minimization force IETF to regulate/standardize theses de-facto practices pushed by online-signers.

@rthalley rthalley added the Future A longer term issue, possibly addressed in the future. label Nov 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Request Future A longer term issue, possibly addressed in the future.
Projects
None yet
Development

No branches or pull requests

2 participants