[Bug network/24255] resolver should handle special domains correctly

[Bug network/24255] resolver should handle special domains correctly

[pemensik at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24255

Petr Menšík <pemensik at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pemensik at redhat dot com

--- Comment #1 from Petr Menšík <pemensik at redhat dot com> ---
I do not think this is a good idea. If one is running a local cache on his
machine, he might be able to forward onion. zone and all requests to it into
TOR network to appropriate DNS servers.

That would be no longer possible if glibc blocked that query from DNS. I think
we want it blocked only from forwarding to 3rd party servers. For example
unbound or bind will create empty zones for it, blocking forwarding it to
upstream DNS servers. That is what we want. It either handles it or blocks it.

I don't think this can be decided by glibc, it is not aware of configuration
details of DNS. I would instead propose to have optional NSS hosts plugin with
configurable blocklist, which could be put before dns in /etc/nsswitch.conf. If
you would include onion in it, it would authoritatively say does not exist
without allowing that in DNS. If you would have local dns cache able to
configure this properly, it would not use such module.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/24255] resolver should handle special domains correctly

[crrodriguez at opensuse dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24255

--- Comment #2 from Cristian Rodríguez <crrodriguez at opensuse dot org> ---
(In reply to Petr Menšík from comment #1)
> I do not think this is a good idea. If one is running a local cache on his
> machine, he might be able to forward onion. zone and all requests to it into
> TOR network to appropriate DNS servers.
> 
> That would be no longer possible if glibc blocked that query from DNS. I
> think we want it blocked only from forwarding to 3rd party servers. For
> example unbound or bind will create empty zones for it, blocking forwarding
> it to upstream DNS servers. That is what we want. It either handles it or
> blocks it.
> 
> I don't think this can be decided by glibc, it is not aware of configuration
> details of DNS. I would instead propose to have optional NSS hosts plugin
> with configurable blocklist, which could be put before dns in
> /etc/nsswitch.conf. If you would include onion in it, it would
> authoritatively say does not exist without allowing that in DNS. If you
> would have local dns cache able to configure this properly, it would not use
> such module.

This is not what the relevant standards say though.

" 3.  Name Resolution APIs and Libraries: Resolvers MUST either respond
       to requests for .onion names by resolving them according to
       [tor-rendezvous] or by responding with NXDOMAIN [RFC1035]."

glibc does not know and will probably never know by itself  how to
tor-rendezvous, it could of course do it using an nss-module which must come
before dns or files in /etc/nsswitch.conf ..but the dns and files module must
return NXDOMAIN on such names.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/24255] resolver should handle special domains correctly

[pemensik at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24255

--- Comment #3 from Petr Menšík <pemensik at redhat dot com> ---
I do not think we ever want to override output of files database. If the user
defines his own example.onion name in /etc/hosts, then he should receive it in
queries. He wants it and we should not filter his wishes.

And for DNS, we cannot know if that the server is connected to Tor or not. I
guess we could block DNS query if the server were not sent to ::1 or
127.0.0.0/8. But handling this at dns plugin seems wrong to me. And it should
be possible to configure it for unusual setups, where we want it forwarded
anyway.

I think system services like Network Manager or systemd-networkd would be
better suited to decide whether such queries should be forwarded or discarded
on low level. Perhaps Tor service could remove onion domain from blocked list
on startup and return it when shut down.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/24255] resolver should handle special domains correctly

[milahu at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24255

milahu <milahu at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |milahu at gmail dot com

--- Comment #4 from milahu <milahu at gmail dot com> ---
> for DNS, we cannot know if that the server is connected to Tor or not

imo, the optimal solution would be
to extend /etc/resolv.conf with something like

> option allow-domains *.onion

... to make tools like curl and git "just work"
on machines behind a transparent tor proxy
where these tools currently throw the error

> Not resolving .onion address (RFC 7686)

... and currently
we need non-transparent workarounds like

> curl --proxy socks5h://127.0.0.1:9050
> git -c remote.origin.proxy=socks5h://127.0.0.1:9050

... or expensive workarounds like "rebuild curl"
which on systems like nixos or guix means "rebuild the world"



this config belongs to /etc/resolv.conf
because its a machine-level config
which affects all DNS clients on that machine

the default config would be something like

> option deny-domains *.onion *.i2p



see also

https://github.com/curl/curl/discussions/11125
I want to resolve onion addresses

https://gitlab.torproject.org/tpo/core/torspec/-/issues/202
Formalize toggle override for non-Tor applications that follow RFC 7686

-- 
You are receiving this mail because:
You are on the CC list for the bug.