fix & improvements for dns

[GoogleCodeExporter]

changes in this diff, the first is most important:

- unbreak reverse lookups in ifip6*.  so_gethostbyaddr was using
getaddrinfo.  apparently i had thought AI_NUMERICHOST did a reverse lookup,
but it doesn't.  getnameinfo does reverse lookups.  i tested this
on debian squeeze/386 (it works).  the windows changes have not
been tested (or even compiled), because i don't have a windows >= vista
machine at the moment.

- ndb/dnsquery knows about .ip6.arpa addresses (reverse ipv6 
addresses).

- srv(2) has a new function "iph2aaaa" (ugly name, but iph2a6 would 
be misleading with a6 dns records) which returns ipv6 addresses for
a host name.  iph2a only returns ipv4 addresses now.  ndb/dns uses
iph2a to specifically resolve dns A requests, so returning ipv6 
addresses does not seem right.

- ndb/dns can request AAAA records, keyword "ipv6".  "ip" stays 
ipv4-only.  ndb/dns cannot yet talk to dns servers over ipv6.

- ndb/dns uses random request id's, not incremental id's.  should
make it a bit harder to forge responses.  there is still room for
improvement (ndb/dns sends the same requests with the same id to
multiple dns servers on timeouts).

- ndb/dns does not crash on an "all" query anymore.  it used to 
crash on dereferencing a nil "soa" in partrrl (t.rtype from t := hd rrl)
from the following expression:

        cachec <-= (ref RR.Error(label, attr, Cin, ttl, auth, "resource does not exist")::soa::nil, auth);

- now ndb/dns does not perform a query anymore for an "all" request,
this makes it consistent with the documentation:  it just returns 
local data.  it makes more sense to me to do an "all" dns request,
but that requires a bit more effort (and knowledge about the dns
protocol).

- ndb/cs tries an "ipv6" lookup after an "ip" (v4) failed (both 
through "dns" file and through srv)

- update root servers in lib/ndb/dns, 
http://www.internic.net/zones/named.root

i am also wondering whether ndb/dns uses attrdb properly.  multiple request 
threads can run concurrently, and each can use "dnsdb".  the underlying Dbf's 
are automatically locked when accessed, but dnsdb can be reopened in one thread 
while Dbptr's are held and later used again, that seems suspect.  i once saw a 
dns thread that was spinning.  a backtrace (i only took 1) showed it busy in 
bufio (readchunk) on Dbf.readentry.  but i can't see how that would happen...

i also found a suspect fd.offset() call outside the lock, in appl/lib/attrdb.b.

Original issue reported on code.google.com by mechiel@ueber.net on 2 Mar 2011 at 7:27

Attachments:

• dns.diff
• attrdb.b.diff

[GoogleCodeExporter]

Original comment by Charles....@gmail.com on 8 Mar 2011 at 9:11

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by Charles....@gmail.com on 8 Mar 2011 at 9:12

• Added labels: Type-Contribution