How to bugger up your site and keep it that way

October 6th, 2009 | Categories: DNS, DomiNotes | Tags:

The launch started about two hours ago, and a little later Volker asks around whether anybody can resolve the domain name. I dig and point out that it can't work.

Two hours later, they've still got it hosed.

And there's more than one of us who've seen the problem. I tried a hint, but it is a long way from marketing to the boffins. ;-)

(A free bit of advice: the ttl is so low you could have fixed it ages ago.)

Read more at whocares.

Update

Now, I'm rolling on the floor and laughing my ass off:

; <<>> DiG 9.2.4 <<>> developer.lotus.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8342
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;developer.lotus.com.           IN      A

;; ANSWER SECTION:
developer.lotus.com.    300     IN      CNAME   192.147.106.27.
192.147.106.27.         601088  IN      A       192.147.106.27

;; Query time: 227 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Oct  7 09:59:03 2009

I really think it is time those guys get a decent DNS admin, or at the very least, ready my book Alternative DNS Servers.

Update2

(Maybe I should read my book as well.) The reason for the A RR above is that my query went via a dnscache, which (thankfully) resolves a query for an A record of an IP address to precisely that IP address. I've verified with your typical resolver, and the original incorrect CNAME RR still makes resolution of the domain impossible.

Update3 October 7th, 08:35 CET.

Somebody at IBM seems to be "working" at this issue "heavily". They've changed the TTL from 300 to … drum roll …

dig @cmtu.mt.ns.els-gms.att.net. developer.lotus.com.

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48833
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; ANSWER SECTION:
developer.lotus.com.    0       IN      CNAME   192.147.106.27.
Leave a comment | Trackback
  1. Chris Linfoot
    October 7th, 2009 at 13:08
    Reply | Quote | #1

    Did you try hacking your local resolver to work around the issue by simulating the correct A record response to the query?

    If you do, the result at http://developer.lotus.com is just a 302 (yes, a 302) redirect to http://www.ibm.com/developerworks/lotus

  2. Jan-Piet Mens
    October 7th, 2009 at 13:19
    Reply | Quote | #2

    No I didn't — dnscache (used in the example above) does that for me.

    (I'm aware of the 302, thanks — and I couldn't really care less ;-) but I'll put it here for posterity:

    HTTP/1.1 302 Found
Server: Lotus-Domino
Date: Wed, 07 Oct 2009 11:16:07 GMT
Connection: close
Location: http://www.ibm.com/developerworks/lotus

    )

    Quite unbelievable how, after almost 20 hours, IBM still hasn't solved the problem — just checked.

  3. Stefan Rubner
    October 8th, 2009 at 23:47
    Reply | Quote | #3

    Meanwhile, they're back at 300 again.

  4. Jan-Piet Mens
    October 9th, 2009 at 12:08
    Reply | Quote | #4

    Nah. They prefer 0.