If you’ve recently upgraded your network from IPv4 to IPv6, you might find that some software no longer works as it had before. Apache Tomcat is one that I recently stumbled upon, as it seems to prefer the IPv6 connection and stops listening on IPv4 with the default configuration.
The solution is simple, you just have to tell the server to listen on all incoming IP addresses. This worked for me with versions 7.x and 8.x, and I suspect that older and newer versions would be similar.
sudo vi /opt/tomcat/conf/server.xml
- To each
<Server> entry add:
- Restart Tomcat
As an IT professional, I’ve long been aware of the impending IPv4 exhaustion. To the layperson, this can easily be compared to phone numbers… there are now so many devices connected to the Internet that the size of the number used to identify and reach each of them uniquely is impossible.
IPv6 is a newer addressing system that supports a drastically increased number of addresses/numbers for use. Unfortunately, like Digital TV (in the US), adoption and migration of users and websites is slow.
To do your part as a user, you can change the settings in your gateway/router/modem to allow for IPv6 DNS lookups as most providers already support IPv6 traffic.
You can test your connection here:
Here are a few common values, I’ve also provided the Comcast/Xfinity values for reference:
- 126.96.36.199 (resolver1.opendns.com)
- 188.8.131.52 (resolver2.opendns.com)
- 184.108.40.206 (resolver3.opendns.com)
- 220.127.116.11 (resolver4.opendns.com)
Ubuntu updates occasionally fail due to IPv6 update servers not being reachable. While I prefer to keep IPV6 activated, this approach will allow you to disable it for updates, simply reverse the steps to re-enable afterwards!
- Update the configuration file…
sudo vi /etc/sysctl.conf
# IPv6 disabled
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
Then, you must enable the change…
sudo sysctl -p
- To verify…
This is a simple mechanism, using DNS to certify that email from your domain comes from authorized servers. This is accomplished by adding a DNS record to identify the servers from which you send legitimate email. Emails sent from other servers MAY then be assumed as forged (SPAM) and blocked by the receiving email server.
NOTE: This can be easily spoofed, as such it should be a portion of your email security strategy, look into DKIM and DMARC too!
One thing that I initially did not understand… if you are supporting IPv6 and IPv4, you should merge your records onto a single DNS TXT entry:
example.com TXT v=spf1 a mx ip4:xxx.xxx.xxx.xxx ip6:xxxx:x:xxx:xxxx:xxx:xxxx:xxxx:xxx -all
Best practices for web applications often call for the use of a CDN. Those of you that have worked with YSlow! are likely very accustomed to seeing warnings for this reason. I’ve found that CloudFlare is very easy to setup, and for basic services costs absolutely nothing. In addition to the obvious performance advantages of using a CDN to offload much of your network traffic, it also has the advantage of improved security.
CDN’s work by caching a copy of your static content at several locations around the world, making it closer and faster for your users.
Implementation takes only minutes as it requires that you:
- create a (free) account,
- retrieve your existing DNS values from your current provider,
- determine direct vs. CDN “cloud” routing for each subdomain,
- change your DNS records to point to the CloudFlare DNS servers
Some additional advantages I’ve seen since implementing:
- Site remains available in limited capability to users during server outages or upgrades.
- Simplified network configuration as all requests can be sent outside of the LAN for users local to the servers
- IPv6 dual-stack support