Flush DNS cache in Ubuntu

According to quite a few users on Stack Exchange, Ubuntu doesn’t cache DNS queries, but I got into an awkward situation where I couldn’t hit an internal server because my installation was convinced my internal server was being hosted on an external IP. 

It wasn’t entirely incorrect, because the server is (sometimes) available externally, but it’s only as needed. I have a few web serviced that need to be reached from outside and although I could use different ports, for ease, I just change the rules according to what service I want to use that day. I know, it’s very awkward and all I really need to do is set up a reverse proxy, but I am yet to get that done. It’s on “the list”! lol

I am using pfsense and the way I have it set up, the services I develop on need to resolve internally and externally. That means when I type https://subdomain.example.com/ and I am inside my network, I need it to resolve to 10.0.0.10 (for example), but when I am not on the network I need it to resolve to my public IP address.

pfsense handles this perfectly.

What I didn’t realise, is that because I mis-configured something, enquiries locally were hitting my public IP address and being hosted that way. Meaning, my DNS request was being directed to my external IP address instead of my internal one. When I changed the order of the rules to allow a different service access to the HTTPS port, I could no longer access my original service. 

Long story, short: my internal server was being accessed by my computer via the public IP address instead of the internal one. 

I fixed the entries in the firewall and now if I did nslookups and digs on the URL, the correct internal IP was being returned. 

Cool!

But it didn’t work. I still couldn’t access the service I needed, because Ubuntu was still accessing it from the external IP address.

Not Cool!

I restarted the resolver in pfsense in case for some reason it didn’t stick. But that wasn’t it. As I said, diging the firewall was returning the correct IP address, but pinging it was returning the external one. This took some time for me to work out that it was Ubuntu that had cached the URL, and it wasn’t the firewall that was now stopping me from accessing that page. 

Let me show you by example:

subdomain2.example.url (all URLs and IP addresses have been changed to protect the innocent) is responding with an internal IP address.

dave@home:~$ dig subdomain2.example.url

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> subdomain2.example.url
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63440
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;subdomain2.example.url.			IN	A

;; ANSWER SECTION:
subdomain2.example.url.		1655	IN	A	192.168.1.78

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Aug 26 23:58:37 AEST 2018
;; MSG SIZE  rcvd: 57

subdomain1.example.url is returning a public IP address (that’s not desired).

dave@home:~$ dig subdomain1.example.url

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> subdomain1.example.url
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2906
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;subdomain1.example.url.		IN	A

;; ANSWER SECTION:
subdomain1.example.url.	7112	IN	A	69.68.67.66

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Aug 26 23:58:48 AEST 2018
;; MSG SIZE  rcvd: 61

I knew this wasn’t quite right, but I couldn’t work out exactly why. So I asked my router where it thought the domain belongs:

dave@home:~$ dig @192.168.1.1 subdomain1.example.url

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> @192.168.1.1 subdomain1.example.url
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1846
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;subdomain1.example.url.		IN	A

;; ANSWER SECTION:
subdomain1.example.url.	3600	IN	A	192.168.2.111

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Mon Aug 27 00:08:02 AEST 2018
;; MSG SIZE  rcvd: 61

As you can see, the router knows the correct internal IP address, but Ubuntu is getting it from somewhere else. 

dave@home:~$ dig subdomain1.example.url

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> subdomain1.example.url
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33482
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;subdomain1.example.url.		IN	A

;; ANSWER SECTION:
subdomain1.example.url.	6551	IN	A	69.68.67.66

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Aug 27 00:08:09 AEST 2018
;; MSG SIZE  rcvd: 61

Then when I googled and found the above referenced Stack Exchange post and most answers were saying Ubuntu does not cache the DNS request, I just got confused. Not being confident of what I was looking at, I didn’t understand that the server IP address (127.0.0.53#53) was a loop back address for the DNS. I knew the port meant that it was a DNS, but I didn’t understand where it was being served from. Yes, I should have quickly realised it was only a loop back address, but I thought it was coming from the router (because of the DNS port entry).

hence my confusion. When I asked the router directly, it was reporting correct. But the computer was getting it from somewhere else.

And that TTL was killing me. I knew if I rebooted the computer it would more than likely fix the issue (it would have), but I had too many things open and I just didn’t want to go down that path. 

Eventually the light bulb turned on and I realised that Ubuntu simply must be caching it itself and I needed to identify the service and restart it. 

Scrolling right down the Stack post I found my answer. Although there’s several answers with differing methods of restarting the service, I went for the systemctl approach. 

sudo systemctl restart systemd-resolved.service

a ping and a dig confirms we’re good to go:

dave@redbox1804:~$ ping subdomain1.example.url
PING subdomain1.example.url (192.168.2.111) 56(84) bytes of data.
64 bytes from ubology.dav3 (192.168.2.111): icmp_seq=1 ttl=64 time=0.874 ms
64 bytes from ubology.dav3 (192.168.2.111): icmp_seq=2 ttl=64 time=0.295 ms
64 bytes from ubology.dav3 (192.168.2.111): icmp_seq=3 ttl=64 time=0.268 ms
^C
--- subdomain1.example.url ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 0.268/0.479/0.874/0.279 ms
dave@redbox1804:~$ dig subdomain1.example.url

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> subdomain1.example.url
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21571
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;subdomain1.example.url.		IN	A

;; ANSWER SECTION:
subdomain1.example.url.	3589	IN	A	192.168.2.111

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Aug 27 00:09:44 AEST 2018
;; MSG SIZE  rcvd: 61

dave@redbox1804:~$ 

Some other untested suggestions in the Stack post revolve around restarting the network manager, killing the process, flushing the cache using a command line switch (I probably should have tried that one, just out of curiosity), and restarting the service via init.d, and others. Posted for posterity and “next time” 

sudo service dns-clean
sudo service network-manager restart
sudo /etc/init.d/nscd restart
sudo kill -HUP $(pgrep dnsmasq)
sudo pkill -HUP $(pgrep dnsmasq)
sudo systemd-resolve --flush-caches
sudo systemctl restart systemd-resolved.service

Problem solved!

Now, for the next one:

I need to get a reverse proxy up and running. I did give it a go with squid, but I was obviously not getting something right. Further readings suggest HAProxy might be the way to go. That will probably be my next pfsense adventure.

WordPress MultiSite & sunrise.php

Are you getting the above error message as well?

After doing a fresh install and enabling multi-sites I couldn’t see the Domain Mapping and Domains sub-menu options under Network Admin / Settings.

I loaded up my trusty editor and confirmed

define('SUNRISE', 'on' );

was in fact in the file. It was slightly higher than where it said, it’s not important, but I moved it anyway, and I still got the error.

I checked and sunrise.php was in fact in the correct location under /home/public_html/wp-content/sunrise.php

So how did I fix it?

The problem was, it was the incorrect (read:old??) sunrise.php file!

Copy the correct one from:

/home/public_html/wp-content/plugins/wordpress-mu-domain-mapping/sunrise.php

and replace the previous one, and reload your admin page. You will now see the welcoming domains page :D

If you want to find out more as to why it happened, and how it is that my sunrise.php got “moved” or “re-moved”, it was due to a conflict by domain mapping plugins. I’ll be blogged about it in the near future and it will appear here (currently in draft and not published).

WordPress MU Domain Mapping missing

Screenshot 2014-12-02 05.39.14

Screenshot 2014-12-02 05.55.36
Domain Mapping and Domain options returned

When upgrading from version 0.5.4.3 to 0.5.4.4 and returning to the network admin site, I had lost all access to the domain management tools. The options normally reside under Settings (right) were no longer there. A quick check of some domains I have setup through domain mapping confirmed that it was still working, ie things were being redirected, however I couldn’t check, change, add or remove any mappings. I couldn’t see them at all.

I went into the Network Admin plugins page to find the plugin hadn’t re-enabled itself after the update. As far as I know, this is the first time any plugin has failed to reactivate. If this was by design, a few moments of stress would have been alleviated if some user warning could have been provided.

After re-enabling the plugin, all domain maps were right where they should have been.

WordPress and “You do not have sufficient permissions to access this page.”

W LOGOUPDATE: It’s amazing the number of hits this page gets, where people get this (or a very similar) error and this has helped them. I’m very glad this helped, but I just want to add, this page is more than 3 years old now and although the logic is simple here, remember it is old and “things” may change (eg, plugin folder name, or how plugins are managed to name just two). I hope this helps you. Good luck

Years ago I hand-coded my first website, and sometimes I still do the odd bit of dabbling like that. But these days there are so many great content management systems (CMS) out there, that really, why bother. I use to use Druple, and I have nothing against that, but a while back now I migrated to WordPress…. All was fine until…

The other day I upgraded using their backend and I lost all permissions. Any guest could use the site as normal, there were no problems there, but I couldn’t login. It took a few days searching on the web (without luck) and eventually, I jumped back into cpanel, and phpmyadmin and started digging.

The solution was a lot simpler than what I had envisioned.

During the update process, one of the plugins caused havoc in the backend, and when trying to display the dashboard, the plugin was breaking privileges. First I had to work out, which plugin it was, and if in fact if it was a plugin that was the cause. As it turned out, it was, and this is how I found it:

1. created a new folder called “old_plugins” *
2. moved all the plugins from the “plugins” folder to the “old_plugins folder” *
3. logged in – sweet – I was allowed and all appears good
4. visit the plugins page (you will get a warning that your plugins have been deactivated since they can’t be found.
5. put the plugins back into their original directory *
6. reactivate each plugin until you find the faulty one. For me it was a google reader plugin for the dashboard, which I never used anyway – so it’s now gone!

Once you find the faulty plugin, you’ll get the permission error again, simply go back to your ftp or file manager (I just used cpanel) and move the faulty plugin out…

* You could probably have just renamed the plugins folder, visited the plugins page, re-renamed the plugins folder, and gone through the reactivation process that way, this is just the way I did it.

also (cross)-posted at wordpress.dav3.net