tlug: External DNS woes

["Stephen J. Turnbull" <turnbull@example.com>]

Not really a Linux question, but the biggest concentration of net
admins/security geeks I know is on TLUG.  And it is making use of my
Linux box difficult in mail applications.

I'm having trouble with mail being intermittently refused from various
sites because "Sender domain must exist."  I believe these are all
recent sendmail implementations (8.9 or 8.10).  (What does sendmail
use to make that check, gethostbyaddress()?  Surely not auth.)  It has
happened with Japanese sites (in particular, TLUG), New Zealand
(vuw.ac.jp), and US (best.com and lucent.com).  The domain in question
is my Linux box turnbull.sk.tsukuba.ac.jp.  Its SOA is
shako.sk.tsukuba.ac.jp.

I've tried querying the remote nameservers for those domains with dig,
and in general it seems that once the cached negative expires things
work OK (both DNS and SMTP).  Right now all of the above sites are
apparently fine, except that one of the nameservers for vuw.ac.jp
(ns1.waikato.ac.nz) can't find the ac.jp domain!  (It just returns
information for the jp domain's name servers and a null ANSWER field.
Maybe it's set not to do recursive queries or something?)

However, my mail is still being rejected at vuw.ac.nz, while the main
departmental server got through.  It turns out there are "internal"
nameservers which reject my DNS queries (and one of which is the MX
used by the ML I'm trying to post to).  So I suspect that the internal
nameserver cached the failed lookup result, but have no way to check it.

The problems started on April 27 or 28, when my domain got
accidentally deleted from the local DNS.  That was fixed at about 6pm
on the 28th, and normal service resumed (so I thought) on the evening
of the 29th, when caches expired.

However, service to all of the sites above has been intermittent since
then, mostly things go through but every once in a while the DNS seems
to fail again, starting on May 1.  It's really annoying, since it
means I can't send mail to those sites until the cache expires,
usually in 24 hours.  I have never managed to get a Tsukuba-dai server
to deny that I exist since April 29, so I suspect some external
problem, probably the Tsukuba-dai packet-filter.

Coincidentally (?) on May 1 Tsukuba-dai started a packet-filter, but
it does let udp/dns and tcp/auth queries through.  Strangely enough,
incoming tcp/dns is (according to the docs) blocked, as is all
incoming ICMP and all incoming UDP except to the DNS port (which means
I have to use TCP queries to remote nameservers).  (If you have
detailed well-informed comments about how stupid this all is, please
do send them; I'll take your name off and forward them to the relevant
committee.)  Further details available if you think it's related and
would help diagnose.

Anybody have any idea what might be going on?  Unfortunately, the
local techs are not particularly clued in to the relevant RFCs, so
they're not much help.  And, no, they won't give me root so I can play
with the DNS myself.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
--------------------------------------------------------------------
Next Technical Meeting: May 13 (Sat) 13:30 Temple University Japan
* Topic: Crypto and Security	Speaker: Chris Sekiya
Next Nomikai Meeting: June 16 (Fri), Tengu TokyoEkiMae.
--------------------------------------------------------------------
more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan