Bypass DNS Boster for Docker container
If I run a Docker container on my FWG, does that container use the Firewalla DNS Booster? If so, is there a way to prevent it? Maybe run as macvlan network?
I have a DDNS updater container that I use to update my Namecheap DDNS entries. I currently run this on a server that I have DDNS booster turned off on. I would like to run this on the FWG and shutdown the other server.
I have entries in the DNS Booster to keep some of my request on my LAN as opposed to my public address, and these entries mess with the DDNS updater.
-
Why not just point your DDNS to the firewalla DDNS with a CNAME?
Or does namecheap have ab API to update the DDNS?
I don’t think DNS Booster apples to the container but it also doesn’t sound like SETTINGS > Advanced > Configurations like DNS Booster would affect it.
EDIT use this in a script it is far less resources than a docker container. namecheap.com/support/knowledgebase/article.aspx/29/11/how-to-dynamically-update-the-hosts-ip-with-an-https-request
-
I solved my problem by moving my DDNS updater to another server (not the FWG). That server is using the DNS Booster, however, I changed up my Docker compose file to specify the Cloudflare DNS servers. This seemed to allow that container to bypass the DNS Booster.
Having said that, I imagine that if I would have run it on the FWG, I could have done the same thing to the Docker compose to bypass the DNS Booster.
-
I specified the DNS servers to use on the Docker container, not the host server. The host server is using the router (aka FWG) as the default DNS server, so is therefore using the FWG DNS Booster. The Docker container is going straight to Cloudflare, and therefore bypassing the FWG DNS Booster.
My reasoning for doing this is as follows. Assume I have the domain foo.com. I need to update the DNS to point to my locally shifting public IP. My DDNS updater that I run locally, checks to see what my public IP is. It then checks DNS to see what it is set to. If it is different, it calls my domain registrar and updates the DNS for foo.com to my new public IP. Now, I am being a little sneaky by setting the IP of my local server that hosts the service for foo.com into the FWG DNS Booster (e.g. foo.com = 192.168.1.70). I do this so that requests to foo.com from my LAN just get routed to the service on my LAN instead of messing with my public IP.
If the DDNS updater doesn't bypass the DNS Booster, it will check what the public IP is and then check the DNS for what the IP should be. It will get my local LAN IP and assume they are different (because they are), and it will call my registrar EVERY time to update it instead of just when it actually changes.
This my Docker compose file:
version: "3.7"services:ddns-updater:image: qmcgaw/ddns-updatercontainer_name: ddns-updaternetwork_mode: bridge# Use a different DNS to bypass the Firewalla DNS boosterdns:- "1.1.1.1"- "8.8.8.8"ports:- 8020:8000/tcpvolumes:- ./data:/updater/dataenvironment:- TZ=${TZ}restart: always -
So you are using 172.17.0.0/16 for the docker CIDR? If so, then I believe you are correct DNS Booster won't be used in that case. But that would be equally true on Firewalla itself or if you run it on another device.
I need to update the DNS to point to my locally shifting public IP. My DDNS updater that I run locally, checks to see what my public IP is. It then checks DNS to see what it is set to. If it is different, it calls my domain registrar and updates the DNS for foo.com to my new public IP. Now, I am being a little sneaky by setting the IP of my local server that hosts the service for foo.com into the FWG DNS Booster (e.g. foo.com = 192.168.1.70). I do this so that requests to foo.com from my LAN just get routed to the service on my LAN instead of messing with my public IP.
Do you mean you are using a custom DNS rule to avoid hairpin NAT? I think that should work, but I'm not sure it of any benefit. If you didn't do this, you might discover any issues faster if you use normal routing (which would be hairpin NAT in this case.)
I don't know which DNS updater you are using. I think most of them will do what you want for you. e.g. check the IP of the origin of the command; if it is different, update, if not do nothing.
Anyway, what you are doing probably works, but is perhaps more complex than needed to do the job.
Please sign in to leave a comment.
Comments
9 comments