Wandering Thoughts archives

2006-08-22

How not to set up your DNS (part 11)

Presented in the traditional illustrated form:

; dig +short ns hinet.net.tw.
reg.hinet.net.tw.
www.hinet.net.tw.
hinet.net.tw.

This looks good, except for the fact that they all have the same IP address, 210.65.1.231. You would think that a large Taiwanese ISP would be able to afford more than one DNS server, but perhaps they're too busy beefing up their network infrastructure to cope with the amount of spam their customers send. (At the moment Hinet is #4 on Spamhaus.org's list of the 10 worst spam service ISPs, with 53 listings.)

But it gets worse.

; dig +short a ms4.hinet.net.tw @210.65.1.231
210.65.1.231

(Okay, perhaps they only have one IP for all their servers.)

; dig mx ms4.hinet.net.tw @210.65.1.231
[...]
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18296
[...]

The correct way for a DNS server to answer a query that it doesn't have any data for is with a response that contains no data. SERVFAIL causes other people to retry, instead of just going away. In this case it caused us to not accept email from an alleged 'wbjtewyeox@ms4.hinet.net.tw', because every attempt to look up the MX record for ms4.hinet.net.tw looked like a temporary failure to us.

sysadmin/HowNotToDoDNSXI written at 17:04:06; Add Comment

Link: Csh Programming Considered Harmful

Tom Christiansen's Csh Programming Considered Harmful used to be posted to various Usenet comp.unix groups, nigh on ten years ago or so. I consider it sort of a pity that it isn't still being posted, because every so often someone still decides that writing shell scripts in csh would be a good idea.

Some of the problems Christiansen identified have since been fixed by modern versions of tcsh, but not all of them.

(The article can also serve as an interesting catalog of sh programming tricks.)

links/CshWhynot written at 16:35:26; Add Comment

fork(), wait(), and threads

Something I've discovered through (painful) experience is that threaded programs cannot portably fork() in one thread and then wait() for the forked process in another one.

This will work in some environments but fail explosively in others; the one I stubbed my toe on was a Linux 2.4 kernel based system (without NPTL, which is the usual state of affairs for 2.4-based Linux distributions).

Admittedly, mixing threads and fork() is a bit perverse, but sometimes it's what you need to do.

(I saw this in a Python program, but Python isn't doing anything special in the POSIX threads department so I have to expect that it's completely generic.)

programming/ThreadsAndFork written at 13:08:41; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.