Archive
Clear DNS Cache from DCHP on Unifi Security Gateway
I’ve got a Ubiquiti Unifi home network setup … yes, I’m a complete nerd. I love it. It’s been rock steady for years and it’s super-fast. The one issue I’ve had, though, is that various network tools will label devices on my network with the wrong device name via reverse-DNS lookups.
For example, for the last 18 months my MacBook Pro has shown up as “Jenna’s iPhone” in Pi-hole – and even MacOS has reverted the “sharing name” of the computer to that from time to time. If you’re wondering, Jenna was one of my daughter’s friends who visited years ago for a sleepover and hopped on our wifi network. You can turn off the register DNS name on DHCP lease feature if you want to, but frankly it’s helpful to be able to reverse-lookup things once in a while. If anything, the bug here is that there’s no age-out function for the cache … which is the hosts file on the USG.
Long story short, just like Pepperidge Farm remembers, so does my Unifi Security Gateway (DHCP and DNS server).
Today I got fed up and decided to do something about it. I’m documenting this here so Future Nathan (and present you) can figure this out too. Big shout out to Howard Durdle’s little post to his future self here: Clearing Ubiquiti UniFi USG DNS entries.
Step 1: Make sure you can SSH into your USG. In the controller portal (or whatever you want to call it) go to Settings > System Settings > Device SSH Authentication. Make sure you’ve got Device SSH Authentication turned on and a username and password configured.
Step 2: Login to your USG over SSH. Pretty easy from a Win10 PowerShell window. Just provide the IP of your USG (which should be your default gateway) and use the -l command to specify the username. Enter the password when prompted. You may need to accept the SSH key if this is your first time logging into the USG. Just say yes.
ssh 192.168.x.y -l <username>Step 3 (optional): Verify the USG’s hosts file is the problem. Look at that – crap that’s been there for years!
cat /etc/hostsStep 4: Spring cleaning. This uses an elevated VI instance to do the damage. Standard caveats apply, don’t be stupid. Just like editing the Windows registry in regedit, if you don’t know what you’re doing and aren’t comfortable having to nuke things and start over, don’t proceed. “There be dragons here”.
Once you’re in VI use the arrow keys to navigate to the line you want to delete and type dd (reference). I’m not sure if the lines for the Unifi gear itself will be regenerated, so to be safe leave the lines for your USG’s IP address and any other critical infrastructure.
To safe the file and exit VI, type :wq and you’ll find yourself back to the USG’s prompt (reference).
Step 5: Restart DNS on the USG. This will load the updated hosts file.
sudo /etc/init.d/dnsmasq force-reloadYou’ll see something like…
@MainRouter:~$ sudo /etc/init.d/dnsmasq force-reload
[ ok ] Restarting DNS forwarder and DHCP server: dnsmasq.And that’s about it. You shouldn’t have Jenna’s iPhone on your network anymore. 🙂
Security for security’s sake is dumb
I added the Microsoft TechNet Radio RSS feed to my Zune desktop a long time ago, but never got around to listening to any of them. While I’m working today I’m finally getting a chance to rectify that oversight. 🙂
I’m currently listening to an interview with Alan Levine from April 2006 (“TechNet Radio Security Series – an interview with Alcoa’s CSIO”). At that time (maybe still today?) Alan was the Chief Security Officer for Alcoa, the aluminum company. At one point (about 18 minutes in) he makes a great observation on how some people in IT try to secure everything for the simple fact that they can … “security for security’s sake” as he says. It’s a bad idea, Alan explains…
“and if you don’t believe that, tonight when you go home park your car in the driveway with your wife. You both get out and you go into the house, and before she can come in lock the door. You’ll find out that security for security’s sake serves no purpose.”
I’m a huge fan of giving real-world, non-IT examples of tech scenarios to help people better understand what’s going on. This is an awesome example of that … and one I’ll have to borrow!
Virtual ‘kumbaya’
VMware and Microsoft both said they’re working behind the scenes to make it easier for virtualization users to migrate across their differing virtualization environments and run each other’s virtualized files.
But so far, it’s only virtual kumbaya. Neither one is saying how they’re going to do it.
I am a staunch believer that virtualization is the next big frontier in enterprise IT (and probably computing as a whole, all the way down to the consumer level). I can’t wait too see what my datacenters and services are going to look like in 5-10 years.
I think it’s going to be a long and painful road to get there, as evidenced by Microsoft’s continuing delays and feature cuts of their Veridian hypervisor.
All that being said, I’m glad to see the major players in virtualization at least starting to talk. I’m not going to hold my breath on the outcome – I’ve been burned by false hopes in the past. But at least it’s a start.
It all depends…
Omar Shahine wrote a great article entitled Designing for Services Dependencies. If you’re involved in IT at all this is a must read, no matter whether you’re a developer or on the operations side.
If only more developers would understand the dependencies they add into their systems!
Here’s a quick chart that talks about “The Nines”. You’ll hear people talking about wanting to have “five nines” of availability. Good luck with that! 🙂
| Reliability | Downtime / year |
| 99.999% | 5 min |
| 99.99% | 53 min |
| 99.9% | 9 hours |
| 99.8% | 18 hours |
Nathan's Occasional Blog 