Re: DNS resolver for NSE

[doug () hcsw org]

Hi Buanzo!

On Tue, Jun 26, 2007 at 09:10:54AM -0300 or thereabouts, Arturo 'Buanzo' Busleiman wrote:
> I was planning on writing an NSE scripts that requests information from DNS servers. Namely, a DNSBL
> checker. I asked Diman if we had resolver functions available from within NSE, but he said "no", so
> as I don't think I can hack that into NSE (not much time, damn, I'd love to contribute that!), then
> I'd thought of throwing the idea in here.

That IS an interesting idea! One possibility is to use the system's
DNS resolver but of course that would BLOCK the whole Nmap process
and stop other NSE scripts from running in parallel.

The other way, as you suggest in your post, would be to implement
a general asynchronous resolver in the standard NSE library or
maybe in nsock itself. Nmap already includes some DNS code in
nmap_dns.cc but it is very specialised for bulk processing of
reverse DNS records. We need something general AND asynchronous
for NSE.

But this means implementing a complete DNS resolver in Lua! Handling
all of DNS is actually a lot harder of a task than it sounds and
would be a major undertaking. I like to think I'm not speaking out
of ignorance here, having implemented DNS resolvers a number of times.
For my program, Nuff, I created a highly sophisticated DNS resolver:

http://hcsw.org:7467/viewcvs/nuff/ffun/dns.scm?rev=1.23&view=auto

It's a %100 asynchronous, forward/reverse, IPv4/IPv6, predictive
resolver that, in a few ways, is smarter than any other resolver I
am aware of. For instance, if one continuation (like a Lua co-routine)
requests a record that already has an outstanding request, no new requests
will be issued - once the first packet comes in, both continuations
will receive a copy of the results (and these copies actually share
memory for efficiency's sake!).

Nuff's dns resolver also implements a technique called DNS PREDICTION
that I invented which gives a substantial performance boost over BIND
in many common cases. Nuff's cache is also MORE SECURE than other
resolvers. It makes "cache peeking" a lot more difficult because you
need to exploit TIMING DIFFERENCES to do it. See my paper here:

http://www.hcsw.org/nuff/papers/dnsd/

As an experiment I once implemented the same program (a board game
AI) first in Lisp and then in Java. I used essentially the same
algorithms and data structures in both programs. The Java one
was about 10 times longer and more complicated than the Lisp one.
This is because I was able to leverage MACROS in Lisp but not in Java.

Based on the fact that I used macros VERY heavily in the nuff resolver
(it's probably 1/4 macros and 3/4 code), and considering of course that
LUA IS NOT JAVA, I would estimate that Lua code implementing 1/2 of nuff's
resolver functionality would be at least 5 times longer than the nuff dns.scm
link I pasted above. Even then, Nuff's scheme system has a lot more features
than NSE, like configurable+gc-weak hash tables and a real format function.

As a quick example, in Lua the following form would translate to at least
2 loops, several local variables, a mess of accessors, and lots of string
concatenation:

(format #f "~{~a~^.~}" (parse-dns-records-add-name))

But with that in mind, implementing DNS in NSE certainly is possible,
and I could provide detailed advice and comments to anyone who would like to
attempt it.

Me? Sorry, I'm sick of writing resolvers. :)

Best,

Doug

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org