So I’ve been informed that there are some bizarre problems resolving a website that has recently changed providers from digiweb to novara (wasn’t my idea). From elsewhere the new site appears reliably, but from inside our network we are getting the following results:
andgal@nbgal185:~$ host -t any peracton.com
peracton.com has SOA record ns1.novara.ie. hostmaster.host.ie. 2011080416 10800 3600 604800 14400
peracton.com name server ns1.novara.ie.
peracton.com name server ns2.novara.ie.
peracton.com name server ns3.nameserver.ie.
peracton.com mail is handled by 10 smail3.host.ie.
peracton.com has address 126.96.36.199
andgal@nbgal185:~$ host peracton.com
peracton.com has address 188.8.131.52
peracton.com mail is handled by 10 mail2.hosting.digiweb.ie.
The first set of results is the “correct” one, so why is host (and nslookup, and dig, and firefox…) still going to the old address by default? I suspect it is something to do with cache locking on our Server 2008 DNS forwarder. It seems that even after I have forced a fresh request by using “-t any”, the stale cached A record is being returned for normal searches. This is apparently a security measure to protect against cache poisoning. It would appear that the TTL on the old A record was unusually long, which means that I had to flush the cache on the primary DNS forwarder (the backup DNS forwarder is fine, presumably because the old record was never in its cache).
Sure enough, running “dnscmd /clearcache” on the offending server fixed the problem.
I had to do a little searching on the internet to work out how to do this, so here it is in a single post.
DNAME records are supported in Server 2008’s DNS service, but you cannot add them (or edit them) in the graphical tool. You need to use the command line. Right-click “Command Prompt” and run as administrator. Then you can type in the following:
DNSCMD /RECORDADD myzone.example.com mynewrecord DNAME myoldrecord.example.com
If you now refresh the graphical DNS tool you will see a new record with a blank type and contents “Unknown – view properties for more info”. If you do this, you will see the raw hex data for the DNAME RR (type 0x27). The only thing you can do with it in the graphical tool is delete it.
Came across this gem today on a machine that had recently been upgraded to Server 2008:
Error: System error: -2146697191
Turns out that a custom VBScript was sending a form to one of our secure web servers and the certificate chain couldn’t be verified up to the root (even though we bought it from a reputable source). Adding the offending root certificate to the trusted root certificate authorities database fixed the problem.
This does not seem to be documented anywhere on the internet yet, so here it is.
In my current job, Microsoft Sharepoint rules. The decision was made long before my time to employ it as the common document repository, and for most people it works reasonably well. I have to force myself to use it though, and I can distil the reasons down to one root cause: ActiveX controls.
In its vanilla, static-page form, Sharepoint is barely functional. It takes a minimum of four clicks (open, edit, modify, save) to change a radio-button option. Checking files in and out is a pain – it’s easier to just overwrite. And I’ve never managed to attach a file to a list entry. To make it really useable, you need to run IE.
Oh wait, you’re using a Mac. Well you can just piss off then.
The problem is not confined to Sharepoint. The motivation for this post was finding that Microsoft’s certificate management server requires scripting to be turned on (it doesn’t say what sort of scripting, but it isn’t JS) in order to process a simple form that could have been written in 1995. In this case there was no option but to boot up the VM and use IE.
So what to do? Struggle manfully with Sharepoint’s prehistoric static interface or retreat into the VM, cut off from my usual editing suite – Office X for Mac. Somebody somewhere is no doubt enjoying this juicy irony. But it’s not me.