Blocky seems to keep query upstream domain via bootstrap DNS even after bootstrapped #454
Comments
|
Did I understand it correct: you have one upstream server (defined as hostname and not as IP). Bootstrap DNS is also defined. You can observe multiple queries on bootstrap DNS server with upstream's hostname. |
|
@0xERR0R yes! You're right! The queries keep going after the upstream's ready and resolving queries. |
|
I can't reproduce it. I started one blocky instance as docker container and a local instance, which uses docker container as bootstrapDNS. I configured only 1 upstream resolver as DoH. I see only 2 requests with resolver's address. No further requests if i run DNS queries. |
|
I'll see how I can package a reproducible environment in Dockerfile that can be used for debug. Thanks. |
|
I can reproduce the issue with blocky v0.18(Build time: 20220223-205646) on Ubuntu 20.04, and maybe my original report wasn't accurate, here's the config used to produce the issue, the log, and the result that I found: Two blocky process will be setup to reprodice this issue, one will be act like the bootstrap server for the other one, one will act like normal local blocky resolver:
upstream:
default:
- tcp-tls:dns.google
port: ":8053"
upstream:
default:
- tcp-tls:dns.google
port: ":8054"
bootstrapDns: udp:127.0.0.1:8053Once they're running, I'll send some DNS requests to the normal one listen on port 8054. This is the log of the bootstrap DNS: This is the log of the normal local blocky DNS: What I saw is that blocky will ask the bootstrap DNS about the encrypted DNS "everytime" when it received a non-cached query, which is not ideally, consider TTL of Maybe blocky should cache the upstream DNS's IP itself, lookup via bootstrap DNS only when the cache is not valid like the TTL is passed? Would be even better to lookup via encrypted DNS before the TTL is passed, so that there's no need to use the plaintext DNS for non-bootstrap need. |
|
Thanks for your input, now I can reproduce it. If I try following config: upstream:
default:
- tcp-tls:one.one.one.one
- https://dns.digitale-gesellschaft.ch/dns-query
port: ":8054"
bootstrapDns: udp:127.0.0.1:8053only "one.one.one.one" appears in the log for each query. DoH address only once. |
|
If I understand it right, Go doesn't cache any DNS queries for lookups (see golang/go#24796 (comment) and golang/go#24796 (comment)). This is typically done by system DNS resolver. By setting the bootstrap dns for blocky, the application doesn't use the system DNS resolver. I'll try to find out, if it is possible to cache those queries. |
|
I added caching to the bootstrap resolver, It looks better now. |
|
That's awesome, I'll see if I can build from the development branch and verify the behavior ;) |
If not, I can provide you a binary for Linux |
|
I can verify that block isn't going to ask about upstream's IP address every time, that's nice! Would be even better if the upstream IP address can be looked up via encrypted DNS before the cache expired 😆 |
|
If you want to DoT or DoH as bootstrap DNS, you need a working DNS resolver to resolve the IP of the URL. Therefore, current bootstrap DNS is a plain DNS, which can be used as IP address. I think, for DoT and DoH you can't use the IP address. |
If the cache of DoH or DoT address is not expired yet, that'll be easier, to just to resolve those domains again, but just via the encrypted DNS? I mean, of course the first bootstrap has no context about upstream IP, but the following behavior after the bootstrap, the encrypted DNS is ready with resolved IP address, right?
Not sure if you mean the cert of DoT/DoH validation issue? Though this may not be very related to the original issue, but I know at least Google, Quad9, Quad101 and Cloudflare has valid cert for their IP address, that won't need a bootstrap, and can actually be reached via DoT/DoH via IP address. For example, these sites are all valid: Though Quad9 doesn't seem to support JSON API query, the other three DNS do, they will return the json format query result for you.:
|
I was not aware, that some DNS providers have valid certs for IP only addresses. In this case it should be possible to use DoH/DoT as bootstrap even if the system has no valid DNS resolver. I'll create an issue for tracking purposes. Edit: Issue created: #464 |
|
Just to confirm, so that using encrypted DNS itself to query its IP address before the cache expire wouldn't be considered to implement, right? |
|
I don't get your question. The idea is to allow to use either plain DNS or DoT/DoH as bootstrap DNS. This is only necessary, if host DNS resolver is not properly configured (of for some other reasons). If user wants to use a DNS server and configures a hostname/URL instead of IP address, blocky will use the system DNS resolver to obtain the IP. |
|
Sorry for the confusion, I just wonder if the bootstrap can only be used at the bootstrap stage, which means once the first encrypted query was successfully sent and resolved, the following requests all going to the encrypted DNS, including the query of the domain of encrypted DNS. |
As title, I've noticed that Blocky seems to keep query upstream domain via bootstrap DNS even after bootstrapped, and it's frequently, not sure if it's expected? Thinking about maybe once the query to encrypted DNS upstream is established, should use the encrypted DNS to look up the upstream's IP addresses?
Here's the partial of the timestamp records that I observed the query to of upstream encrypted DNS's domain name. I use only single one upstream in this case, and its TTL of the upstream domain is 300 secs, it looks like the query is much more frequent than the TTL.
The text was updated successfully, but these errors were encountered: