Dnsx is not functioning properly.

[edgy elk]

What does output run normally look like

Without hc

[winged agate]

According to the documentation, the normal one should be -a to output the a record of dns. Then I got nothing

[edgy elk]

Given you cut off the next line, I assume it is just the prompt and no output? What about debug/verbose

[winged agate]

I did not get any useful information, even when I specified to resolve it as 8.8.8.8, there was no response.

[winged agate]

I don't know if it's a bug or not, but this logic is awkward to use

I checked the readme again, and I realized my thoughts were wrong. Sorry.

[edgy elk]

So you were getting results? You literally cut them off in every screen shot if so

[winged agate]

I solved it, thank you. After reviewing the documentation, I realized that the -l option only accepts standard input or a file. For example, when using dnsx -l google.com, the argument google.com is not treated as a parameter, but as a file. The correct usage should be: echo google.com | dnsx.

Initially, I wanted to use dnsx to check the IP of a domain. Based on the information mentioned earlier, the correct command should be: echo google.com | dnsx -ro.

It would be even better if the -d option, in addition to resolving DNS during brute-forcing, could also be used for DNS resolution. Additionally, there should be an error message if the -l option fails to find the specified file.

[edgy elk]

Are you saying you can't have it resolve when using -d?

[winged agate]

-d, -domain string list of domain to bruteforce (file or comma separated or stdin)

-d is a parameter for brute-forcing subdomains and does not support direct resolution to IP addresses.

[edgy elk]

How does it know it has a valid domain unless it finds a valid dns record, which it would have to resolve to determine

[winged agate]

you right

[edgy elk]

What has me confused is you saying it doesn't do it makes it hard to help when the info you are giving isn't accurate