Default DNS resolvers should pull from system settings about fastdialer HOT 4 CLOSED

Thanks for replying. I can understand the decision, it makes sense that the public DNS servers can better handle the load. It might be helpful to explicitly state this in the documentation for each of the tools.

Is there any chance at at all that this had anything to do with initial failures? We noticed it in the first place being in an environment where 8.8.8.8,1.1.1.1, etc were suddenly blocked and the local system resolver wasn't very forgiving.

from fastdialer.

This is a deviation from the expected behavior, which is to use the host systems DNS configuration as a default. This is, for example, the way curl works.

@liquidsec this is actually intentional, using DefaultResolvers instead of system resolver in all the PD tools as default and optionally support using system resolver when required, the reason being, unlike curl, these tools dnsx/naabu/httpx/nuclei/tlsx meant to used and required to perform large scale dns resolution and relying on system resolvers resulted into multiple failures initially mainly because system resolvers are not sufficient to work with large inputs.

from fastdialer.

@liquidsec Thanks for opening this issue. By default, fastdialer, unless the user specifies otherwise, builds a list of base resolvers consisting of the public ones you provided (1.1.1.1:53, 1.0.0.1:53, 8.8.8.8:53, 8.8.4.4:53) along with the default system resolvers. As you can see from the default options, by default, we parse the system resolver file (ref

from fastdialer.

The code seems to cover already the case mentioned - Converting to discussion

from fastdialer.