Re: DNS resolution of local clients (DHCP)

I had to use the above updated scripts as many clients (ios, cameras, etc) did not make it into the hosts file for the same reason as above. The updated script resolved this, but for clients that are configured as "static" in the controller, the entry is added using the MAC name as the name in the /etc/hosts file instead of the real name. When made not static, the real name is used instead. Any idea why and how to resolve it transparently when defining a client as "static"?

In the interim I defined static-host-mapping entries for the ones that are "static" but would have expected the dhcp handling registers it using the name.

Re: DNS resolution of local clients (DHCP)

I don't see any appreciable difference in DNS operation from prior versions. I do now see a "Site Name" under Settings > Site, which I set to be my domain name. Also, hosts that previously were being added with spaces no longer appear to be...

However, hosts are still being added to /etc/hosts with whatever they identify themselves as, including capitalization, and static aliases are ignored. FQDN hosts don't resolve properly (hostname+domain), only hostname queries resolve properly (not sure if this was supposed to be fixed with the addition of the Site Name).

Re: DNS resolution of local clients (DHCP)

I don't see any appreciable difference in DNS operation from prior versions. I do now see a "Site Name" under Settings > Site, which I set to be my domain name. Also, hosts that previously were being added with spaces no longer appear to be...

However, hosts are still being added to /etc/hosts with whatever they identify themselves as, including capitalization, and static aliases are ignored. FQDN hosts don't resolve properly (hostname+domain), only hostname queries resolve properly (not sure if this was supposed to be fixed with the addition of the Site Name).

Site name is not the domain name, that's strictly for reference/display, has no functional impact (and has always been there). The domain is set in the network configuration for each network, and requires being on 5.5.x controller. Settings, Network, edit the LAN for instance, set there in Domain Name.

Registration of aliases is new to 5.6.x versions, and pending UI to be usable. That likely will make 5.6.4.

Re: DNS resolution of local clients (DHCP)

Cloud Key firmware ships with the latest official stable release controller version, which is 5.4.x at the moment. 5.5.x is currently stable candidate soon to be the next stable, 5.6.x is development/unstable. You can download the .deb of any controller version to the CK and 'dpkg -i <filename>.deb' to install.

Re: DNS resolution of local clients (DHCP)

Cloud Key firmware ships with the latest official stable release controller version, which is 5.4.x at the moment. 5.5.x is currently stable candidate soon to be the next stable, 5.6.x is development/unstable. You can download the .deb of any controller version to the CK and 'dpkg -i <filename>.deb' to install.

Where do you find the 5.5 and 5.6 versions? I'm only seeing 5.4 on the website for download.

(I'm sure you think I'm a pain in the arse, but I really am just trying to solve these DNS issues with my Ubiquiti network (since October, 2016), I'm otherwise very pleased with the equipment, setup, and configuration, DNS is just a thorn).

5.5.11 and 5.6.3 will be coming next week. If you want to go to 5.6.x, I'd wait until 5.6.3 is posted to beta blog. If you're not using multi-WAN, then 5.5.9 is a fine choice. (5.5.10 was internal-only)

Re: DNS resolution of local clients (DHCP)

So I just got through round two of purchasing the USG and getting ready to return it yet again for this exact issue. Windows 10 DNS not being set properly at all nor being forwarded through the USG at all. My controller is on atag_5.7.23_10670. Can anyone confirm if the fixes for DNS mentioned in this thread are indeed resolved for you? I have a support case open with limited engagement since Friday with support.

Re: DNS resolution of local clients (DHCP)

I no longer have the issue stated in this thread. You should check the TCP/IP configuration on the windows machine you're using and make sure it's taking all its configuration from the USG and has not been manually specified to use Google's DNS servers or something like that.