Oosat really is a bit broken

[winston]

There is some network borkiness about capnhack.com.

From the Isle of Man:

Code: Select all

$ dig -t NS capnhack.com

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

;; QUESTION SECTION:
;capnhack.com.                  IN      NS

;; ANSWER SECTION:
capnhack.com.           21477   IN      NS      ns2.powweb.com.
capnhack.com.           21477   IN      NS      ns3.powweb.com.

;; Query time: 18 msec
;; SERVER: 172.16.1.11#53(172.16.1.11)
;; WHEN: Wed Mar  1 10:19:42 2006
;; MSG SIZE  rcvd: 73

As you can see, DNS is working fine. Or at least my cached copy of it with 21477 seconds left to live is working fine.

However, from Dallas, Texas:

Code: Select all

$  dig -t NS capnhack.com

; <<>> DiG 9.2.4 <<>> -t NS capnhack.com
;; global options:  printcmd
;; connection timed out; no servers could be reached

For some reason I can't actually reach their DNS servers. It's nothing to do with the Great Firewall of China, something is causing capnhack.com to not be resolvable from the entire Internet.

If I put in the IP address of www.capnhack.com, it is pingable from home but not from Dallas.

It's not geography specific either, I can reach www.capnhack.com from the Deathrow VMS cluster in Florida, so it's probably some network routing problem that is being left to fester.

Whoever is in charge of Oosat ought to contact the Power Web support people. Here is the traceroute from Dallas, Texas:

Code: Select all

[root@poleaxed root]# traceroute 66.152.98.205
traceroute to 66.152.98.205 (66.152.98.205), 30 hops max, 38 byte packets
 1  129.70-85-70.reverse.theplanet.com (70.85.70.129)  1.125 ms  0.370 ms  0.351 ms
 2  vl2.dsr01.dllstx2.theplanet.com (12.96.160.41)  0.511 ms  0.392 ms  0.456 ms 3  vl21.dsr01.dllstx3.theplanet.com (70.85.127.65)  0.778 ms  0.734 ms  0.714 ms
 4  70.85.127.5 (70.85.127.5)  0.637 ms  1.333 ms  5.784 ms
 5  * * *

[Murgh]

how strange.
I'll mail the Cap'n I guess..

[xaotik]

Good catch.
Also, note the serial number of the powweb.com NSs in their original entry - and their refresh and retry values. The serial doesn't conform with RFC format and the refresh/retry values are very low imo. 900 secs and 60 secs... that's kinda overkill unless they're migrating their network.

Code: Select all

dig powweb.com SOA

; <<>> DiG 8.3 <<>> powweb.com SOA 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49368
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;;      powweb.com, type = SOA, class = IN

;; ANSWER SECTION:
powweb.com.             0S IN SOA       ns3.powweb.com. hostmaster.powweb.com. (
                                        1137033259      ; serial
                                        15M             ; refresh
                                        1M              ; retry
                                        1W              ; expiry
                                        1H )            ; minimum

RFC nonconformance might have it rejected by stricter DNSs. Not that this is the source of their network problems, just something extra...

[winston]

The serial looks an awful look like seconds since the epoch - I thought that was in vogue these days (certainy for the .com/.net zones) - dig -t SOA for 'com' shows 1141222096 as the serial. If that's not RFC compliant, well, then the entire com/net zone is not RFC compliant either and someone who ignores non-compliant serials is not going to see much of the internet

(Personally, I use the good 'ol fashioned ISO date format and two digits for my serial numbers, just like the 'org' TLD zone uses).

[xaotik]

Right you are, after a search I found that RFC1912 which is just an informative memo states a YYYYMMDDnn format is a recommendation - so it's not a violation of any sort of standard.

[Cyberian Tiger]

zone serial makes no difference and then it only matters when you have secondary NS servers doing ixfr.

And the only requirement is that you must increment it when the zone file changes.

[capnhack]

are people still having this problem?

the site went a bit awry over the past 2 weeks and the stupid hosts were 'aware of the problem, and working on it'. thanks for being so informative, eh? anyway, should be working fine now. if its still behaving badly then please reply here with which country youre in, which isp you use, etc, so i can ask powweb about it (or you can ask them directly, www.powweb.com).

[winston]

Seems to be working from Dallas now.