-n nameserver option not supporting name, only IPs

[FabioPedretti]

-n nameserver option not supporting name, only IPs

[L1ghtn1ng]

This is not a dnsrecon issue it's a dnspython issue

[FabioPedretti]

The dnspython issue is known to be working in some release? Can a proper version be suggested? If not dnsrecon should resolv the name and call dnspython with the IP.

[hlein]

It looks to me like this is intended to be supported?

Starting around https://github.com/darkoperator/dnsrecon/blame/master/dnsrecon/cli.py#L1557, we iterate over the nameserver argument(s). Line 1565 seems to be resolving provided nameserver hostnames to IPs:

            # Resolve in the case if FQDN
            answer = socket_resolv(entry)

...The problem is the quoted error is thrown when entry is used first thing in the loop, line 1558, before it has been resolved. It makes sense that you can't tell your DNS library to use a hostname to send requests to, since... it needs to have an IP to send to. Should the resolve check simply be moved earlier in the for loop? Or if there's no intention to support --name_servers arguments of hostnames, dnsrecon could reject them with a cleaner error message, and probably s/Domain server to use/Domain server IP to use/ in the usage, as well.

[L1ghtn1ng]

More than happy to except a PR if you would like to contribute a fix? On 23 Apr 2022, at 23:04, hlein ***@***.***> wrote:  It looks to me like this is intended to be supported? Starting around https://github.com/darkoperator/dnsrecon/blame/master/dnsrecon/cli.py#L1557, we iterate over the nameserver argument(s). Line 1565 seems to be resolving provided nameserver hostnames to IPs: # Resolve in the case if FQDN answer = socket_resolv(entry) ...The problem is the quoted error is thrown when entry is used first thing in the loop, line 1558, before it has been resolved. It makes sense that you can't tell your DNS library to use a hostname to send requests to, since... it needs to have an IP to send to. Should the resolve check simply be moved earlier in the for loop? Or if there's no intention to support --name_servers arguments of hostnames, dnsrecon could reject them with a cleaner error message, and probably s/Domain server to use/Domain server IP to use/ in the usage, as well. — Reply to this email directly, view it on GitHub<#217 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA3V2QSKK6IPEZTEMAQ6HE3VGRXVDANCNFSM5RUTP57Q>. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[darkoperator]

Normally in a pentest/redteam on tests each individual name server, that is why when I wrote the tool made it and tested it with ip addresses in mind. Should probably document that as a best practice to avoid using a FQDN since one may hit different name servers and makes it harder to do repeatable validation.

…

Sent from my iPhone

On Apr 23, 2022, at 6:36 PM, J.Townsend ***@***.***> wrote:  More than happy to except a PR if you would like to contribute a fix? On 23 Apr 2022, at 23:04, hlein ***@***.***> wrote:  It looks to me like this is intended to be supported? Starting around https://github.com/darkoperator/dnsrecon/blame/master/dnsrecon/cli.py#L1557, we iterate over the nameserver argument(s). Line 1565 seems to be resolving provided nameserver hostnames to IPs: # Resolve in the case if FQDN answer = socket_resolv(entry) ...The problem is the quoted error is thrown when entry is used first thing in the loop, line 1558, before it has been resolved. It makes sense that you can't tell your DNS library to use a hostname to send requests to, since... it needs to have an IP to send to. Should the resolve check simply be moved earlier in the for loop? Or if there's no intention to support --name_servers arguments of hostnames, dnsrecon could reject them with a cleaner error message, and probably s/Domain server to use/Domain server IP to use/ in the usage, as well. — Reply to this email directly, view it on GitHub<#217 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA3V2QSKK6IPEZTEMAQ6HE3VGRXVDANCNFSM5RUTP57Q>. You are receiving this because you modified the open/close state.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[L1ghtn1ng]

Thanks for the input Carlos On 23 Apr 2022, at 23:43, Carlos Perez ***@***.***> wrote:  Normally in a pentest/redteam on tests each individual name server, that is why when I wrote the tool made it and tested it with ip addresses in mind. Should probably document that as a best practice to avoid using a FQDN since one may hit different name servers and makes it harder to do repeatable validation.

Sent from my iPhone

On Apr 23, 2022, at 6:36 PM, J.Townsend ***@***.***> wrote:  More than happy to except a PR if you would like to contribute a fix? On 23 Apr 2022, at 23:04, hlein ***@***.***> wrote:  It looks to me like this is intended to be supported? Starting around https://github.com/darkoperator/dnsrecon/blame/master/dnsrecon/cli.py#L1557, we iterate over the nameserver argument(s). Line 1565 seems to be resolving provided nameserver hostnames to IPs: # Resolve in the case if FQDN answer = socket_resolv(entry) ...The problem is the quoted error is thrown when entry is used first thing in the loop, line 1558, before it has been resolved. It makes sense that you can't tell your DNS library to use a hostname to send requests to, since... it needs to have an IP to send to. Should the resolve check simply be moved earlier in the for loop? Or if there's no intention to support --name_servers arguments of hostnames, dnsrecon could reject them with a cleaner error message, and probably s/Domain server to use/Domain server IP to use/ in the usage, as well. — Reply to this email directly, view it on GitHub<#217 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA3V2QSKK6IPEZTEMAQ6HE3VGRXVDANCNFSM5RUTP57Q>. You are receiving this because you modified the open/close state.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

— Reply to this email directly, view it on GitHub<#217 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA3V2QSQ3EIDHLPSFRSVOX3VGR4JBANCNFSM5RUTP57Q>. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[hlein]

More than happy to except a PR if you would like to contribute a fix?

Sure, I'll try to get to it and/or assign an intern to it :)

My inclination would be to go ahead and support expanding a name to IP(s), like the code currently seems to try to do. But if the preference is to only support IPs in light of @darkoperator's comment, and to make relevant usage/error updates, please let me know.

[L1ghtn1ng]

The usage and error updates would be good 😊 On 24 Apr 2022, at 01:04, hlein ***@***.***> wrote:  More than happy to except a PR if you would like to contribute a fix? Sure, I'll try to get to it and/or assign an intern to it :) My inclination would be to go ahead and support expanding a name to IP(s), like the code currently seems to try to do. But if the preference is to only support IPs in light of @darkoperator<https://github.com/darkoperator>'s comment, and to make relevant usage/error updates, please let me know. — Reply to this email directly, view it on GitHub<#217 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA3V2QSGBXNXGI6OAXKRXYDVGSFX7ANCNFSM5RUTP57Q>. You are receiving this because you modified the open/close state.Message ID: ***@***.***>