You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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).
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.
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:
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:
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
The text was updated successfully, but these errors were encountered: