Re: DNS resolver for NSE

[Diman Todorov <diman.todorov () chello at>]

On 26.06.2007, at 23:09, doug () hcsw org wrote:

> 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.
As far as I remember your DNS resolver does use nsock. Providing  
hooks between your resolver and NSE does pose a challenge but I don't  
see how it would block the whole Nmap process. After all the whole  
point of using nsock is to have parallelized network I/O.

> 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:
I agree that implementing a DNS resolver in Lua is not very bright  
idea. Especially since there already is some code base for that in  
Nmap already. I am not sure if a DNS resolver is logically a part of  
the NSE library. I would have said it is is core functionality of NSE  
- sort of like the nsock bindings in NSE.

I am definitely looking forward to a nuff version which runs on OSX ;)

> 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.
oh contrair. The garbage collection in Lua is quite flexible. In fact  
stoiko extended it to collect and close open but unneeded nsockets. I  
am not familiar with weak hash tables but are they something like  
this http://lua-users.org/wiki/WeakTablesTutorial ? And what exactly  
do you mean by a 'real format function' anyway?

Speaking of Lua macros, I thought about adding at least a simple  
macro system to NSE but I decided against it. One of the reasons was  
that there was a community effort to add a sort of token filter based  
preprocessor to Lua. At the time when I wrote NSE it was in a very  
experimental stage besides not being very powerful so I ended up  
keeping it far far away from NSE. I definitely think some kind of  
syntax extension mechanism for NSE is a good idea. It would for  
example allow us to define a sane syntax for the bitlib. A first step  
would be to check if said token filter has reached any reasonable  
level of maturity.

> 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.
I second that.

cheers,
Diman






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