systemd-resolved namespacing

[Andrew Athan <aathan_systemd@xxxxxxxxxxxx>]

    I'm not sure this is the right place to pose this question, nor that
    I'm asking the "right" question, so kindly direct me if I "have it
    all wrong."
    
    Question:
    
    Having looked at the "namespace" features such as those of `ip
    netns` and/or those available via `unshare` or even `systemd-nspawn`
    it seems there is a rather large hole in that DNS resolution and the
    associated caches cross namespace boundaries. I suppose this is a
    general problem faced by any system/node level caching service
    accessed by APIs from within namespaces.
    
    Maybe I'm thinking about this wrong, but it would seem to me that
    network services such as the DNS cache should respect namespace
    boundaries. Otherwise, a container that has (for example) set an
    /etc/netns/othernamespace/resolv.conf pointing to a different DNS
    server than the node's main resolv.conf will receive cached
    responses from queries made outside its namespace.
    
    Probably this is an issue that goes beyond systemd-resolved and
    should also be addressed in glibc's "nss" helpers such as
    nss-resolve and nss-dns and/or any associated caches.
    
    Are there plans to address this issue? I'm assuming there's enough
    information about the context of a resolution request at the time
    systemd-resolved receives that request, for it to know the namespace
    into which it is vending its response? Perhaps this would not be the
    case for queries sent to the stub 127.0.0.53 address, but I imagine
    even this could at be dealt with by providing multiple stub
    responders on separate IPs that can be targeted appropriately from
    within each network namespace.
    
    It's possible the "safe" solution is to turn of name resolution and
    other caches or to use a more complete container solution (e.g. a
    more complete virtual OS instance) and that pushing namespace
    support into the resolver is some kind of slippery slope -- but it
    seems like a clear and present (and common) need, if not danger.
    
    
    
    Things I've read before posting this:
    
    man 8 nsenter
    man 8 ip-netns
    man 8 systemd-resolved
    man 1 systemd-nspawn
    man nss-resolve
    https://gist.github.com/zoilomora/f7d264cefbb589f3f1b1fc2cea2c844c
    
    The motivating usecase:
    
    client apps operating in a namespace, through a Wireguard VPN device
    with default routes and DNS via the far end should resolve names
    always as if the DNS server configured in the namespace's
    resolv.conf sourced the response.
    
    Thanks!
    Andrew