From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Sun, 18 Apr 2010 20:31:19 -0400
To: 9fans@9fans.net
Message-ID: <f2c8825311e53e096979d1824a06cb3b@kw.quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] continued dns problems
Topicbox-Message-UUID: 07e9f288-ead6-11e9-9d60-3106f5b1d025

disclaimer: dns works great at 2 of the 3 plan 9 sites i maintain.
unfortunately, one squeeky mouse gets the exterminator fired.

dns under heavy use is continuing to be problematic.  before
the recent locking changes, i was seeing several crashes a month.
after the locking changes, i am seeing many bad rrs that appear
to cause lookups to fail.  the changes all looked good to me, so
i'm uncertain what's going on.  regardless, there were 6-7 *reported*
lookup failures on friday.  i don't know if the crashes were masking
the old problem. google.com, for example,  tends to get a number
of wierd rrs. pages don't load.

bowing to pressure over failed lookups, i'm trying a downgrade to
the server as of 20100305.  i'm hoping i can more easily detect a
broken server than one with bad rrs.

sorry for the crappy bug report.  there has been zero time in the
schedule to debug this problem.  (and people don't generally
even report a problem.)  i'm also sorry that there's no code, but
it's not clear to me that change is welcome.

despite russ' objections, i still think ndb/dns needs a restructuring.
if the rr db were a single thread that communicated with the
query threads via channels, it would be much easier to debug.

after at least 10 years of the current setup, we've proven that
the current structure is at a minimum hard to debug.

- erik