Roadmap

Customer Feedback


Voters 8

  • A
  • A
  • A
  • A
  • A
  • A
  • A
  • + 2 voters
  • A
8

Support Internal DNS for domain joined devices

  • Complete
A
 Anonymous

Windows domain joined devices need internal/local DNS to function correctly. DNS Guard right now forwards all traffic externally.

  • 10-01-2023 -
A

Activity Newest / Oldest

P

Peter Bin

We've released our new client with support for Internal DNS & IPv6. You can download the client via our Portal.

New clients can be enrolled immediately with this version.

Clients which have version 1.0.0 installed currently, will have to uninstall and perform a clean install.

Thank you all for your feedback and patience!

P

Peter Bin

We have identified an issue where the installer would not start/configure DNS Guard client correctly upon installation.

We don't have an ETA for now.

We're busy investigating this issue to resolve it as soon as possible.

P

Peter Bin

We're expecting to release the DNS Guard client with Internal DNS Support officially next Monday!

P

Peter Bin

We have identified an issue where the DNS servers would not be configured automatically. In this case a user needs to set their DNS servers to 127.0.0.1 themselves. We will fix this in a following BETA update of the client.

P

Peter Bin

We've distributed the DNS Guard client with internal DNS support to anyone who let us know they wanted to test with the client. Please let us know if you want to join testing.

We're updating our documentation about the client: help.securityhive.io/en/articles/8075734-features-and-mechanism-of-dns-guard-client

P

Peter Bin

We've finished our internal tests and will be reaching out to BETA testers in the next few days with a BETA version of the client with internal DNS support. We haven't experienced any problems so far. We've also implemented endpoint health checks, hosts, and mDNS support.

P

Peter Bin

Hi all,

Thank you for actively sharing your thoughts and voting for this feature! The discussion is very helpful for us to develop this feature.

We're making progress with the support for internal DNS. Our development version of the client supports static internal dns now.

At this moment we're developing the support for dynamic internal dns support. This means the client will discover the DHCP lease given and extract both search domain and internal DNS server. It allows a client to switch networks and keep the internal DNS working.

We've also added support for mDNS to improve support for services like AirPlay.

We're getting there and thank you for your patience. It won't take long anymore, as this has our highest priority. Once more information available, we'll let you know as soon as possible!

P

Peter Bin

Jan Staal: Thank you for giving your feedback! This would be a good solution indeed besides our IP-linking option. However, most of the voters waiting for internal DNS support have roaming devices like a laptop that sometimes is connected to the office network, and sometimes to the home network.

In both cases they need to get protected by DNS Guard, but when connected to the office network they need to be able to reach out to internal devices.

A

Anonymous

Yes off course; that is what we do. And this works fine for agentless devices. But what happens now is that computers where DNSGuard agent is installed always forward DNS requests tot DNS Guard. When they want to access a local resource "nas01.domain.local" or just plain "nas01" it couldn't be resolved. The agent should be aware of local DNS. Any update on the beta?

A

Anonymous

It would be better to forward the DNS requests from the domain controller to the DNS Guard, this way the internal devices can use the "Active Directory Intergrated DNS Server" for DNS and the AD DNS server forwards the requests to DNS Guard when not resolved by the "AD DNS". This will make it easy to implement in an Active Directory Environment and will allow the use of multiple forward lookup zones which might not end with ".local".

For example mail.domain.com externally resolves to a public IP. But with a forward lookup zone internally it will resolve to an internal IP. While the FQDN in the AD structure could be domain.local.