05-05-2016 04:54 PM
05-09-2016 07:48 PM
@Robrecht Yes, we heard that from other users too. And that is exaclty what we plan to do.
Hopfully spreadsheet or CSV import is part of those plans
Having wifi problems? Take a look here first: https://help.ubnt.com/hc/en-us/articles/221029967-UniFi-Debugging-Intermittent-Connectivity-Issues-on-your-UAP
05-10-2016 02:00 AM
Yes, good idea.
09-02-2016 02:06 AM
Any idea when the static naming and resolution will be implimented, I am on the latest Alpha build for Unifi and its not in there, but there is some firewall related entried that look promising.
09-02-2016 11:10 AM
Adding @UBNT-cmb for this one. We've been focusing on stability improvements across customer installs lately so features have taken a back seat.
10-05-2016 08:29 AM - edited 10-05-2016 08:30 AM
New here, just set up my unifi setup with USG and oh would this feature have saved me a day or two of head scratching!
It seams that as soon as you set a client to use a static ip address it's hostname on the dns is replaced with it's mac address.
To me this does not require any changes to the interface, why would you want this behaviour instead of it continuing to use the hostname?
Now when you use an alias I agree it would be great to have a check box to say add as DNS entry.
But first things first should'nt the hostnames that get used when a client has a dynamic address also be used when it has a static address?
Note I'm reffering to clients that use DHCP to receive thier static address.
For those that do not use DHCP, the use of the alias is a good way to define thier name.
10-10-2016 11:03 AM
I use the "Static DHCP" method to address things that are a pain to manually address or that may move to other network segments. The best example of this is my MacBook. I want it's wifi adapter to have a known address at home for things like SSH and Web Devel, but obviously I leave with it and don't want to mess with the adapter when I get somewhere.
The other the good one is a PlayStation 4 which seems to forget it's static address after a few reboots.
It may seam OCD but I like to put like objects into groups of IPs. So all the TiVos are in 192.168.x.5x space. Then of course I want to be able to check if one is online by pinging TiVo-bedroom.
12-20-2016 02:36 PM
Any update here from the Ubiquiti team? This has been coming soon for quite a while. I have been on the testing channel for a while now and you guys have made significant stability improvements in the last few months. Will feature development get some more attention soon?
12-21-2016 10:51 AM
I too would really like this feature. For the same OCD reasons.
This may be unrelated but my USG will occasionally assign the wrong static IP to devices initially. This is even more interesting as all my static IP's are out of the DHCP range. This seems to correct itself after the orignal lease expires, but if the device to whom the orginal IP was assigned joins the network it will get assigned the proper IP leading to two devices sharing the same IP.
unifi 48 port 750 PoE switch
AP-AC-Pro acess points x2
All running latest firmware updated on Dec12
Computer A- Static IP 192.168.2.51
Computer B- Satic IP 192.168.2.61
USG DHCP range is 180-250
Computer A is turned on and joins the network and is INCORRECTLY assigned 192.168.2.61 (computer B's IP).
This leads to problems when I'm using the IP to talk to that computer.
a) Wait. In a day or so it will correct when the lease expires and is renewed
b) disconnect and reconnect the device from the network several times and eventually it works
Computer A is turned on and joins the network and is INCORRECTLY assigned 192.168.2.61 (computer B's IP).
Computer B is than turned on and is Correctly assigned the IP of 192.168.2.61.
Now BOTH computers have been assigned 192.168.2.61
This essentially makes both Computer A and computer B unusable. It took awhile to figure out what was wrong.
a) Turn off both computers several times. Pray a little bit. Eventually it will work. It seems to work best when I reassign the static IP to each computer again
Unfortuately, this has happened a few times and I'm a little worried everytime something gets turned on, but I can't leave everything on all the time
02-02-2017 04:32 PM
And is that how I could set all my hostnames as I transfer over from an existing consumer router?
What ties the MAC address to a hostname though, or is that another option I need?
04-08-2017 04:41 AM
I need to bring this up again as I am struggling with the CLI.
I used the commands as mentioned above.
configure edit service dns set forwarding options host-record=mutter,192.168.2.14 commit save exit exit
However, I am still not able to ping this server
macbook12:~ mike$ ping mutter ping: cannot resolve mutter: Unknown host
But surprisingly nslookup works
macbook12:~ mike$ nslookup > mutter Server: 192.168.2.1 Address: 192.168.2.1#53 Name: mutter Address: 192.168.2.14
So where is my mistake please?
it seems to be registed (with a lot of pain) but not even a chance to ping it....
I am clueless
04-08-2017 05:02 PM
There have been a number of related improvements recently in that regard @mbrust. It depends on which controller version you're on whether that's relevant, or even necessary at all.
First, if that device is a DHCP client or has a DHCP reservation, you don't need to add anything like that at all. Make sure you're on USG 4.3.39 as it has some relevant fixes.
If it's a static IP device you want to register, then you need that host-record. But it needs to be a FQDN, not just a non-qualified hostname. If you're on a recent 5.5.x or newer controller, you'll have a default domain field there when you edit the LAN network. "localdomain" by default. If you changed that to something else, replace accordingly.
When your host does a lookup for "mutter" with localdomain as the default domain, it does a lookup for "mutter.localdomain", not "mutter". So you need to register it accordingly as "mutter.localdomain".
If you're not on a controller version new enough to have default domain, you'll want to be. Some OSes won't do DNS lookups at all for non-qualified hostnames unless they have a default domain assigned, rather fall back to LLMNR only.
04-08-2017 11:09 PM
Dear @UBNT-cmb, I can confirm that .39 is a great improvement (running controller 5.5.9 here), the behaviour is much better now.
also thanks for the explanation regarding the domain handling, this is definitively different than on my non-unifi environment before.
I still have one crucial device (surveilance cam / foscam) which does not properly register although it is a DHCP client, so I have to use ip address rather than a hostname. I blame the camera :-)
Again, thanks for your feedback.
04-09-2017 07:34 PM - edited 04-09-2017 07:35 PM
That behavior of DNS isn't UniFi-specific, most other things just happen to set a default domain out of the box and probably append it automatically where defining a non-fully qualified hostname. Which is same as what UniFi does now, outside of the manually configured hostnames like that.
The camera in question likely either doesn't submit a client-hostname in its DHCP requests, or maybe sets it to something other than the name you're expecting. Checking "show log" output on USG after doing something to make it trigger a DHCP renewal will show what hostname, if any, it's sending. Or "show dhcp leases" output.
10-02-2018 10:50 AM
Oh, interesting. So what you proposing is to say have a section where you could enable DNS entries for the names entered?
Kinda hate to dredge up a 2.5-year-old thread, but this is an issue that just cost me considerable time and hassle when trying to set up a Pi-hole DNS server in conjunction with my USG-P3, which is handling DHCP duty (every permanent device on the network has an IP reservation). Pi-hole worked great, but only a couple hostnames were resolving in the logs -- everything else was just the IP address. The conclusion I finally reached was that the majority of my clients (smartphones and IoT stuff) aren't passing along hostnames with the DHCP requests, and since the USG isn't assigning anything, the Pi-hole has nothing to return except IP addresses. I worked around this by manually editing /etc/hosts on the Pi-hole, but that creates unnecessary maintenance when I add/remove/change devices.
As far as I can tell, this suggestion was never implemented. Is that correct, or am I missing something? (My controller is running the latest release.) If it wasn't implemented, why not? And is there (or could there be, please) any plan to do so in future? From an end user perspective, all it would take would be adding an optional "hostname" field along with the IP address when assigning a fixed IP address to a client. Obviously I don't know what that would take from a technical perspective, but it doesn't seem an insurmountable request. Attaching a mockup of what I envision; new field is in red. If this is already implemented and I've missed it, I still think this would be a logical place to show that info.
Disclaimer: I'm a home networking neophyte who knows just enough to be dangerous and make his wife angry when stuff doesn't work.
10-02-2018 01:15 PM
The "name" should be the value that the consumer transmits as part of the DHCP. If the consumer doesn't transmit a (short) name as part of the DORA process, then no name or perhaps a value of "dhcp-<ip>-<ip>-<ip>-<ip>" should be used.
Comments/Suggestions for functionality (a bit 'wish list' too):
- There should not be an "alias" field, rather a "Name" field. Introduction of naming (outside of DNS) only creates issues. By default it should be the value transmitted by the consumer, otherwise it becomes an ovverride.
- If name specified (as shortname):
- Creation of A or AAAA and PTR records into the local DNS Service when there is an active lease (removed if no active lease)
- Adjust DHCP to include transmission of Option 12 (hostname) to send the (shortname) value to the consumer. Although some consumers ignore this value (Android-based consumers are notorious for behavior)
- DNS suffix should be obtained via DHCP Option 15 from the network's configured value.
- For various services, the value in DNS (FQDN) vs. the value that a consumer purports itself (FQDN) need to match, otherwise it can create issues (latency at a minimum due to increased validation requirements). Such as UNIX Kerberos (also utilized as the underpinnings of MS auth services)
- Ability to create empty zones to prevent invalid lookups from going outbound. Example: includes the TLD of "local", the RFC-1918 networks and a few more. DNS lookups for entries in any of these should never leave an organization/entity's environment. This would add an additional measure of protection for home user/prosumer environments. The ability to 'negate' this for corporate/enterprise use would be critical. eg: branch/remote user with local cache, otherwise forwards up to corporate DNS servers.
- These should be "enabled" by default with the ability to disable.
- Ability to specify entries for static devices via the GUI. Entry of FQDN and IP Address should result in creation of both A or AAAA and PTR records.
- If local DNS service is only being utilized as a cache-forwarder and DHCP is provided locally - the ability to have DHCP manage the DDNS entries on behalf of the consumer (into the appropriate external DNS Server)
The following zones are the DNS namespaces that should never appear on the Internet, as they are either "private" or special purpose. If queries for any of the above exit an organization's environment, it can reveal namespace and/or internal IP Addressing information. These are sometimes referred to as the RFC-6303 zones:
local (the entire TLD, it's the RFC-1918 equivalent for forward DNS)
NOTE: Specified IPv6 networks in CIDR notation due to long string value. Example:2001:db8::/3 = 8.b.d.0.1.0.0.2.ip6.arpa
11-25-2018 11:51 AM
Some information about this on the horizon? Or stil a "fata morgana"...
Can one of you bring some light into this darkness.... thanks.
I've just switched my pfsense fw for a USG. But al these simple DNS and DNS overide options (and DHCP, but some are there... like fixed address) things are really missing here.
I really hope it will be implemented soon.