Upgrading cloud key sucks but works. After upgrade log in to unifi ui. You would see blue lights back on. Disable system-d. Check if dnsmasq is working, if not try to install resloveconf package.
Login to your cloud key and make sure its working (blue lights :))
DNS resolution will not work. The problem is pihole unbound resolution. Add these lines to /etc/resolveconf.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
check the status of dnsmasq;
#disable systemd-resolved first
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
sudo systemctl status dnsmasq
sudo systemctl status dnsmasq
If dnsmasq is running, proceed. don’t restart. reinstall pihole and restore from backup. Follow these after pihole installation (couldn’t find an easier solution);
#Reconfigure lighttpd port (for example 8080)
nano /etc/lighttpd/lighttpd.conf
#Restart lighttpd
/etc/init.d/lighttpd restart
#Change the pi-hole random password to your liking
pihole -a -p
Pi-hole has dnsmasq embedded in pihole-FTL, and a separate dnsmasq on the host is not required and causes problems as you have discovered.
Non-authoritative answer simply means the answer is not fetched from the authoritative DNS server for the queried domain name.
First you have to understand how DNS system works. DNS system can be divided into three tiers. They are:
root DNS servers
top-level domain DNS servers
authoritative DNS servers
There’s another class of DNS Server usually called local DNS server whose IP address is specified on your operating system.
When your browser connects to a website say example.com, the browser first queries your local DNS server to get the IP address of example.com.
If the local DNS server doesn’t have the A record of example.com, it will query one of the root DNS servers.
The root DNS server will say: I don’t have the A record but I know the top-level domain DNS server which is responsible for .com domains.
Then your local DNS server query the top-level domain DNS server which is responsible for .com domains. The TLD DNS server will respond: I don’t know either but I know which DNS server is authoritative for example.com.
So your local DNS server queries the authoritative DNS server. Because the actual DNS record is stored on that authoritative DNS server, so it will give your local DNS server an answer.
Then this query result is cached on your local DNS server but it can be outdated. When the TTL time has expired, your local DNS server will update the query result from the authoritative DNS server. Whenever you query a DNS record on your local DNS server, it returns a non-authoritative (unofficial) answer. If you want an authoritative answer, you must explicitly specify the authoritative DNS server when you use nslookup or other utilities. I think a local DNS server should be called caching DNS server.
When someone registers a domain name, he/she can specify which DNS server is the authoritative DNS server. This information is called an NS record. The NS record will tell a top-level domain DNS server which nameserver holds the domain’s A record, MX record, etc.
run nslookup and enter this;
The authoritative name servers for this domain are in red block.
I have upgraded cloud key with UDMPro. UDMPro don’t have a DNS. I plan to use Cloud Key as DNS and wanted to install PI-HOLE on it.
Followed these steps.
a) Factory Restore Cloud Key Power off the system.
b) Press and hold the reset button and then power on the Cloud Key by connecting it to the power source.
CloudKey G2 Plus
Keep the reset button pressed for about 10 seconds, or until you see the recovery LED pattern in a loop (blue – off – white). The LCD screen on the front panel will also read “RECOVERY MODE.”
Once the LED is flashing in the recovery mode pattern, open your browser and type the IP address for the Cloud Key, visible on the device’s screen. The IP address comes from your DHCP server, if you can’t access DHCP, the fallback IP will work: 192.168.1.30. However, keep in mind that if your Cloud Key does have a IP address assigned by the DHCP server, the fallback IP will not work.
You should be taken to the Recovery Mode screen. From here you can reset, reboot, power off and most importantly you can upload an updated firmware bin file.
Click ton Reset to Factory Defaults and then Reboot. It would take 2-3 minutes to come back with a steady white light. You would see information on the LCD that its ready to be configured.
2) Open your browser and type the IP address for the Cloud Key, Disable update/diagnostic in wizard
Let it set up. After update, I can see UniFi OS Version2.3.10 on Cloud Key.
Uninstall All applications, Settings -> Update. There are three dots on the right of application icon, click and uninstall.
Enable SSHS by going into Settings -> Advanced and SSH.
Open Putty and SSH into Cloud key;
User = ubnt
Password = your password
We are in console. If for some strange reasons, Web URL doesn’t work but SSH works, then cloud key can be reset to factory defaults by running this command;
/sbin/ubnt-systool reset2defaults
It’s time to re-purpose cloud key. I have found this sequence on unifi forum. Follow step by step;
#go superuser
sudo –i
#Let’s install nano to make conf edit easier
apt-get install nano
#Install dnsmasq
apt-get update
apt-get install dnsmasq
#(Answer Y to replace the files as keeping the existing will point to 01-pihole.conf which does not work until pi-hole is installed)
# Ubiquiti switched the resolver to systemd-resolved which reserves the port 53
# dnsmasq install will fail to start dnsmasq so lets resolve that
# Pi-Hole related
# Command to see if the database exists:
stat /etc/pihole/pihole-FTL.db
#If it does, then run these commands:
sudo service pihole-FTL stop
sudo rm /etc/pihole/pihole-FTL.db
sudo service pihole-FTL start
# Pi-Hole stores its 24 hour log here:
/var/log/pihole.log
# debian related
dpkg --list
systemctl status lighttpd
systemctl start lighttpd
systemctl stop lighttpd
systemctl restart lighttpd
# List of ports that are in use
sudo lsof -l -P -n | grep LISTEN
One last thing, you can install this tool on a different device but you’ll probably have to;
chown "user" /usr/local/bin/
“temporarily” on the terminal of your different device to make it work. The tool just pulls the current docker image from dockerhub so it doesn’t need to be ran on the same machine if you don’t want to.
