1

When it comes to encrypting DNS queries using dnscrypt-proxy, people also tend to use dnsmasq on their linux machines. The main goal of this setup in the past was to provide cache for DNS queries, but the DNS cache is now implemented in dnscrypt-proxy itself. So it looks like that dnscrypt-proxy is all people need these days. But I noticed that people usually add the following line (or something similar) to the dnsmasq config:

server=/pool.ntp.org/1.1.1.1

The purpose of this line is to send DNS queries for the time server domain directly to the DNS server and hence skip the whole encryption process (it's just a regular DNS query). Some people once told me that these queries should go as fast as possible to provide a better time sync. So, does this approach make any sense?

Mikhail Morfikov
  • 10,309
  • 19
  • 69
  • 104
  • 1
    I truly hope that ntp is not implemented that way. I see no need to include DNS look up as part of the time synchronisation. I would hope it is done pre-synchronisation. – ctrl-alt-delor Sep 17 '20 at 20:53
  • Yes, the DNS query is resolved before local NTP gets into the whole "What time is it? No, really what time is it? Say again?" conversation with the NTP server. What will the Black Hat learn about you, or your system, by knowing you looked up an NTP server? So did everybody else. – waltinator Sep 18 '20 at 01:46

1 Answers1

0

From a security perspective, I don't think this approach is really advisable. The purpose of DNS over HTTPS and/or DNSCrypt is not only to provide secrecy, that is, to hide the queries, but also, and perhaps most importantly, to provide authenticity. In particular, performing DNS queries to the NTP server in the clear (without the encryption) would open the network to MITM attacks with fake NTP packets in order to defeat or bypass HSTS. Since HSTS relies on its max-age parameter, one could defeat it by spoofing the NTP server and changing the machine's clock.

Hermógenes Oliveira
  • 321
  • 2
  • 7