Don’t be a .local yokel

Wikipedia has a nice technical write up that explains why you should never, ever use the .local suffix the way Microsoft has frequently recommended.

But I like this politically incorrect version better:

Microsoft: “Gee, nobody is using the .local piece of the globally shared Internet namespace, so let’s tell all our customers that it’s best practice to use it for our totally super cool version of Kerberized LDAP service called Active Directory!”

Novell: “Oh noes, Microsoft has made an inferior competitor to our flagship technology! It’ll probably destroy our market advantage just like their inferior networking stack did!”

Linux/Unix: “Oh noes, when somebody attaches the new Microsoft technology to an existing mature standards-based network, Kerberos breaks!”

Microsoft: “HA HA HA HA HA HA HA we are totally following the standard, lusers!”

Linux/Unix: “grumble whine we will patch Kerberos even though we don’t agree.”

Microsoft: “whatevs. Did you notice we broke your DNS too? :)”

Apple: “Hey, IETF, we have this cool new zeroconf technology. We want to reserve the .local namespace for it.”

IETF: “OK, sure, you’ve filled out all the forms and attended all the meetings and there’s two independent implementations so you’ve done everything correctly. We have no valid reason to deny this allocation.”

Novell: “Hey, we were using SLP already, what did you just do?”

Apple: “Oh, whoopsie, did we just eat your lunch? HA HA HA HA HA”

Microsoft: “Hey, what just happened?”

Apple: “HA HA HA HA HA HA HA HA HA HA HA RFC6762, lusers!”

Linux/Unix: “grumble mumble whatevs. We can do mDNS.”

Microsoft customers: “OH NOES WE ARE SCREWZ0RRED”

Microsoft: “Meh, you didn’t really want Apple products on your networks anyway.”


Microsoft customers: “How much would it cost to fix this network?”

Microsoft: “What, were you talking to us? Everything’s fine here. Windows 10 forever!”

Comcast DNS highly unreliable

Today we finally solved our email mystery. The reason some people could not get their email from their homes was that they were using Comcast as a service provider.

Querying Comcast’s DNS servers at and, we discovered that our domain won’t resolve there at all, and even with the domains that do resolve properly there’s between 20% and 50% packet losses. Comcast’s DNS is broken.

A little googling around shows that these problems have been continuously reported by Comcast customers since at least 2006, and Comcast has never fixed it. This has been broken for so long that linux-based home router systems like DD-WRT actually support several workarounds!

We’re a Comcast Business Internet customer, and the people failing to communicate with our site are Comcast Home Internet customers (typically “Triple play” buyers) so this is a case where they are actually failing to provide a critically important customer service to both sides of their business. Our users who have Verizon FIOS are working fine, despite Verizon’s long standing practice of unethical DNS hijacking.

A moment of extreme computer geekery

Almost certainly of no interest to anyone.. well, maybe DNS experts who have occasional need of perl. Net::DNS::RR::CNAME->set_rrsort_func is pretty incredibly obscure, though.

#!/usr/bin/perl -w -T -W
#  DNS zone transfer and output CNAMEs sorted by target host
#  Charlie Brooks 2014-01-08

use Net::DNS;
use Net::DNS qw(rrsort);  # why don't I get this automatically?

my @domains=qw/;

# Use system defaults from resolv.conf to find nameservers
my $res  = Net::DNS::Resolver->new;

foreach my $namespace (@domains) {

# do a zone transfer, loading resource records into array
# axfr is standard (BIND style) not djbdns style
  my @zone = $res->axfr($namespace);

# Red Hat's perl-Net-DNS-0.59-3.el5 package doesn't seem
# to have a useable rrsort for CNAMES (it tries to do a
# "<=>" flying saucer instead of "cmp") and the examples
# in the doco for custom sort methods flat out don't work
# but I flailed around until I found a way to do it.  It's
# weirdly simple if you stumble upon the magic incantation.

# dumping the CNAMEs sorted by target requires custom sort function
  Net::DNS::RR::CNAME->set_rrsort_func ('cnamet',
             sub {($a,$b)=($Net::DNS::a,$Net::DNS::b);
                  $a->{'cname'} cmp $b->{'cname'}});

  foreach my $cname (rrsort("CNAME","cnamet",@zone)) {