9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: [9fans] small dns improvements
Date: Mon, 16 Jan 2012 12:13:59 -0500	[thread overview]
Message-ID: <81ab20f06c1b8b20cf869565b01e2e29@chula.quanstro.net> (raw)

it must be that time of year.  dns is driving folks bats.  :-)

i've been spending some time looking at why ndb/dns fails.  as is well known,
there are very long-standing locking problems.  in the past, i've gotten hung up on
those and not made any progress.  while imho, the long-term strategy should be
to replace ndb/dns with an easier-to-maintain structure, i only have a few weeks
to fix as much as possible.  so i decided to see if there were simple things we could
do to improve things.

geoff has made a few big improvements.  some sites which were broken for a long
time are now working.  tomshardware.com is one that i've used as a test, and it
finally works.  (although the results don't seem worth the effort.  ☺)

but there are a number of other lookups that are still broken for me, and it
there seem to be some straightforward reasons that i think i've fixed:

1.  we're sending the RD (recursion desired) bit when we ourselves are acting as
a recursive server.  this looks okay by the standard, but many servers return Srvfail
(code 2, Rserver in the dns code) rather than ignoring this bit.  turning this off
helps alot (example: ocsp.netsolssl.com).

2.  we're ignoring status codes that we should be treating as fatal (like Srvfail)

3.  we're not using edns0.  this is kind of a sticky bit.  some servers insist on sending
enormous answers but don't answer via tcp.  on the other hand, some servers insist
on sending enormous answers, but return nasty errors when given edns0 queries.
what seems to work best is to send udp/no edns0, udp/edns0 and finally tcp.

4.  we get confused attaching the name servers to an answer for an out-of-baliwick
cname record.  (this is largely a problem with logging, but has the potential to
corrupt the database.)

if anyone would like to try a 386 executable (amd64 available on request),
i've put a copy at
	http://ftp.quanstro.net/other/^(dns dnsdebug)

i'd be happy to hear of any dns lookup problems.  please let me know
which version of dns you're using.

thanks,

- erik



             reply	other threads:[~2012-01-16 17:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-16 17:13 erik quanstrom [this message]
2012-01-16 18:02 ` Charles Forsyth
     [not found] ` <CAOw7k5gmafeG9upUmjKhgB=9kyoyO0+sUJ_eySu3URfXw=6Wdg@mail.gmail.c>
2012-01-16 18:05   ` erik quanstrom
2012-01-16 18:13     ` Charles Forsyth
     [not found]     ` <CAOw7k5g6j4VcZct4LpxN=SRiUjhU1aFVo8nOtDAm_Dmi0c7KkQ@mail.gmail.c>
2012-01-16 18:19       ` erik quanstrom
2012-01-16 18:07   ` erik quanstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=81ab20f06c1b8b20cf869565b01e2e29@chula.quanstro.net \
    --to=quanstro@quanstro.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).