On Jan 19, 2012, at 11:17 AM, erik quanstrom wrote:
> On Thu Jan 19 12:08:37 EST 2012, [email protected] wrote:
>> Haven't seen it. But it does seem that a lot of us
>> are having fun with dns this week (and every week).
>>
>> Mine's more the problem of
>>
>> ndb/dns -sx /net.alt -f /lib/ndb/external
>
> you probablly want -R too, so you ignore the RD flag
> on incoming queries.
not necessarily what I want, but I've tried that too.
>
> the key to getting plan 9 resolution working right is
> to have the proper ipnet configuration that has a
> proper netmask s.t. ndb/ipquery $sys dns gives a
> credible answer. e.g.
yep, I get clean sys, ip, etc resolves for nodes in my
/lib/ndb/external file. It's the next hop out that just
doesn't happen. No pointer to the next dns server to
do a lookup, e.g. sources.cs.bell-labs.com.
Turns out Presotto posted a little comment in 9fans years back
about adding root entries into an ndb file would solve it. It
works, now I can replica/pull and 9fs sources til the cows come
home from a cpu server that spans multiple networks.
So as a reminder:
ndb/dns -sx /net.alt -f /lib/ndb/external
will require the external file to have the ROOT-SERVERS.NET ns
entries defined even if you have the following:
database=
file=/lib/ndb/external
file=/lib/ndb/common
^just copy the *ROOT-SERVERS.NET lines from /lib/ndb/common into
the external file. It may just be more practical to copy
local.complicated to external and edit from there. Researching
the lack of the database reference to /lib/ndb/common is left
to the reader.
-jas
