On Tue, Jan 26, 2016 at 9:19 AM, Dan Williams
<dcbw(a)redhat.com>
wrote:
> On Mon, 2016-01-25 at 19:43 -0800, Andrew Lutomirski wrote:
> > On Mon, Jan 25, 2016 at 6:34 PM, Peter Robinson <
> > pbrobinson(a)gmail.com
> > > wrote:
> > > > > > > > It is intended as a convenient fallback
mechanism,
> > > > > > > > and is
> > > > > > > > only supposed
> > > > > > > > to have an effect if 'gateway' is not
defined in the
> > > > > > > > local DNS (the
> > > > > > > > 'domain' or 'search' zones).
Would it help if those
> > > > > > > > limitations were
> > > > > > > > more explicit, e.g. documented in
nss-myhostname(8)?
> > > > > > >
> > > > > > > I understand that the goal is that nss_myhostname
will
> > > > > > > not
> > > > > > > override
> > > > > > > existing names, due to the way the NSS is configured.
> > > > > > >
> > > > > > > What I do not understand is how the the “gateway”
name
> > > > > > > can
> > > > > > > be
> > > > > > > useful.
> > > > > >
> > > > > > Here's a very obvious, trivial example: wherever I am
I
> > > > > > can
> > > > > > now simply
> > > > > > type "ping gateway" to know whether connectivity
to my
> > > > > > local
> > > > > > router
> > > > > > works.
> > > > >
> > > > > But that's not actually true, isn't it? If
nss_myhostname
> > > > > doesn't
> > > > > override “gateway”, the outcome depends on the network you
> > > > > are
> > > > > on. With
> > > > > a captive portal, you are likely pinging the portal server,
> > > > > not
> > > > > the
> > > > > default gateway. And if you are on one of Microsoft's
> > > > > corporate
> > > > > networks, you might end up at
gateway.microsoft.com
> > > > > (whatever
> > > > > this
> > > > > is).
> > > >
> > > > Well, IRL you'd actually quickly notice, since ping shows you
> > > > the
> > > > full
> > > > fqdn of the host, and hence gives you a very clear hint on
> > > > what
> > > > it is
> > > > actually pinging.
> > > >
> > > > > Because it's so unreliable, we cannot put this trick into
> > > > > documentation,
> > > > > and we shouldn't train users to rely on this functionality.
> > > >
> > > > Yeah, single-label names are like that. If you want trustable
> > > > single-label names, you better shouldn't use search domains
> > > > (and
> > > > quite
> > > > frankly, I am not particularly a fan of the search domain
> > > > concept
> > > > myself, because of its ambiguities. In systemd-resolved we by
> > > > default
> > > > ignore the DHCP-reported search domains because of this.)
> > > >
> > > > Note that systemd-resolved's LLMNR implementation actually
> > > > excepts
> > > > itself from resolving "gateway" even though a single-label
> > > > name
> > > > (it
> > > > also excepts itself from a couple of other names, such as
> > > > "localhost"). Which basically means: the
"gateway" name is
> > > > safe
> > > > exactly when you turn off the search domain logic (or to put
> > > > this
> > > > correctly if networkd is used: it is safe unless you *turn
> > > > on*
> > > > the
> > > > search domain logic).
> > > >
> > > > > Right. If software (or documentation) uses “gateway” to
> > > > > mean
> > > > > “address
> > > > > of the default gateway”, it will break, depending on search
> > > > > path
> > > > > configuration and other network properties.
> > > > >
> > > > > I don't think this is what Fedora wants (and what you
> > > > > intended).
> > > >
> > > > I disagree. It only breaks if the user enables domain search
> > > > logic,
> > > > and configures a domain in there that actually serves a host
> > > > called
> > > > "gateway".
> > >
> > > Which from my time, a good 10 years or so, at a large global
> > > service
> > > provider and as a Red Hat consultant on customer sites both of
> > > those
> > > were often true so I'm not sure it's something that you can
> > > assume
> > > either way. And given on those networks there's generally LOT
> > > of
> > > legacy platforms that make assumptions about that sort of thing
> > > I'm
> > > not sure it's something you can just turn around and say "well
> > > just
> > > turn it off you idiots".
> > >
> >
> > I think that the "gateway" override should not be conflated with
> > always letting the gethostname(2) return value resolve.
> >
> > I also think that the whole gethostname(2) mechanism is
> > terminally
> > screwed up. We abuse the hostname for multiple purposes:
> >
> > 1. It shows up in the default bash prompt.
> > 2. It gets sent to remote DHCP servers. I think this is a
> > mistake on
> > desktop machines
>
> When sent to DHCP servers, the hostname is used only for DDNS
> updates
> and not for any kind of client identification. That's what the
> Client
> Identifier is used for, or missing that, the MAC address (depending
> on
> the server). I'm not aware of any DHCP server that uses the DDNS
> hostname as a lease identifier.
>
> It's not a mistake to send a hostname if your DHCP server also
> handles
> DDNS updates. It doesn't have to be the name set for the local
> machine, but almost all of the time its going to be since you want
> your
> local queries to return the same result for your machine name as
> non
> -local queries would.
>
> One problem is that there is no way to determine that the DHCP
> server
> has DDNS functionality enabled, and thus to selectively send the
> hostname. Which is why NetworkManager has ipv4.dhcp-send-hostname
> and
> ipv6.dhcp-send-hostname toggles so you can turn it off.
I think this depends a bit on the use case.
On a public network, I think that NetworkManager and related tools
should send the bare minimum of identifying information. I think
that
means that a MAC address should be sent and as little as possible
that
isn't a MAC address. If I name my computer "fluffybunnies" or
"mysocialsecuritynumber", I do *not* want to advertise that, and if
something else on the network is trying to resolve fluffybunnies
using
DDNS, then something is already very wrong.
On a private network that uses pre-assigned MAC-to-IP+name or
port-to-IP+name mappings on the DHCP server, DDNS is irrelevant.
That leaves only private networks that actually use DDNS in some
useful manner with a user clueful enough to set up a meaningful name.
I still think that, for the default workstation use case, configuring
a hostname as a mandatory part of installation is counterproductive.
Would it make sense to improve support for hostname-less
workstations?
NetworkManager could take hostname=="localhost" or
"localhost.localdomain" to mean that DDNS should be turned off and
the
client ID should be "MAC<digits>" instead of "localhost".Would
it
make
sense to teach NetworkManager to skip sending the client ID (or send
some compatibility value) instead of "localhost"?
If public vs private networks ever get implemented in a meaningful
manner, the same behavior could be flipped on for public networks.
Agreed. The issue is more around UI; no interaction gurus that I know
think the Windows "PICK A ZONE FOOL!!!" is the right thing to do. We
do have the firewall zone thing in NetworkManager, but that's not quite
the same thing as public/private networks, thought they are closely
related. It's all possible to set right now by:
nmcli con mod <name> ipv4.dhcp-send-hostname false
nmcli con mod <name> ipv4.dhcp-client-id "sillyclientid"
nmcli con mod <name> 802-11-wireless.mac-address-randomization 2
and maybe a couple other toggles. But it's more about the interaction
design than any underlying deficiencies in the software.
Dan