On Jan 19, 2012, at 11:17 AM, erik quanstrom wrote: > On Thu Jan 19 12:08:37 EST 2012, j...@corpus-callosum.com 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