How To: Resolve Multicast DNS (mDNS) using Dig in Linux

Sometimes it can be nice to verify that the hostname on your box (printer, raspberry pi, whatever) is resolving to the correct IP-address on the LAN.

Whether it’s published via Avahi, Bonjour or something similar. An mDNS request resolves to.

  • IPv4 address or IPv6 address ff02::fb
  • UDP port 5353

This can be achieved with dig, example:

~$ dig whatever.local @ -p 5353

Example output

;whatever.local. IN A

whatever.local. 10 IN A

whatever.local. 10 IN AAAA fe80::;;
whatever.local. 10 IN AAAA fdaa:;;

Happy resolving!

How To: Mitigate Mozilla Firefox HTML5 Video Performance Issues

A neat feature of the modern web is that Adobe Flash Player is (finally) starting to be replaced by HTML5 apps, and that includes video playback such as YouTube.

During this change I have, among allot of other people on the Internet, noticed that our favorite browser is not yet optimized for this future proof technology. And enabling (now default) HTML5 playback can lead to audio/video stutter and high CPU-usage.

Until support for hardware acceleration is more widespread in Firefox Quantum, I’ve found a work-around on the Mozilla Support page. Which is:

Simply go to Settings > General > Performance and bump up the Content process limit (Uncheck Use recommended performance settings).

It seems, at least for me, help with the CPU utilization when playing HD/4k video on YouTube.

Read more at the support article:

How To: Redirect HTTP Traffic to Proxy Using iptables

Invisible Traffic

Proxy Madness

Using Squid or any other proxy for transparent caching/filtering of HTTP traffic has many benefits, being for logging purposes or the aforementioned use-cases, keeping every client configured can be a nuance. Networking equipment from Cisco and Juniper has the ability to redirect all passing HTTP traffic, in IOS and JunOS respectively, to the desired proxy.

A more cost-effective solution is to use a Linux box inline the client network and the “Internet”, redirecting HTTP traffic to a separate transparent proxy box, before it reaches the Internet.

Another, more realistic (…), use case. Is to use the transparent caching proxy server inline the VPN Server, VPN Client and the Internet. Example below.

VPN Client --> VPN Server --> Caching Transparent Proxy --> Internet

The benefit being that the VPN Server can resend cached content to the VPN Client, reducing latency for the server and the connection as a whole.

The Solution

Using the example above, traffic redirection using iptables most efficiently takes place on the VPN Server.

Below is the required configuration:
~# iptables -t nat -A PREROUTING -i [TUNNELIFACE] -p tcp -m tcp --dport 80 -j DNAT --to-destination [PROXYIP]:[PROXYPORT]

Working example:
~# iptables -t nat -A PREROUTING -i tun0 -p tcp -m tcp --dport 80 -j DNAT --to-destination

As an end note. For best results and lowest possible latency, the VPN Server and Caching Transparent Proxy should be on the same network, preferably on the same network switch.

Happy Caching!

How To: Netcat – Check for open ports with the command line

NetCat PortKitty Port-checking

When troubleshooting a network integration or any other connection issue in Linux, step one is usually a matter of checking to see if the network port on the other side is even responding.

Netcat -The network Swiss Army knife (Hobbit, not nmap)- is the right tool for the job.

Before we begin, NetCat needs to be installed.

# RHEL / CentOS
~$ yum install nc

# Debian / Ubuntu
~$ apt-get install nc

Once installed, you can invoke Netcat like so:

[REMOTE_SERVER] – The server to be checked
[PORT] – The service/port to be checked



Connection to 443 port [tcp/https] succeeded!

Client side Security, How’s My SSL? (.com)


Years ago,

Moxie Marlinspike taught us that web-browser hints such as a “lock icon” in the address bar, didn’t guarantee ciphered communication. Since the website you are visiting still happily falls back to plain http since you, the user, made an effort to not be redirected from a clear to ciphered session… Not really. Man-In-The-Middle is so very unforgiving to its victims.

Even though major websites, the giants, such as Facebook, Google and Micro$oft products such as Has mitigated this fallback bug somehow. Smaller websites, such as Intranets and self-hosted WordPress blogs, is still vulnerable. Two-factor authentication solves the credentials issue, this is about privacy and information sanity. TLS or not, what cipher am I using anyway?

There is a website,, which tells you what encryption ciphers are currently being used by the browser, in the order the browser sends them. Also, it list common and newly discovered vulnerabilies in the SSL/TLS protocol. What I find particularly interesting, is the cipher suites listed at the bottom of the page. To still see RC4 is getting very tedious…

Lab Time!

Just for fun, I disabled all the insecure ciphers I could find and made TLS1.1 the minimum required TLS version in Mozilla Firefox. For the first two weeks, every https I visited worked fine. Until I had some banking piled up at the end of the month…

Apparently my bank still uses TLS1! Mozilla won’t let me continue! And what’s even more surprising, is that the error message speaks of SSL3? For two protocols with only three years apart, maybe there isn’t much difference?

Nevertheless, I called my banks end-user technical support and explained the issue. And what did they tell me? To use another browser…


With the big scary Internet growing and tighter supervised than ever. Datacenters spinning with almost unlimited capacity, these 90’ts encryption protocols are surely broken. The old reheated excuses for large company’s to not implement https -not enough capacity, bandwidth, offloading etc- don’t apply anymore.

Out with the old, in with the new