-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
net: LookupNS doesn't chase through CNAMEs #44199
Comments
is it consistent in which domains fail and can you give an example of a failing domain? |
@seankhliao I send you PM (twitter) with real domain name. |
sorry closed by error. |
So |
@seankhliao temporary I workaround this scenarios checking CNAME when LookupNS return "no such host", but now I have another set of domains on LookupCNAME returns "no such host" too, but dig cname host works properly:
One more time test int with diferent solvers:
|
Hi, Add more information: All failing lookupCNAME resolutions are CNAMES related with xxxx.googlehosted.com domains. |
Hello,
output:
|
I'm experiencing a similar problem with LookupCNAME (go v1.20). It should return the last CNAME, but sometimes it returns the first CNAME:
Output:
The CNAME section for
Unlike LookupCNAME, the dig result is always consistent. |
What version of Go are you using (
go version
)?go1.13 darwin/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?macos and alpine container
What did you do?
I see related issues with cgo/go/cgo+1 resolvers but:
What did you expect to see?
ghs.googlehosted.com.
What did you see instead?
lookup _acme-challenge.xxxxx.cat on 192.168.50.1:53: no such host
it works fine in most cases, but not in some cases(domains) and I don't understand why.
I have the complete code running in an alpine container within a kubernetes cluster, so I rule out that it is a problem with my local dns solver.
Note: Adding net.LookupCNAME when LookupNS return error I can see the expected result. lookupNS not following CNAME? is the expected behavior?
The text was updated successfully, but these errors were encountered: