Upgrade Requirements, Challenges, and Solutions for Same-Server DoT Implementation
Explore the transition from Do53 to DoT without changing resolvers, addressing challenges in DNS resolvers, TLS standards, and forwarder complications. Discover partial solutions through DANE TLSA certificates, DNS zone publishing, and DNSSEC trust anchors for enhanced security and upgrade process efficiency.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
DoT for Clients Same Server Upgrade Requirements, Challenges, and Solution(s) Brian Dickson, GoDaddy
DNS Client to Resolver Privacy: use TLS Standards have been developed DoH DoT Both rely on TLS Do53 uses IP addresses, not names, for resolvers How can a client upgrade from Do53 to DoT? Objective: upgrade to DoT without selecting a different resolver
Challenges DNS Resolvers: Do not require a DNS FQDN TLS: Server Name is mandatory Public CA limitations public DNS name only CA set for validation may be large CA signing process is complex, requires Internet access Lifetime of certificate and expiry Purchases required Validation of request, done by CA
Partial Solutions Use DANE TLSA for certificates Facilitates self-signed certificates Facilitates private CA usage Requires DNSSEC Use Reserved Name Space for Resolver Name ISO 3361-1 reserved 2-letter codes Use zz (see Roy Arends proposal)
Forwarder Complications If the client talks to a forwarder, queries get forwarded to a resolver (directly or indirectly) Client does not talk directly to the resolver EDNS options are hop-by-hop, so can t be used for client-resolver Consequence: Client-Resolver communication can only occur in- band with DNS queries and responses
Partial Solutions (cont) Publish information in DNS on the same Resolver Solves client reachability issue Compatible with private use Use the resolver s name as the DNS zone Zone in Reserved Name Space ISO 3361-1 reserved 2-letter codes Use zz (see Roy Arends proposal) Serve zone authoritatively, on the Resolver Zone reachable IFF query comes from resolver client Include TLSA, sign with DNSSEC
DNSSEC Trust Anchors Enable DNSSEC validation A unique zone name will have a unique trust anchor Obtaining the Trust Anchor is a challenge Once obtained, can be maintained (e.g. RFC 5011) One time only: get DNSSEC Trust Anchor for unique private zone
Two Zone Names A well-known name for discovery and first Trust Anchor discovery resolver-name.arpa A unique name in private served space zz for each resolver Globally unique Locally significant Randomly generated High entropy 12-character name from the base32hex (0-9,a-v) character set 2^5 characters x 12 letters, 2^60 potential names About 1,000,000,000,000,000,000 names, collisions unlikely
Bootstrap Once Per Resolver Generally, once the name is learned, a trust anchor is obtained Only use this first trust anchor during the bootstrap Never replace a known trust anchor resolver-name.arpa used for this process Obtain the unique name Obtain the corresponding trust anchor This instance of resolver-name.arpa is also DNSSEC signed Store this instance s trust anchor also (optionally?)
Second Stage of Bootstrap Have name of resolver Have trust anchor DNSSEC validate all data in this zone Resolver has generated its own self-signed certificate, published as a TLSA record (cert fingerprint) in its own zone Get TLS certificate fingerprint (TLSA) TLS certificate can now be validated by the client We can now do DNS over TLS (DoT) to the resolver
Additional Optional Features Use a Private CA Centrally managed certs Managed DNS zones Franchise use case No CA, but Managed Trust Anchor Locally generated self-signed certs Locally managed ZSKs Centrally managed KSK for all resolver-name.arpa instances Head Office use case
More Complex Set-up Handle Forwarders with the same mechanism Only include in standard as a defense against bad things happening A forwarder doing this, prevents discovery of the actual resolver using this same technique The forwarder would answer locally A client with two servers configured may want to ensure TLS all the way to the resolver Differential behavior by forwarders can break the proper server selection Forwarder 1 forwards over Do53 but client cannot learn this Forwarder 2 forwards over TLS but client cannot distinguish this
More Complex Set-up (continued) Add another element to the unique zone: server-function Either forwarder or resolver Add additional zone contents for forwarders upstream list of server names Per-name details under the name of the upstream s name E.g. foo.zz.bar.zz for upstream foo.zz of forwarder bar.zz Details include Trust Anchor, IP addresses, server type Add transport details (e.g. DoT and/or DoH)
Proof of Concept Available Now Proof of concept is on github: https://github.com/godaddy/ietf-dprive-poc Questions or comments: brian.peter.Dickson@gmail.com bdickson1@godaddy.com
