Documentation on how to change MacOS roaming clients from 53 to 5353 or 853
launched
Greg
Requesting documentation on how to change roaming clients from 53 to 5353 or 853 for a MacOS. I was under the impression I could add
upstream_order=[ "tcp-tls", "udp", "tcp" ]
to /Library/Application Support/DNSFilter/daemon.conf until I realized this seems to be only in environments that use a relay server and relay.conf file?
Does the daemon.conf not allow to change the upstream_order or change the ports used locally on the MacOS?
We have services running on our Macs that conflict with udp port 53 and need the ability to use the available 5353 or 853 ports potentially. The documentation doesn't make it very clear if those other ports are only available outside of local macos configurations.
Nick Saunders
launched
Nick Saunders
Hi Greg, modifying the upstream_order is supported on macOS and will enable the use of Port 853 when using 'tcp-tls'. I agree our documentation could make this more clear, I'm working with our knowledge base team to get this updated. In meantime you can refer to this page referencing the necessary macOS configuration and this overview page on DoT itself which mentions it's use of Port 853.
Also, is the conflicting services you're using have issues with Port 53 in general or just on our 127.0.0.1 default listener address? If it's the latter there's additional configuration options that may work for you.
Greg
Nick Saunders when I have tried to make the change in daemon.conf locally on a mac and restart services I do not see any listening ports for dns other than 53. I tried uninstalling, reinstalling, restarting services and dns is only listening on 53. Do macs need some other settings changed to look at dnsfilter at port 853 if the upstream order is changed?
Also, AWS local stack specifically conflicts with 127.0.0.1:53 on our macs.
Nick Saunders
Greg I see, okay so I think what would work for you is modifying the listener address itself to 127.0.0.2 — this can be done by adding a parameter in the daemon.conf file called
alias_address
alias_address = ["127.0.0.2"]
If you add that to the top of the file and restart the service you should avoid the conflict with AWS. We support .3 and .4 as well, if necessary. I'm also getting this configuration option added to the docs as it was missed when it was first added in version 1.5.0.
Greg
Nick Saunders so if I understand correctly, updating the daemon.conf to have
alias_address = ["127.0.0.2"]
upstream_order=[ "tcp-tls", "udp", "tcp" ]
to my local mac as a test, it should take these configurations into considerations when I start dnsfilter back up? How do I test to confirm the upstream order and alias order is being used by dnsfilter on a macos for example?
When I run these commands I don't see 127.0.0.2 or port 853 listening for any DNS calls after uninstalling dnsfilter and reinstalling with the new daemon.conf settings
✗ netstat -an | grep "127.0.0.2:853"
✗ netstat -an | grep "127.0.0.2"
✗ netstat -an | grep "127.0.0.1"
tcp4 0 0 127.0.0.1.631
.
LISTENtcp4 0 0 127.0.0.1.53
.
LISTENtcp4 0 0 127.0.0.1.8769
.
LISTENtcp4 0 0 127.0.0.1.6463
.
LISTENtcp4 0 0 127.0.0.1.49205
.
LISTENudp4 0 0 127.0.0.1.53
.
Are these things only listening during web calls? or am I misunderstanding how to troubleshoot/confirm these settings?
Nick Saunders
Greg Hey Greg, I see what the problem is and I'm sorry I misspoke on the optional setting - the correct parameter name is
alias_addresses
as it supports an ordered list of multiple addresses. Can you try that and see if it works for you.Greg
Nick Saunders It seems to have worked! the deployment script im running on the macs tried using launchctl to stop and start service after a fresh install AND tried just doing a open application but it seems all dnsfilter needed was a little bit of time to take in the new changes? When I first run my deployment it doesnt produce expected results in testing but I let it sit overnight on a test device and the daemon config seems to be working as expected. Is it a timing thing you think Nick Saunders or is it something about how the agent gets installed and needing a couple launchctl stop/starts to kick in the new changes faster?
Regardless, thanks for the help