In this article:
Introduction
The ".local" top-level domain (TLD) is a reserved TLD as specified in RFC 6762, designed to be used for multicast DNS services. It is heavily used within the Apple ecosystem as a way for systems to identify compatible devices via the Bonjour mDNS service, and it is highly recommended by Apple to instead use a registered domain name or non-reserved TLD when designing out an internal network.
In situations where a network already heavily utilizes .local as a TLD and you are unable to change the structure, you may run into issues trying to reach Resources through the Twingate service that end in .local, especially when using a Linux or MacOS based system. There are a couple of possible solutions that can be tried.
Using Sub-domains
There are some situations where adding a sub-domain to a domain.local style domain will resolve issues resolving to the proper IP address. This depends heavily on the OS or client application that is making the request.
For example, if you've been using domains such as "fileshare.local" or "grafana.local" to represent internal resources on your network, try injecting your company name as the domain, keeping the current domain as a sub-domain.
- fileshare.local => fileshare.companyname.local
- grafana.local => grafana.companyname.local
In this manner it is a minor change for users and you can update your network hosts configuration without having to remove the existing entries, allowing for a more gradual migration.
Assigning an Alias
One of the biggest issues with using ".local" as a TLD for private resources is that the client machine itself tries to use it with its mDNS resolution service. Removing the need for the client machine to directly access the domain by adding an Alias within the Twingate configuration may help to alleviate this issue.
For any Resource that you've defined inside of your Twingate Remote Network, click the Edit button on the left-hand side of the Resource screen, click "Alias" next to the defined domain name, and then enter a new alias, so that it looks something like this:
Once you update the Resource and verify that the change has taken place on your local Client, try accessing it both through the ".local" and new ".int" versions of the domain, and see if the Alias has resolved the issue.
Disabling the mDNS Service
Making the changes below will disable multicast DNS and may have an impact on other services such as network discovery, meaning file shares and printers and screen sharing can all be affected. These changes are last resorts and generally not recommended.
Linux
In Linux distros that use the systemd-resolved service the local DNS stub listener won't forward DNS requests for domains ending with the .local TLD. To resolve this you can disable the local stub listener by editing /etc/systemd/resolved.conf:
$ cd /etc/systemd
$ sudo nano resolved.conf
change:
#DNSStubListener=yes
to:
DNSStubListener=no
Ctrl-O + Enter
Ctrl-X + Enter
$ sudo systemctl restart systemd-resolved
Uncommenting out the line and changing it to no will disable the local listener and have the machine go directly to the upstream DNS resolvers.
MacOS
On MacOS there's a service that runs after each boot that handles mDNS requests. To disable this service you need to first boot into recovery mode, and then disable System Integrity Protection.
To do this, first reboot your Mac and press Command+R as it boots. Once inside the recovery environment click "Utilities" and then "Terminal", and within that terminal run the following:
csrutil status
This will return enabled or disabled depending on the status of the service, if it returns enabled then run:
csrutil disable
This will disable System Integrity Protection, and after you reboot the system you will have full root access to the entire operating system.
Once you have booted back up you can then run the commands below in a terminal window:
$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSresponder.plist
$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSresponderHelper.plist
These commands will stop and disable the two services completely, with the "-w" flag causing these changes to persist beyond each reboot of the system. If you wish to later re-enable these two services then run the same commands with "load" replacing "unload", and then reboot the system, making sure to also go back into the recovery environment and re-enabling the System Integrity Protection service by running:
csrutil enable