Post 9voIQXBUAMRe32qxMW by robertcc@infosec.exchange
 (DIR) More posts by robertcc@infosec.exchange
 (DIR) Post #9vmKqPm29UAaBbUrwW by leip4Ier@infosec.exchange
       2020-06-05T16:41:55Z
       
       0 likes, 0 repeats
       
       as far as i can see, if DoH is enabled on #mikrotik, the router itself will only use regular dns to resolve DoH domain. you have to have them configured for a single request on boot, later it won't fall back even if DoH becomes unavailable.but there's an issue: when allow-remote-requests=yes, dhcp tells its clients to use <router ip>,<regular dns ip 1>,<regular dns ip 2>. so they can possibly fall back to unencrypted dns!
       
 (DIR) Post #9vmKyeStPjUC4DTIYK by leip4Ier@infosec.exchange
       2020-06-05T16:43:25Z
       
       0 likes, 0 repeats
       
       i added a firewall rule to block udp 53 requests to wan, but that's an ugly hacknow thinking, maybe adding a static mapping for DoH resolver domain will work? maybe it's not just a coincidence that they added static mappings in the same release as DoH!
       
 (DIR) Post #9vmLaiktuWA4NU30Gu by leip4Ier@infosec.exchange
       2020-06-05T16:50:18Z
       
       1 likes, 0 repeats
       
       yeah it does work! microblogging often helps me realize there's a better way to do things. fediverse is my rubber duck debugger.
       
 (DIR) Post #9vms21vtul72CvG5ku by duponin@udongein.xyz
       2020-06-05T22:53:50.524861Z
       
       0 likes, 0 repeats
       
       @leip4Ier yeah! o/
       
 (DIR) Post #9voIQXBUAMRe32qxMW by robertcc@infosec.exchange
       2020-06-06T15:24:17Z
       
       0 likes, 0 repeats
       
       @leip4Ier Does your DoH provider also allow IP-based lookup over https? I am still getting into secure DND and just setup cloudflared on my piholes, but the lookup there didn't rely on unencrypted DNS, so that seems odd.
       
 (DIR) Post #9voJ3aQ44VcfNLIHho by leip4Ier@infosec.exchange
       2020-06-06T15:31:19Z
       
       0 likes, 0 repeats
       
       @robertcc no, i think almost all DoH providers use domain names instead of ip addresses, probably for easier key management (not everyone lets you get a tls certificate for an ip address, etc). i ended up adding a static mapping to their ip.it's common to use an ip address and specify a domain name to verify its tls cert against in dns-over-tls world. some clients don't even send sni, as servers are supposed to just accept all connections. but i don't like DoT.
       
 (DIR) Post #9voJNqKUczSWVmLZOi by leip4Ier@infosec.exchange
       2020-06-06T15:34:59Z
       
       0 likes, 0 repeats
       
       @robertcc in most cases, for DoT you specify your resolver in 0.0.0.0#domain.tld format. it makes the client connect to 0.0.0.0 and verify that it's certificate is valid for domain.tld. in some cases, you can also specify an ip address and a cert fingerprint, like that in hpkp, but i think it's being phased out.no idea why didn't DoH adopt these conventions..
       
 (DIR) Post #9voJQrbeKzILL8oPbM by leip4Ier@infosec.exchange
       2020-06-06T15:35:33Z
       
       0 likes, 0 repeats
       
       @robertcc in most cases, for DoT you specify your resolver in 0.0.0.0#domain.tld format. it makes the client connect to 0.0.0.0 and verify that it's certificate is valid for domain.tld. in some cases, you instead specify an ip address and a cert fingerprint, like that in hpkp, but i think it's being phased out.no idea why didn't DoH adopt these conventions..
       
 (DIR) Post #9voJj0ugTNyZPxMzxY by robertcc@infosec.exchange
       2020-06-06T15:38:50Z
       
       0 likes, 0 repeats
       
       @leip4Ier Yeah I have been driving into the DoH vs DoT fight myself to see what's going on. It's quite a mess we've made.Thank you for the information. Key management makes sense certainly. My experience has this far only been with cloudflare which does seem to require only IP but you also run a custom daemon to do some heavy lifting and validation I wager.
       
 (DIR) Post #9voJoiqKZQpn6y3WK0 by robertcc@infosec.exchange
       2020-06-06T15:39:51Z
       
       0 likes, 0 repeats
       
       @leip4Ier When I did this whole setup and blocked DNS at the border I found that Google devices started getting snickety, by the by. I actually internally NATed all calls to 8.8.8.8 and 8.8.4.4 to my resolvers, which solved it. Just in case!
       
 (DIR) Post #9voKC8xHeV9Il0TZkO by leip4Ier@infosec.exchange
       2020-06-06T15:44:06Z
       
       0 likes, 0 repeats
       
       @robertcc whoa, didn't think about this! sometimes regular dns being unencrypted is actually neat, thanks for the suggestion :)
       
 (DIR) Post #9voKdlkPWzgct8cz0S by robertcc@infosec.exchange
       2020-06-06T15:49:06Z
       
       0 likes, 0 repeats
       
       @leip4Ier I wanted to share because the symptoms were NOT obvious and forthcoming. So if I can save headache I will, gladly!
       
 (DIR) Post #9voLaJafrUmSe7zSng by leip4Ier@infosec.exchange
       2020-06-06T15:59:40Z
       
       0 likes, 0 repeats
       
       @robertcc i set up logging for that firewall rule, so that i can catch issues like this. i hope if i stumble upon some other devices not working correctly, i'll see why!
       
 (DIR) Post #9voZczQYgPqgL2Qcc4 by robertcc@infosec.exchange
       2020-06-06T18:37:01Z
       
       0 likes, 0 repeats
       
       @leip4Ier I was just intrigued why my Google devices were happily taking my local resolvers from DHCP but still running their own queries against the Google DNS servers, and never found a really satisfactory answer. They Just Do!