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, 18.104.22.168. 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 @22.214.171.124 126.96.36.199
(Okay, perhaps they only have one IP for all their servers.)
; dig mx ms4.hinet.net.tw @188.8.131.52
;; ->>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
'firstname.lastname@example.org', because every attempt to look up the
record for ms4.hinet.net.tw looked like a temporary failure to us.
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
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
wait(), and threads
Something I've discovered through (painful) experience is that threaded
programs cannot portably
fork() in one thread and then
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.)