Re: [ncat][RFC] Ability to control hostname resolution for proxy

On Fri, Jan 25, 2019 at 09:57:03AM -0700, nnposter wrote:
> On 1/24/19 12:13 AM, David Fifield wrote:
> > On Tue, Jan 22, 2019 at 02:06:07PM -0700, nnposter wrote:
> > > 
> > > ncat   ...   --proxy-dns local | remote | both | none
> > > 
> > > More at https://github.com/nmap/nmap/pull/1439
> > > Please review the proposal and comment.
> > 
> > curl uses different URL schemes to control whether name resolution is
> > local or remote: https://curl.haxx.se/docs/manpage.html#-x
> > socks4, socks5: local
> > socks4a, socks5h: remote
> > 
> > But personally I've never liked that setup. I almost always want remote
> > resolution and have to remind myself not to use the versions that will
> > leak DNS. And of course it doesn't work for http or https proxies.
> 
> I agree. It is definitely overloading the concept of a protocol.
> 
> Back to my proposal, what would be your vote?
> (1) ignore; do nothing
> (2) proceed with it
> (3) the feature should be somehow supported but not this way

I think I would choose (1), (2), (3) in order of preference. But I don't
know what the desired use case for local resolution is.

About (3), it would in general be nice to have something in Nmap where
you can say, "use this IP address, but pretend it has this DNS name."
For example when running http-* scripts, a name may resolve to 5
addresses, but you are only interested in a specific one of them, but
you still need a DNS name to make virtual hosting work. I think the best
way to fake it in general is to use an /etc/hosts file, which of course
implies local resolution. In the http case, there's the http.host script
arg, but it's global. If there were some mechanism like that for Nmap,
Ncat could use it as well. But obviously that's a big design question
and would take time to develop, which is why I wouldn't necessarily
choose option (3) over (2).
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/