Dear UPS

Disks in two of our servers failed last week. One was covered by warranty, the other by a HP Care Pack (Next Business Day). In both cases, I reported the failure last Friday and replacement disks were promptly dispatched by the distributor and HP, respectively.

As of Wednesday evening, they have not arrived.

Yes, we’re in the last frenzy of the Christmas shopping rush, but what UPS is reporting on their tracking webpage is simply an outrage.

On monday morning, their tracking page reported the packet as

VIENNA, AT 	21.12.2009  	8:10  	IMPORTSCAN 

and “on track to delivery today”.

No delivery attempt was made on Monday.

Tuesday’s action reads

VIENNA, AT  	22/12/2009  	17:56  	THE RECEIVER IS ON A HOLIDAY. 

I was not on vacation. Co-workers were in the office until 18:30. No delivery attempts were noticed.

Wednesday’s UPS log shows:

VIENNA, AT  	23/12/2009  	17:08  	THE RECEIVER IS ON VACATION. 
	23/12/2009 	5:19 	OUT FOR DELIVERY
	23/12/2009 	2:00 	IMPORT SCAN  

Today I was on vacation, but dropped by at the office around 17:00 and there were three collegues present. No UPS delivery guy, though.

So, this looks like someone is simply making things up to cover up that they could not keep their SLA.

A disgrace.

At this point I have to add that our local Federal Post office has improved their customer service noticeably. Whereas I used to leave the Treustraße office angered by their slowness, the last three times they were actually helpful and tried to avoid unnecessary waiting times.


After a complaint by phone to UPS the disks finally made it to our office on December 30th.

The only working day where the office really wasn’t manned was December 24th. The rest of the entries were simply pulled out of the a** of an overloaded delivery guy.

A blast from the past: mod_epp

I recently got contacted by SIDN regarding some problems with mod_epp. They were running into issues when combining mod_epp with mod_proxy and needed me to find a fix. We came to an agreement, I spend some time programming C again, and here it is: mod_epp version 1.6.


* Bugfix: Internal EPP error messages work again
* Default value for EPPAuthURI
* New config statement: EPPReturncodeHeader
- Backend can signal EPP RC to mod_epp
* New feature: implicit login
- EPPAuthURI = implicit
- no special request to authenticate
- uses either HTTP error code or via EPPReturncodeHeader
of the command.
* New feature: User-Agent: header set
* Bufix/Feature: Connection close now works on mod_proxy
- X-Connection
- via EPP return code

* A mod_proxy setup is now fully supported. See README.

Get it here.


This one started with a basic circle and grew from that. Worked out better than expected in the end. These days, once I build such a track, both kids play with trains on it. I had to repair the bridge a few times, but it’s getting a lot better now.

Google DNS resolution service

In their endless quest for world domination Google recently unveiled their public DNS resolver setup. Such a service is nothing new per se, OpenDNS is doing something similar for some time. Based on the FAQ, Google seems to do this right: A sensible privacy policy and no NXDOMAIN rewriting. They even seem to implement some state-of-the-art (except DNSSEC) tricks to harden their system against forgery attempts.

(Quick aside: one of their tricks to speed up the resolution is to pre-fetch records due to expire from the cache. I’ve proposed exactly the same to the BIND folks at the DNS-OARC meeting in Chicago, 2007.)

On one mailing list, the question was raised how widespread use of Google DNS would affect the Content Distribution Networks (CDNs) like Akamai. After all, they take the source IP of the DNS query as “close to the client, network-wise” and return the best CDN node for that IP address. If now an Austrian User ask the Google DNS servers in the US, then the CDN’s nameserver will return the address of an American CDN node leading to a suboptimal choice.

That effect might become less pronounced (but does not go away) once Google deploys their DNS service in a massive anycast infrastructure. Akamai will then see the request coming from at least the same region as where the end-user is.

Actually, the best move Akamai could do is start a rival DNS resolving infrastructure. If they use anycasted recursors at each of their CDN nodes, that would really simplify their CDN algorithm as the node that gets the DNS request is very likely to be the optimal one for the actual content delivery, too.