Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full URL is sent to DNS resolver #695

Closed
TheTechromancer opened this issue Jul 13, 2022 · 8 comments
Closed

Full URL is sent to DNS resolver #695

TheTechromancer opened this issue Jul 13, 2022 · 8 comments
Assignees
Labels
Priority: High After critical issues are fixed, these should be dealt with before any further issues. Status: Completed Nothing further to be done with this issue. Awaiting to be closed. Type: Bug Inconsistencies or issues which will cause an issue or problem for users or implementors. Type: Question A query or seeking clarification on parts of the spec. Probably doesn't need the attention of all.
Milestone

Comments

@TheTechromancer
Copy link

Hello,

Recently in our testing we have noticed that when provided URLs, httpx sometimes fails to resolve DNS hosts:

image

Inspecting the traffic in wireshark reveals that httpx is passing the full URL to the DNS server:

image

@TheTechromancer TheTechromancer added the Type: Bug Inconsistencies or issues which will cause an issue or problem for users or implementors. label Jul 13, 2022
@ehsandeep
Copy link
Member

@TheTechromancer thanks a lot for pointing this out, we were already investigating something which might be related to this (not confirmed).

@ehsandeep ehsandeep added the Priority: High After critical issues are fixed, these should be dealt with before any further issues. label Jul 14, 2022
@Mzack9999 Mzack9999 self-assigned this Jul 18, 2022
@Mzack9999
Copy link
Member

@TheTechromancer Thanks for opening the issue. I can confirm that the five consecutive requests with the same request-id of type A and AAAA seem to match the retryabledns default settings. Anyway, a few things are unclear. For example, the full URL https://www.example.com:80/index.html, from the command screenshot you provided, was never piped into httpx. Also, the AAAA shows two times OPT OPT. Could you confirm if the provided command is the exact one associated with the Wireshark screenshot?

@Mzack9999 Mzack9999 added Type: Question A query or seeking clarification on parts of the spec. Probably doesn't need the attention of all. Status: On Hold Similar to blocked, but is assigned to someone labels Jul 18, 2022
@TheTechromancer
Copy link
Author

TheTechromancer commented Jul 18, 2022

The target corresponding to the wireshark screenshot was https://www.example.com/index.html, as shown in the capture. These were two separate runs; I mixed them up. So the command that generated the wireshark screenshot was:

echo 'http://www.example.com/index.html' | httpx -debug -json -r <dns server>

Just now I went back to verify this, and strangely I am no longer seeing the URL in the capture. I'm unsure why this is, since I'm using the same binary as before (version 1.2.3), but the DNS requests still seem to fail against the custom resolver.

image

image

@Mzack9999
Copy link
Member

I suspect the problem might be between https://github.com/projectdiscovery/retryabledns and the custom resolver. Would it be possible to provide more information about it: DNS server software used? Any particular configuration?

@TheTechromancer
Copy link
Author

Sure. It is an Active Directory domain controller running Windows Server 2012 R2 with the DNS server role and a default configuration. The forwarder (upstream DNS server) is set to 8.8.8.8.

@Mzack9999
Copy link
Member

On Hold - Not reproducible, will need a custom setup similar to the described scenario.

@Mzack9999
Copy link
Member

The issue can't be reproduced - It seems more related to the OS configuration than the go app itself. By default, we already use system resolvers in retryabledns.

@Mzack9999 Mzack9999 added the Status: Completed Nothing further to be done with this issue. Awaiting to be closed. label Dec 28, 2022
@ehsandeep ehsandeep added this to the v1.2.6 milestone Jan 5, 2023
@gitevildelta
Copy link

The issue can't be reproduced - It seems more related to the OS configuration than the go app itself. By default, we already use system resolvers in retryabledns.

I had the same issue with the latest version of httpx (1.3.9), curl was working fine but not httpx, I fixed that by using -r 127.0.0.53 to use systemd-resolved resolver (which should be the system resolver)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: High After critical issues are fixed, these should be dealt with before any further issues. Status: Completed Nothing further to be done with this issue. Awaiting to be closed. Type: Bug Inconsistencies or issues which will cause an issue or problem for users or implementors. Type: Question A query or seeking clarification on parts of the spec. Probably doesn't need the attention of all.
Projects
None yet
Development

No branches or pull requests

4 participants