1 15.895697 2600:480e:4000:c00::3 -> 2001:470:1f12:425::2 DNS 94
Standard query 0x896c A wwW.ruWeNZORI.net
2 15.901855 2600:480e:4000:c00::7 -> 2001:470:1f12:425::2 DNS 94
Standard query 0xe3e6 A Www.RuWEnzoRi.neT
3 16.557423 2600:480e:4000:c00::7 -> 2001:470:1f12:425::2 DNS 93
Standard query 0x5040 A KiVu.grabEuH.COm
4 16.566121 2600:480e:4000:c00::3 -> 2001:470:1f12:425::2 DNS 93
Standard query 0x9c91 A KIVU.grabeUH.cOM
5 17.211708 2600:480e:4000:c00::9 -> 2001:470:1f12:425::2 DNS 94
Standard query 0x7b36 AAAA www.RUWENzORi.net
6 17.888244 2600:480e:4000:c00::9 -> 2001:470:1f12:425::2 DNS 93
Standard query 0xc582 AAAA KiVu.gRabEUH.com
7 18.041786 2600:480e:4000:c00::7 -> 2001:470:1f12:425::2 DNS 93
Standard query 0xcb72 AAAA Kivu.GRABEUh.coM
Well… WTF ? Who let the script kiddies out ? No one… Surprisingly: those are actually perfectly well-formed queries, using “0x20 Bit encoding“.
This technique was introduced in a 2008 paper, “Increased DNS Forgery Resistance Through 0x20-Bit Encoding – SecURItY viA LeET QueRieS” :
“We describe a novel, practical and simple technique to make DNS queries more resistant to poisoning attacks: mix the upper and lower case spelling of the domain name in the query. Fortuitously, almost all DNS authority servers preserve the mixed case encoding of the query in answer messages. Attackers hoping to poison a DNS cache must therefore guess the mixed-case encoding of the query, in addition to all other fields required in a DNS poisoning attack. This increases the difficulty of the attack”.
For example, Tor uses it by default for name lookups that a Tor server does on behalf of its clients.
Of course, this clever exploitation of a fortuitous behaviour did not go without inducing bugs… What a surprise !
Well… One less mystery.
Upon reboot after upgrading yet another Debian host to sweet Jessie, I was dismayed to lose connectivity – a slight annoyance when administering through the Internet. Later, with screen & keyboard attached to the server, I found that the Intel Ethernet interface using the e1000e module had not come up on boot… A simple ‘ip link set eth0 up’ fixed that… Until the next reboot.
/etc/network/interfaces was still the same as before upgrade, complete with the necessary ‘auto eth0’ line present before the ‘iface eth0 inet static’ line. And everything was fine once the interface had been set up manually.
Looking at dmesg yielded an unusual “[ 1.818847] e1000e 0000:00:19.0 eth0: Unsupported MTU setting” – strange, considering I had been using a 9000 bits MTU without issue before… That error message let me to the cause of my problem: the driver maintainer chose that from kernel 3.15 onwards, calculation of the Ethernet frame’s length always takes into account the VLAN header, even when none is present… And I was running Linux 3.16:
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index d50c91e..165f7bc 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5687,7 +5687,7 @@ struct rtnl_link_stats64 *e1000e_get_stats64(struct net_device *netdev,
static int e1000_change_mtu(struct net_device *netdev, int new_mtu)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
- int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
+ int max_frame = new_mtu + VLAN_HLEN + ETH_HLEN + ETH_FCS_LEN;
/* Jumbo frame support */
if ((max_frame > ETH_FRAME_LEN + ETH_FCS_LEN) &&
As the author remarked: “The hardware has a set limit on supported maximum frame size (9018), and with the addition of the VLAN_HLEN (4) in calculating the header size (now it is 22) , the max configurable MTU is now 8996”.
So there…
diff --git a/network/interfaces b/network/interfaces
index ee4e27d..a094569 100644
--- a/network/interfaces
+++ b/network/interfaces
@@ -7,7 +7,7 @@ iface lo inet loopback
auto eth0
iface eth0 inet static
- mtu 9000
+ mtu 8996
address 10.128.0.2
network 10.128.0.0
netmask 255.255.255.0
And a reboot later the host is still connected – problem solved. Now to avoid fragmentation I’ll have to set a few other hosts’ MTU to 8996 too… Damn.