starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #216] Consider the CN (DNS Name, SPKI) of the TLS request #397

New issue

Closed

opened 2026-03-15 22:18:29 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 22:18:29 +03:00

Owner

Originally created by @bluejekyll on GitHub (Sep 28, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/216

See https://news.ycombinator.com/item?id=15354120

It's possible that it would be better to have the certs be signed with IP addresses in the alternative subject fields, rather than name, as the name is somewhat irrelevant. It's the IP that's being used to for connection establishment.

Originally created by @bluejekyll on GitHub (Sep 28, 2017). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/216 See https://news.ycombinator.com/item?id=15354120 It's possible that it would be better to have the certs be signed with IP addresses in the alternative subject fields, rather than name, as the name is somewhat irrelevant. It's the IP that's being used to for connection establishment.

kerem

2026-03-15 22:18:29 +03:00

closed this issue
added the
enhance

trust

crate:client

crate:rustls

crate:native-tls
labels

kerem commented

2026-03-15 22:18:45 +03:00

Author

Owner

@Darkspirit commented on GitHub (Sep 28, 2017):

I am confused that you are talking about "CN".
Chrome deprecated CN and only pays attention to SAN (DNS/IP). That should be done everywhere.
If I'm not wrong, Letsencrypt does not issue certificates for ip addresses.
Using a CA for DNS over TLS is another killswitch/point of failure and is not an ideal solution in my opinion, but better than without any validation.

recursive-to-authoritative connections (not standardized)
The com zone may contain "example.com NS ns1.example.com" + "ns1.example.com A <ip4>". So trustdns-server should have a cert for ns1.example.com (SAN). For the case that one trustdns server is known under different nameserver domains (uncommon?), it could support SNI to select the correct certificate. Otherwise one has to make sure that all possible names are SAN entries in the one and only certificate.

stub-to-recursive connections (rfc7858)
A publicly accessible trustdns resolver could have a cert for (and a PTR record to) resolver.example.com (SAN) to make things clearer. I don't remember how the standard wants to have this if it's defined at all. Will read it again.
Edit:

The client will then authenticate the server, if required. This
document does not propose new ideas for authentication. Depending on
the privacy profile in use (Section 4), the DNS client may choose not
to require authentication of the server, or it may make use of a
trusted Subject Public Key Info (SPKI) Fingerprint pin set.

Unbound does not care which certificate is provided, if I'm not wrong.
Cool would be to have multiple options on the client side:

opportunistic TLS, take any cert: 4.1. Opportunistic Privacy Profile
, check if my dhcp dns server speaks on port 853, otherwise connect via port 53.
require TLS: take any cert
require TLS: validate against common CAs
require TLS: SPKI fingerprint pinning (like TLSA/DANE I think): 4.2. Out-of-Band Key-Pinned Privacy Profile

(All "require TLS" options would definitely fail on port 53-only captive portals if a non-dhcp resolver is configured. dnssec-trigger configures a local unbound and can notify the user if there is a captive portal to temporarily disable dnssec validation + switch to dhcp dns. Just wanted to notice this so that it is not forgotten.)

the future
DNSSEC/DANE chain stapling (similar to OCSP stapling) will be used for _443._tcp.example.com TLSA
and _853._tcp.example.com TLSA for example. (at least it seems so)

@Darkspirit commented on GitHub (Sep 28, 2017): I am confused that you are talking about "CN". Chrome deprecated CN and only pays attention to SAN (DNS/IP). That should be done everywhere. If I'm not wrong, Letsencrypt does not issue certificates for ip addresses. Using a CA for DNS over TLS is another killswitch/point of failure and is not an ideal solution in my opinion, but better than without any validation. **recursive-to-authoritative connections** (not standardized) The com zone may contain "example.com NS ns1.example.com" + "ns1.example.com A \<ip4\>". So trustdns-server should have a cert for ns1.example.com (SAN). For the case that one trustdns server is known under different nameserver domains (uncommon?), it could support SNI to select the correct certificate. Otherwise one has to make sure that all possible names are SAN entries in the one and only certificate. **stub-to-recursive connections** ([rfc7858](https://tools.ietf.org/html/rfc7858)) A publicly accessible trustdns resolver could have a cert for (and a PTR record to) resolver.example.com (SAN) to make things clearer. I don't remember how the standard wants to have this if it's defined at all. Will read it again. Edit: > The client will then authenticate the server, if required. This > document does not propose new ideas for authentication. Depending on > the privacy profile in use (Section 4), the DNS client may choose not > to require authentication of the server, or it may make use of a > trusted Subject Public Key Info (SPKI) Fingerprint pin set. [Unbound](https://github.com/jedisct1/unbound/search?q=ssl-upstream&type=Commits&utf8=%E2%9C%93) does not care which certificate is provided, if I'm not wrong. Cool would be to have multiple options on the client side: * opportunistic TLS, take any cert: [4.1. Opportunistic Privacy Profile ](https://tools.ietf.org/html/rfc7858#section-4.1), check if my dhcp dns server speaks on port 853, otherwise connect via port 53. * require TLS: take any cert * require TLS: validate against common CAs * require TLS: SPKI fingerprint pinning (like TLSA/DANE I think): [4.2. Out-of-Band Key-Pinned Privacy Profile](https://tools.ietf.org/html/rfc7858#section-4.2) (All "require TLS" options would definitely fail on port 53-only captive portals if a non-dhcp resolver is configured. [dnssec-trigger](https://packages.debian.org/stretch/dnssec-trigger) configures a local unbound and can notify the user if there is a captive portal to temporarily disable dnssec validation + switch to dhcp dns. Just wanted to notice this so that it is not forgotten.) **the future** [DNSSEC/DANE chain stapling](https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/) (similar to OCSP stapling) will be used for [_443._tcp.example.com TLSA](https://bugzilla.mozilla.org/show_bug.cgi?id=672600#c65) and [_853._tcp.example.com TLSA](https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-11#section-8.2.2) for example. (at least it seems so)

kerem commented

2026-03-15 22:18:50 +03:00

Author

Owner

@bluejekyll commented on GitHub (Sep 28, 2017):

By CN I mean the CommonName of the cert, though really I mean any valid signed name in the Cert as the CommonName (CN) or any SubjectAlternativeName (SAN). I didn't realize that CA's out there won't issue certs against IP.

If I understand your comment, then this is the current configuration on the client. It is expected that you would validate the cert with ns1.example.com. On the server side, I currently don't have SNI implemented. But it should be feasible to change the current server wide cert for certs per zone and use SNI to select the current cert.

Cool would be to have multiple options on the client side:

We can do that. My biggest concern is that we don't offer any options that someone could easily shoot themselves in the foot.

opportunistic TLS, take any cert: 4.1. Opportunistic Privacy Profile
, check if my dhcp dns server speaks on port 853, otherwise connect via port 53.

I'm not sure of the value of this (though I can be swayed), as this would potentially allow for both downgrade accidental connections in plain... It's definitely something that would be easily implemented, I have logic around the UDP -> TCP promotion, this would probably be similar.

require TLS: take any cert

Wouldn't most people want to know that they're connecting to something legit? Again, my concern is a false sense of security.

require TLS: validate against common CAs

Supported today.

require TLS: SPKI fingerprint pinning (like HPKP): 4.2. Out-of-Band Key-Pinned Privacy Profile

This would disable the common CA's, yes? TRust-DNS currently allows for pinning of additional Certs, but not exclusively only those. This may require digging into some of the underlying TLS implementations to expose these features.

@bluejekyll commented on GitHub (Sep 28, 2017): By CN I mean the CommonName of the cert, though really I mean any valid signed name in the Cert as the CommonName (CN) or any SubjectAlternativeName (SAN). I didn't realize that CA's out there won't issue certs against IP. If I understand your comment, then this is the current configuration on the client. It is expected that you would validate the cert with `ns1.example.com`. On the server side, I currently don't have SNI implemented. But it should be feasible to change the current server wide cert for certs per zone and use SNI to select the current cert. > Cool would be to have multiple options on the client side: We can do that. My biggest concern is that we don't offer any options that someone could easily shoot themselves in the foot. > opportunistic TLS, take any cert: 4.1. Opportunistic Privacy Profile , check if my dhcp dns server speaks on port 853, otherwise connect via port 53. I'm not sure of the value of this (though I can be swayed), as this would potentially allow for both downgrade accidental connections in plain... It's definitely something that would be easily implemented, I have logic around the UDP -> TCP promotion, this would probably be similar. > require TLS: take any cert Wouldn't most people want to know that they're connecting to something legit? Again, my concern is a false sense of security. > require TLS: validate against common CAs Supported today. > require TLS: SPKI fingerprint pinning (like HPKP): 4.2. Out-of-Band Key-Pinned Privacy Profile This would disable the common CA's, yes? TRust-DNS currently allows for pinning of additional Certs, but not exclusively only those. This may require digging into some of the underlying TLS implementations to expose these features.

kerem commented

2026-03-15 22:18:55 +03:00

Author

Owner

@briansmith commented on GitHub (Oct 24, 2017):

If I understand your comment, then this is the current configuration on the client. It is expected that you would validate the cert with ns1.example.com.

AFAICT, Trust-DNS client will do the correct thing when using Rustls, automatically. This is because Rustls was designed to do the correct thing by default.

On the server side, I currently don't have SNI implemented. But it should be feasible to change the current server wide cert for certs per zone and use SNI to select the current cert.

Rustls makes this pretty easy to do, as it has a callback interface for looking up the cert by SNI name already.

@briansmith commented on GitHub (Oct 24, 2017): > If I understand your comment, then this is the current configuration on the client. It is expected that you would validate the cert with ns1.example.com. AFAICT, Trust-DNS client will do the correct thing when using Rustls, automatically. This is because Rustls was designed to do the correct thing by default. > On the server side, I currently don't have SNI implemented. But it should be feasible to change the current server wide cert for certs per zone and use SNI to select the current cert. Rustls makes this pretty easy to do, as it has a callback interface for looking up the cert by SNI name already.

kerem referenced this issue

2026-03-16 02:04:51 +03:00

[PR #397] [CLOSED] Bump env_logger from 0.5.6 to 0.5.7 #1408