fl1ger / deleg Goto Github PK
View Code? Open in Web Editor NEWExtensible Delegation for DNS
License: Other
Extensible Delegation for DNS
License: Other
A DELEG compliant, authoritative nameserver will include signed DELEG records, or authenticated denial of DELEG records. However, an adversary can remove these records from a response, and the resolver will treat the response as a legacy response, since there is no signed indication that DELEG or its authenticated denial should have been present.
Two methods of signed indication have been proposed.
The DNSKEY RR contains a 16 bit flag field in the RDATA. Of these, 3 have been allocated. The ZONE, REVOKE and Secure Entry Point (SEP) flag. Trivially, a fourth can be added, such as a DELEG flag. A validating resolver that observes a DELEG flag MUST expect either a signed DELEG record in a referral, or an authenticated denial record in a referral.
Advantage of this method is that it requires no additional space in a response for the signed indication.
A potential disadvantage is that state needs to be kept between observing the DELEG flag and parsing a response.
A potential disadvantage is that legacy validators may not understand the DELEG flag and ignore the key completely. That behavior is NOT standards compliant. This needs to be tested.
The DS record contains a digest field. If the validator does not recognise the digest field value, then the DS record should be ignored. This protects legacy validators from failing over unknown DS records, and in addition, it can be used as an indicator that a DELEG or its denial should be present.
Advantage of this method is that it is "legacy validator safe" (but must be tested regardless) and that the resolver doesn't have to look at the key, since the signal is in the reponse.
A disadvantage is that this is NOT what the DS record was meant to do, i.e. Yet Another Hack.
A disadvantage is that it causes yet another record in a response that already contains NS, DS, DELEG/NSEC/NSEC3 and RRSIGs.
The current text has no examples of priorty=0 with parameters, but it doesn't explicitly forbid that. Is there a reason to allow ipv4hint or ipv46hint with aliasing?
I'm not saying we should prohibit parameters for AliasMode, because there might be later parameters that could affect aliasing that we haven't thought of yet (or I could be wrong and there is a reason to have ipv4hint or ipv46hint with aliasing). But we should document what we know now.
A non-DELEG-aware ("legacy") validating stub can only use records that carry a non-DELEG DNSSEC signature chain. This seems to be incompatible with the "sharedds" mechanism proposed in the DNSSEC draft.
It's also unclear how to construct a DELEG-aware validating stub, as DELEG records are not presently passed to the stub at all.
At present, I think the result is that any query to a recursive resolver with DO=1 would require the resolver to skip any DELEG records with "sharedds", and would create some very complicated caching questions. This seems like bad news for "sharedds".
When using DoT/DoQ/DoH, but not using DANE (no TLSA records or TLSA SvcParams), what SNI do we use? i.e. what is the Authentication Domain Name (ADN).
If DELEG follows the usual SVCB behavior, the ADN is the "apex name", and the nameserver must use a TLS certificate that covers this name (whether or not any AliasMode records appeared in the chain). However, this is very awkward for operational delegation scenarios: most businesses would not want to hand their DNS operator a valid certificate to impersonate their apex domain, enabling a trivial MITM attack (and bypassing Certificate Transparency protections!). Even in self-hosted infrastructure, using the high-value apex certificate in the DNS server may be difficult.
When DANE is in use, this problem is avoided because, in DANE modes where the ADN exists, the ADN is determined by the final TargetName, not the original owner name (as specified in SVCB-DANE).
There are many possible behaviors. The ADN could be:
https://github.com/martinthomson/i-d-template allows to easily create gh-pages of the documents, making them available in both .txt and .html format and viewable as HTML via github pages. For example: https://martinthomson.github.io/i-d-template/sample.html
This makes reading the document easier, but the repo also comes with a bunch of tooling/linting enforcement that will help keeping the document syntax valid. It will also make the workflow with IETF datatracker smoother.
I am not sure how this repo was created, but it would be nice to be able to generate the GH pages for it.
I gave a try on my repo and generated the GH pages.
index
deleg draft
using this branch: https://github.com/chantra/fl1ger-deleg/commits/fix_md_formats/
There is 2 commits there.
One question that has already come up is why a new DELEG RRtype that looks just like SVCB is needed instead of reusing SVCB. A sentence or two near the top of the document would be useful here.
Assume a signed DELEG record for example.com, with TargetName ns1.example.com and IPv4hint=192.0.2.1
Assume a delegation point NS record for example.com, with an NSDNAME ns1.example.com
Assume a glue address record (served by the server authoritative for .com) for ns1.example.com with address 192.0.2.2
Assume a hostname ns1.example.com with A record 192.0.2.3, in the example.com zone.
example.com is not a signed zone.
The DELEG record contains a signed binding between ns1.example.com and address 192.0.2.1.
All other records can be spoofed by an adversary.
The SVCB specification specifies that when A records for TargetName are locally available, the client SHOULD ignore these hints.
In short, the SVCB instruction here is to "trust" the unsigned "192.0.2.3" or "192.0.2.2" over "192.0.2.1". Experience tells me that there will be mismatches between parent and child records.
The same is true for IPv6, but have left this out to not convolute this example. We need clear instructions and rationale for developers.
This is minor, but just wanted to put it out there.
When only a DELEG and Authenticated Denial record exist at a delegation point, and no NS and DS, then a referral response can be replayed as an NXDOMAIN response to legacy validators. However, legacy resolvers can't use this referral anyway, due to the absence of NS records. Ergo, it is highly unlikely that NS records will ever go away.
If a DNS server is
what should it serve to a query for foo.example.com/A?
A non-DELEG-aware resolver requires a referral response to the nameserver that is authoritative via NS. A DELEG-aware resolver needs an answer to the question. The authoritative server doesn't know which kind of resolver is asking the question.
This distinction is especially apparent if we imagine that DELEG has overridden the DS record, using a different DS from the one that applies to the NS delegations.
For the same reason explicit DS records need to work:
DS records are obscured when parent and child are hosted on the same server. Only an explicit DS request can establish a chain of trust. As an example, UK and CO.UK are hosted from the same server set, and explicit DS queries are needed to establish a chain of trust.
This can be made to work in the authoritative server by treating DELEG requests the same way as DS requests.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.