{"id":19070719,"url":"https://github.com/powerdns/parent-signals-dot","last_synced_at":"2026-02-09T16:31:21.734Z","repository":{"id":56162586,"uuid":"255726106","full_name":"PowerDNS/parent-signals-dot","owner":"PowerDNS","description":"Work towards a draft for parent-side signaling of DoT in delegated domains","archived":false,"fork":false,"pushed_at":"2020-11-23T12:00:22.000Z","size":299,"stargazers_count":3,"open_issues_count":7,"forks_count":3,"subscribers_count":10,"default_branch":"master","last_synced_at":"2026-02-06T13:05:09.668Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"SCSS","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/PowerDNS.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2020-04-14T21:05:30.000Z","updated_at":"2024-12-11T01:18:37.000Z","dependencies_parsed_at":"2022-08-15T13:50:47.890Z","dependency_job_id":null,"html_url":"https://github.com/PowerDNS/parent-signals-dot","commit_stats":null,"previous_names":[],"tags_count":2,"template":false,"template_full_name":null,"purl":"pkg:github/PowerDNS/parent-signals-dot","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PowerDNS%2Fparent-signals-dot","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PowerDNS%2Fparent-signals-dot/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PowerDNS%2Fparent-signals-dot/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PowerDNS%2Fparent-signals-dot/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/PowerDNS","download_url":"https://codeload.github.com/PowerDNS/parent-signals-dot/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/PowerDNS%2Fparent-signals-dot/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29272724,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-09T13:47:44.167Z","status":"ssl_error","status_checked_at":"2026-02-09T13:47:43.721Z","response_time":56,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-09T01:20:10.068Z","updated_at":"2026-02-09T16:31:21.716Z","avatar_url":"https://github.com/PowerDNS.png","language":"SCSS","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Goal\n\nFigure out a way to signal DoT support (which would then be mandatory to avoid downgrade attacks) for a domain, from the delegation side, like DS records do for DNSSEC.\nIdeally, this would support some kind of pinning.\n\n# Previous work\n\nManu Bretelle, IETF 104 dprive\n\n1. [presentation: DoT For insecure delegations](https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations)\n1. [draft-bretelle-dprive-dot-spki-in-ns-name: Encoding DNS-over-TLS (DoT) Subject Public Key Info (SPKI) in Name Server name](https://tools.ietf.org/html/draft-bretelle-dprive-dot-spki-in-ns-name-00). Problem: NS name in delegation is not signed.\n1. [draft-bretelle-dprive-dot-for-insecure-delegations: DNS-over-TLS for insecure delegations](https://tools.ietf.org/html/draft-bretelle-dprive-dot-for-insecure-delegations-01). Problems: new parent-side DSPKI RRtype requires changes in DNS auth servers and resolvers; pin is limited to the server certificate, not anything higher in the chain.\n\nStéphane Bortzmeyer, dprive\n\n1. [Encryption and authentication of the DNS resolver-to-authoritative communication](https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth-01). Relies on TLSA in the zone hosting the NS name. Problems: inconvenient indirection; relies on DNSSEC in the zone hosting the NS name; lookup of the TLSA is not encrypted.\n\nT. April, IETF 107 dnsop:\n\n1. [draft-tapril-ns2](https://datatracker.ietf.org/doc/draft-tapril-ns2/). New `NS2` and `NS2T` RRtypes. Covers DoT, DoH, DoQ. Problems: hard to deploy parent side (like DSPKI); lots of complexity for resolvers; risk of loops.\n\nJ. Levine, dprive:\n\n1. [draft-levine-dprive-signal-02](https://tools.ietf.org/html/draft-levine-dprive-signal-02). Contains six proposals that all have problems with downgrades, indirection, or that they require DNSSEC.\n\n# Other rejected ideas\n\nApply Manu Bretelle's DSPKI type to DS, by assigning a new DNSSEC algorithm for it.\nProblem: many registries require the ability to generate DS from DNSKEY.\n\nPut TLSA for delegated name servers in parent zone. Cannot do this with normal TLSA syntax, because `ns1.example.com` is inside the `example.com` delegation, so this requires another hack to map that name into the parent zone. Problems: this puts a limit on the maximum name length of name servers; breaks Paul Wouter's powerbind proposal; generally does not look pretty.\n\n## Bortzmeyer+TLSA chain\n\nIf we add [draft-ietf-tls-dnssec-chain-extension-07](https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07) to Bortzmeyer's proposal above, as a mandatory configuration for DoT auths, the inconvenient indirection goes away.\nThen all that is left is just the signal 'this zone has DoT' which could be a DS record with specific algorithm, ignored digest and ignored content.\nThis still requires DNSSEC in the zone hosting the NS name.\n\nProblem: because the NSset in a delegation is unsigned, this does not actually provide any security.\n\n# Proposals\n\n## SPKI in DNSKEY\n\nStick SPKI (as defined by Manu Bretelle's DSPKI draft) in CDNSKEY (when we say CDNSKEY, we also mean 'submit DNSKEY via EPP to registry that does not accept DS').\nWhen we do this, the DS, using an existing digest type, becomes hashed SPKI (with a predictable prefix from 4034 5.1.4), which TLS clients can almost work with.\nProblem: as some registries insist on doing their own hashing from DNSKEY to DS, the CDNSKEY would be limited to the non-hashed variant, which prohibits any extra parameters, ~~such as pointing the pin at something higher in the chain (this is a bad idea because the NSset in a delegation is unsigned).~~\n\n## DNSKEY-wrapped TLSA plus DS NULL digest\n\nDefine a DNSKEY algorithm that wraps TLSA contents. Define a DS digest type that does not hash - instead it copies DNSKEY content verbatim. We can call it NULL or VERBATIM or something else. Then, we are effectively publishing TLSA for the name server hosts, in the parent zone, without requiring any changes to existing auth software; resolvers will still be able to pass on DS records correctly to their forwarding clients, and can optionally use the new DNSKEY algorithm and DS digest type to confidently operate TLS to the auths.\n\nProblems: because the NSset in a delegation is unsigned, most combinations of TLSA parameters are useless, so this might be more complicated than is useful.\nThe DS NULL digest type will be a pain to get deployed.\n\n# Random notes\n\n## TLS chain\n\n[draft-dukhovni-tls-dnssec-chain](https://datatracker.ietf.org/doc/draft-dukhovni-tls-dnssec-chain/), [server implementation 1](https://github.com/andreasschulze/openssl-demo-server), [server implementation 2](https://github.com/shuque/chainserver)\n\n# Unfinished thoughts on authenticating NS names\n\nWherever this proposes a new parent-side authoritative record type, you can also imagine some DS/DNSKEY hackery.\nThese thoughts are expected to enable `TLSA`-based proposals by given the resolver proven NS names.\nInstead of `TLSA`-related proposals, these ideas would also enable the usual CA checking that browsers do.\n\n## DNS\n\nThe `DNS` (delegated NS) type provides an authenticated child name server by name (or by hash, to match against the NSset)\n\n## DSNSSET\n\nThe `DSNSSET` (delegation signed NS set) type provides a hash/signature over the whole NSSet.\nWhen changing the NSset, add the new `DSNSSET` first, wait for TTL to expire, then change the NSSet.\n\n# Unfinished thoughts\n\nIdea from Petr Spacek: reserve a RRtype numeric range for types that are treated like DS, i.e.: authoritative in the parent; signed by the parent; provided with delegations by the parent.\nWe should write a short draft on this (doesn't have to be perfect or accurate) to take to DNSOP to check for appetite.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpowerdns%2Fparent-signals-dot","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpowerdns%2Fparent-signals-dot","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpowerdns%2Fparent-signals-dot/lists"}