3 ms·

Sorry, I meant DNSCrypt (I thought I edited it soon enough). DNSCrypt is meant to be more about the last leg encryption/integrity/authenticity guarantee (compar

by ktta 9y ago

Sorry, I meant DNSCrypt (I thought I edited it soon enough). DNSCrypt is meant to be more about the last leg encryption/integrity/authenticity guarantee (compared to DNSCurve atleast) between a client and (caching) server. I agree with you on the DNS over TLS part. It is definitely a great idea. With TLS, secure transport implementations are already done to death so I guess we don't have to worry about another. I do have a question though. How are you handling the DNS request for the initial TLS connection? I'm talking about this: 1. Want to make DNS query for X.com 2. Connect to personal-dns-server.com over TLS connection for DNS request. 3. Want to make DNS query for personal-dns-server.com. 4. ? I'm asking this because your TLS implementation seems to be about the whole works - including the CA system. Which needs a CN. Which needs to be resolved (I initially thought it was just about the key neg + transport part of TLS with a hardcoded IP address in the config file) About DNSSEC + DNSCurve/TLS. I just wasn't talking about privacy. Integrity was my primary concern. DNSSEC isn't widely deployed, so we don't really know which domain implements DNSSEC and which doesn't. So in the last leg of DNS reply, one can just remove the RRSIGs and make it look like DNSSEC was never implemented. Pretty much a downgrade (to nothing) attack. Also, we don't have any way of warning the user if a RRSIG doesn't validate the A rec properly, so what's your plan on this? A while ago I had a similar idea you did, but more geared towards being an on-disk cache (check out pdnsd - sad it is unmaintained though) where I thought eventually it has to step into user alerts using the notification daemon.

bluejekyll 9y ago
Let me unpack this starting from here: >I'm asking this because your TLS implementation seems to be about the whole works - including the CA system. Which needs a CN. Yes, I am leveraging the standard TLS design, it includes the defaults as specified by the underlying TLS implementation; currently this is openssl, native-tls, or rustls. Like DNSCrypt (Curve), the server must be registered out-of-band if it is not signed by one of the CA's registered in the system. I thought about this for a while, and decided it was best for ease of use to rely on the system CAs and allow additionals to be registered. > Which needs to be resolved (I initially thought it was just about the key neg + transport part of TLS with a hardcoded IP address in the config file) This isn't accurate. The CN is only used by the underlying TLS library to validate the Subjects in the X509 cert returned by the server. There is no additional lookup required for that name. Honestly, since that name isn't being used for resolution (i.e. your using IPs in DNS config), this doesn't provide as much value in DNS as it does in standard TLS connections where a name was resolved to an IP, but at least it would validate that the NS servers are named what you expect. > How are you handling the DNS request for the initial TLS connection? I'm talking about this: > > 1. Want to make DNS query for X.com > 2. Connect to personal-dns-server.com over TLS connection for DNS request. > 3. Want to make DNS query for personal-dns-server.com. > 4. ? Again, there is no "DNS" request for the TLS connection, this is the order: 1. A direct IP connection to the remote TLS server based on configuration, 2. The TLS handshake is performed with that server, using the associated CN on the connection, and validating against the associated CA list 3. Standard TCP DNS request is performed from this point. Does that help clarify this impl?
- ktta 9y ago
  Apologies. Your implementation was a little tricky to understand. Excellently commented though. Can you give me an example config file for the client? (I could only see one for the server) PS: In a couple places, 'Ellyptic' was written so you might want to correct that.
  - bluejekyll 9y ago
    The Client/Resolver doesn't actually have a config for enabling TLS ATM, this should be added as a backlog issue. At the moment you'd have to build this into a custom Rust impl. I've been considering whether it can be an addition to the resolv.conf, or should just have a separate TOML. If you don't mind, would you want to file an issue and describe how you want to use this? Edit: I have been planning on a system daemon caching resolver that can be run on any OS. This work is only just getting started. > In a couple places, 'Ellyptic' was written Yeah, me and spelling have had a issue going all the way back to 1st grade ;) Edit: btw, you're comment about CN got me thinking again about the correct usage of that, and I wonder if "name" is even correct. It might be better to have the certs be validated against IP's listed in the Subject of the Cert... I need to revisit this. btw, here's a good example from one of the tests that shows how to set this up: https://github.com/bluejekyll/trust-dns/blob/master/rustls/src/tests.rs#L193-L207 https://github.com/bluejekyll/trust-dns/blob/master/rustls/s...
    - ktta 9y ago
      Thanks. I'll check it out. What you are saying can work if the client has a an IP/port and the CN that is in the Server's Cert in a config file. If you are targeting linux I would say have a new config file in /etc . Messing with resolv.conf isn't recommended since it is re-generated frequently.

by ktta 9y ago

bluejekyll 9y ago

Let me unpack this starting from here: >I'm asking this because your TLS implementation seems to be about the whole works - including the CA system. Which needs a CN. Yes, I am leveraging the standard TLS design, it includes the defaults as specified by the underlying TLS implementation; currently this is openssl, native-tls, or rustls. Like DNSCrypt (Curve), the server must be registered out-of-band if it is not signed by one of the CA's registered in the system. I thought about this for a while, and decided it was best for ease of use to rely on the system CAs and allow additionals to be registered. > Which needs to be resolved (I initially thought it was just about the key neg + transport part of TLS with a hardcoded IP address in the config file) This isn't accurate. The CN is only used by the underlying TLS library to validate the Subjects in the X509 cert returned by the server. There is no additional lookup required for that name. Honestly, since that name isn't being used for resolution (i.e. your using IPs in DNS config), this doesn't provide as much value in DNS as it does in standard TLS connections where a name was resolved to an IP, but at least it would validate that the NS servers are named what you expect. > How are you handling the DNS request for the initial TLS connection? I'm talking about this: > > 1. Want to make DNS query for X.com > 2. Connect to personal-dns-server.com over TLS connection for DNS request. > 3. Want to make DNS query for personal-dns-server.com. > 4. ? Again, there is no "DNS" request for the TLS connection, this is the order: 1. A direct IP connection to the remote TLS server based on configuration, 2. The TLS handshake is performed with that server, using the associated CN on the connection, and validating against the associated CA list 3. Standard TCP DNS request is performed from this point. Does that help clarify this impl?

ktta 9y ago
Apologies. Your implementation was a little tricky to understand. Excellently commented though. Can you give me an example config file for the client? (I could only see one for the server) PS: In a couple places, 'Ellyptic' was written so you might want to correct that.
- bluejekyll 9y ago
  The Client/Resolver doesn't actually have a config for enabling TLS ATM, this should be added as a backlog issue. At the moment you'd have to build this into a custom Rust impl. I've been considering whether it can be an addition to the resolv.conf, or should just have a separate TOML. If you don't mind, would you want to file an issue and describe how you want to use this? Edit: I have been planning on a system daemon caching resolver that can be run on any OS. This work is only just getting started. > In a couple places, 'Ellyptic' was written Yeah, me and spelling have had a issue going all the way back to 1st grade ;) Edit: btw, you're comment about CN got me thinking again about the correct usage of that, and I wonder if "name" is even correct. It might be better to have the certs be validated against IP's listed in the Subject of the Cert... I need to revisit this. btw, here's a good example from one of the tests that shows how to set this up: https://github.com/bluejekyll/trust-dns/blob/master/rustls/src/tests.rs#L193-L207 https://github.com/bluejekyll/trust-dns/blob/master/rustls/s...
  - ktta 9y ago
    Thanks. I'll check it out. What you are saying can work if the client has a an IP/port and the CN that is in the Server's Cert in a config file. If you are targeting linux I would say have a new config file in /etc . Messing with resolv.conf isn't recommended since it is re-generated frequently.