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

Can't resolve from outside of containers. #508

Open
bwskin opened this issue Sep 17, 2024 · 2 comments · May be fixed by #512
Open

Can't resolve from outside of containers. #508

bwskin opened this issue Sep 17, 2024 · 2 comments · May be fixed by #512
Assignees

Comments

@bwskin
Copy link

bwskin commented Sep 17, 2024

With version 1.12.0 I can't get results from aardvark-dns directly from host system. Downgrade to 1.11.0 fixes it. It works correctly when accessing from container.

With v1.11.0:

~> nslookup gitea 172.20.0.1
Server:		172.20.0.1
Address:	172.20.0.1#53

Non-authoritative answer:
Name:	gitea
Address: 172.20.0.8

With v1.12.2, same config:

> nslookup gitea 172.20.0.1
Server:		172.20.0.1
Address:	172.20.0.1#53

** server can't find gitea: NXDOMAIN

Is that expected behaviour now? Or is it configurable (using podman config)?

@Luap99
Copy link
Member

Luap99 commented Sep 18, 2024

We generally never really considered/supported the use case of resolving the names from the host directly.

I think I "broke" this in my rework (not intentionally) so if it worked before we can add it back if it is useful

@bwskin
Copy link
Author

bwskin commented Sep 18, 2024

It's useful for me, for example with ssh passing through to gitea. I just have aardvark-dns as additional resolver for some names in dnsmasq. Host can get ip address of the container to connect, and I don't have to maintain static ip list for every service container i have. Pretty convenient to have it.

@Luap99 Luap99 self-assigned this Sep 19, 2024
Luap99 added a commit to Luap99/aardvark-dns that referenced this issue Sep 19, 2024
In my rework it seems I broke the weird way how we tried to resolve
names when we have no source ip match. Let's do this properly and move
the logic all into lookup() which makes it much cleaner and no
duplication needed.

Now there is catch here, we only lookup the network for the current
network listener, so if the user has multiple networks they always must
target the requests against the correct ip depeding on what network the
name is in. But this is the same as it worked before and seems safer
than allowing a unknown ip to access all names I guess.

Fixes containers#508

Signed-off-by: Paul Holzinger <[email protected]>
@Luap99 Luap99 linked a pull request Sep 19, 2024 that will close this issue
Luap99 added a commit to Luap99/aardvark-dns that referenced this issue Sep 19, 2024
In my rework it seems I broke the weird way how we tried to resolve
names when we have no source ip match. Let's do this properly and move
the logic all into lookup() which makes it much cleaner and no
duplication needed.

Now there is catch here, we only lookup the network for the current
network listener, so if the user has multiple networks they always must
target the requests against the correct ip depeding on what network the
name is in. But this is the same as it worked before and seems safer
than allowing a unknown ip to access all names I guess.

Fixes containers#508

Signed-off-by: Paul Holzinger <[email protected]>
Luap99 added a commit to Luap99/aardvark-dns that referenced this issue Sep 20, 2024
In my rework it seems I broke the weird way how we tried to resolve
names when we have no source ip match. Let's do this properly and move
the logic all into lookup() which makes it much cleaner and no
duplication needed.

Now there is catch here, we only lookup the network for the current
network listener, so if the user has multiple networks they always must
target the requests against the correct ip depeding on what network the
name is in. But this is the same as it worked before and seems safer
than allowing a unknown ip to access all names I guess.

Fixes containers#508

Signed-off-by: Paul Holzinger <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants