mirror of
https://github.com/andrewbadge/DNSRoaming.git
synced 2026-04-26 05:05:52 +03:00
[GH-ISSUE #3] Feature Request: Add DNS Query Result in Rules #2
Labels
No labels
enhancement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/DNSRoaming#2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ztheory on GitHub (Mar 5, 2022).
Original GitHub issue: https://github.com/andrewbadge/DNSRoaming/issues/3
Originally assigned to: @andrewbadge on GitHub.
Firstly, thank you for making this excellent application.
Use Case
An organization wants to use DHCP-delegated DNS servers when the device is on prem, but use the configured DNS servers (Quad9/Cloudflare/etc) when off-prem.
Using the LAN IP address/range or ping rules to determine if the device is on prem will not work in all cases, since the same IP address/range or pingable IP address may also exist on foreign networks. If the organization uses 192.168.0.0/24, and so does a foreign network, this would make DNSRoaming undesirably use the DHCP-delegated DNS servers if set in the rules.
In addition, the WAN IP address may be different in some cases, such as:
This means managing more rules.
Feature Request
In this situation, a DNS query sent to the DHCP-delegated DNS servers would be definitive. An organization could create an entry in the local forwarder, such as "amionprem.local".
NXDOMAIN, then DNSRoaming uses the configured DNS serversNOERROR, then DNSRoaming uses the DHCP-delegated DNS serversThis implementation might require a prerequisite: upon service stop or system shutdown/sleep, reset DNS to use the DHCP-delegated DNS servers. On service start/wakeup, the DNS query could then be executed to determine if it's on prem or not when executing the ruleset and before changing to Quad9/Cloudflare/etc. This is likely required, because if the DHCP-delegated DNS servers are not restored upon Service stop or system shutdown/sleep, and if Quad9/Cloudflare/etc is already present, then the query would not be sent to the local DNS forwarder.
Hope this makes sense!
@andrewbadge commented on GitHub (Mar 6, 2022):
Hi ztheory,
Thanks for the feedback.
I've been using a Cloud Print service named "Printix" recently (which is awesome BTW) and they identify networks using the Gateway IP and Gateway MAC Address. Do you think this would be helpful method to simplify your network detection?
I'll also look at your "NXDOMAIN" method you've suggested. Validating a CNAME or A record could potentially work just as well? ie. it might save having to create a local zone for this one purpose.
RE: the service start/stop issue
Potentially a configurable delay might be necessary after the "network change" event occurs. Some PCs and Firewalls seem to take a while to return a DHCP answer.
Regards,
Andrew
@ztheory commented on GitHub (Mar 6, 2022):
That would be more accurate than specifying a local IP or range to trigger on-prem, but again the variance of multiple networks, differing VPN gateways, multiple offices, etc, creeps in. However, this might make the initial deployment more difficult and error-prone as compared to the DNS query method. If someone forgets one of the gateway IP/MAC pairs, then pushes out the application, suddenly no one can resolve local DNS until an update is pushed or requires manual intervention. If the gateway device is changed internally, then another update.
I would imagine that being able to specify the FQDN in the application would be ideal, rather than having a hard-coded FQDN required by the application, so they don't have to create a specific zone or record for this solution, but rather, just use an existing FQDN that is specific to their local network. Yes, this is essentially resource record validation,
NXDOMAINorNOERRORare just the relevant response codes, which is probably simpler than implementing a request FQDN (some.fqdn.local), then actually checking for the response data (192.168.1.44). In this case, we only care if the record exists, as opposed to the value of the record response.@andrewbadge commented on GitHub (Mar 6, 2022):
Thanks. Let me have a look.
I think as a result the rule form might need to be redesigned. Its going to get a little busy.
@andrewbadge commented on GitHub (Mar 7, 2022):
Hi Zack,
I've been thinking about the NXDOMAIN validation. The only way this would work is if the interface is reset to DHCP after each change event then the validation is done. We'd need a pause to handle the response time of the DHCP which can vary; or some validation that the DNS values did reset.
Once the interface is back to DHCP, then we can safely perform validation. It seems a bit ugly. Have I got this wrong?
Example that won't work:
How it could work:
@andrewbadge commented on GitHub (Mar 12, 2022):
Hi Zack,
I think I've solved the question by specifying the DNS server to query in the rule. This avoid having to rely on the network or DHCP to reset then perform the query.
Can you have a look at the build and let me know if this is what you were expecting?
Service and Client:
https://github.com/andrewbadge/DNSRoaming/tree/main/Source/DNS%20Roaming%20Installer%20-%20Service%20and%20Client/bin/Release
Service Only:
https://github.com/andrewbadge/DNSRoaming/tree/main/Source/DNS%20Roaming%20Installer%20-%20Service%20only/bin/Release
NB: its not a release (to avoid people auto-updating to this version) until I've gotten more feedback.
@andrewbadge commented on GitHub (Mar 20, 2022):
Hi Zack, Did you have any feedback on the new build? Did it do what you expected?
Thanks
Andrew
@andrewbadge commented on GitHub (Mar 26, 2022):
Hi Zack, I'm going to close this issue as I'm assuming the new build does what you need. Let me know if you have further suggestions or ideas. Thanks Andrew