mirror of
https://github.com/mageddo/dns-proxy-server.git
synced 2026-04-25 09:25:56 +03:00
[GH-ISSUE #54] Server does not handle unquallified domains well in some conditions #23
Labels
No labels
bug
confirmed
discussion
duplicate
enhancement
feature
feature-request
not-planned
pull-request
secondary-feature
stale
triage
waiting-feedback
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/dns-proxy-server-mageddo#23
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @firelizzard18 on GitHub (Dec 4, 2017).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/54
The core issue here is when A)
/etc/resolv.confspecifies DNS search domains and B) I request an unqualified hostname owned by a container,dns-proxy-serverqueries the nameservers before resolving the hostname to the container.nslookup example-app., I get a prompt responsenslookup example-app, the server appends the search domain, queries the name servers, and waits for those queries to fail before it returns the appropriate responseconfig:
/etc/resolv.conf:nslookup example-app.:Logs:
nslookup example-app:Logs:
@mageddo commented on GitHub (Dec 4, 2017):
@firelizzard18 Thank you for the very well explained case, I will work on that
@mageddo commented on GitHub (Dec 4, 2017):
@firelizzard18 What do you think would be the expected behavior here?
@mageddo commented on GitHub (Dec 5, 2017):
@firelizzard18 I tried to reproduce your issue then I got the same problem. Anyway I solved using another approach(specifying the domain sufix at container hostname)
/etc/resolv.conf
starting container
testing it
or solving by custom domain suffix
Now I want to understand, does it works and is ok for you or you have some point? Thank you
@firelizzard18 commented on GitHub (Dec 5, 2017):
I expect
dns-proxy-serverto first try to find a match for the query within the docker containers' hostnames, regardless of whether the name in the query is fully-qualified.The diagram in the readme shows the following resolution strategy:
It seems to me that this strategy holds true when the query specifies a fully-qualified domain name. But when the query specifies an unqualified domain name,
dns-proxy-serverdoes not follow the above, as it queries remote resolvers before looking for a match in docker. Or perhaps it tries the entire resolution strategy using the qualified name and then the entire strategy with the unqualified name.I have a container server that is running multiple containerized services. I need all of the services to be accessible on the default port (HTTP), so I need to use virtual hosts. Therefore I must use a reverse proxy.
One of the apps is
example-app, accessible ashttp://example-apporhttp://example-app.ExampleDomain.local. This app is running in a container configured with a hostname ofcontainer-example-app. So I need to set up a reverse proxy fromexample-appandexample-app.ExampleDomain.localtocontainer-example-app. Howevercontainer-example-apponly means anything in the context of the container server so it shouldn't be suffixed withExampleDomain.local.@mageddo commented on GitHub (Dec 8, 2017):
Sorry for the too late answer, I took a while to understand this problem. The conclusion was:
DPS can solve names without domains e.g.
container-example-appanyway it is not working with nslookup for me(I don't know why yet), I proved that with digStarting container for tests
Testing hostname with dig
DPS logs
or using a go script
main.go
out
DPS LOG
Back to your problem...
As you can see the go application asks the hostname IP to linux then Linux asks to DPS, as your system has a search domain and you are looking for a name that have not a domain Linux first try to solve the hostname appended with the configured search domain, this way DPS receives a request like
nginx1.ExampleDomain.localand don't found a container with that name(and that is correct), then proxy it to a remote server, as you mentioned your remote server is slow to answer for a name that doesn't exists probably Linux is aborting the connection before try to solvenginx1(which is tried last).The conclusion is that I think we can solve your problem by limiting the remote server timeout to respond in DPS, anyway it is not implemented yet, I might it is not hard to do.
If you look to the first log you sent you can see the
example-appbeing solved but probably your client doesn't waited it responds.DPS = Dns Proxy Server
@mageddo commented on GitHub (Dec 8, 2017):
See resolv.conf reference
And this stack exchange answer
I understood:
If you have a search domain configured then Linux will ask DNS Server by
domain+search domainIF domain have not dots, then there is not guarantee that Linux will askexample-app(without search domain) to DPS, I think it will depend the client resolver implementation. After all that's why you (and my last example) are getting this behavior.Back to my first solution maybe you might use
.docker,.container,.appin the docker container hostnames suffix, it can make more sense rather than useExampleDomain.localif remove the search is not a option.@mageddo commented on GitHub (Dec 8, 2017):
Just to let it clear, DPS look for a container with same hostname as requested by the client, it don't try to match domain prefixes
@firelizzard18 commented on GitHub (Dec 9, 2017):
Ah. For now I'll probably use some kind of suffix like you suggest. Or maybe talk to IT and figure out why the upstream DNS servers take so long.
Adding DPS configuration for upstream DNS request timeout could be nice, but I think that's a separate issue and not how I want to solve my problem.