Discussion:
nss_myhostname as default in Fedora
(too old to reply)
Orion Poplawski
2016-01-21 22:18:47 UTC
Permalink
See https://bugzilla.redhat.com/show_bug.cgi?id=1284323 as well

For a while (from 197-1 until 228-5), systemd added "myhostname" to the end of
the hosts line in /etc/nsswitch.conf in %post via sed. This has been removed
as it is error prone, and the above request filed to add it by default to
/etc/nsswitch.conf in glibc. The glibc maintainer would like to see
discussion of this on the devel list, hence this email.

My interest in this stems from build issues with mpich using programs. This
may have been triggered by a combination of the above change as well as
changes in mpich, I'm not sure. In any case, mpich uses gethostbyname() on
the hostname of the machine it is running on in order to configure itself
properly, and fails if it cannot do this. So the mpich tests run by netcdf
are currently failing on the builders, and has since Nov 27 when systemd
dropped adding myhostname took place.

So:

- Is the change to nsswitch.conf in glibc (back to behavior that was the
default for quite a while) desired?

- If not, is there some other way we can get the koji builders' mock
configuration to be setup so they can at least resolve their own hostname?

Thanks.

PS - There is some other discussion around "mymachines" which seems much more
problematic. I'd like to just focus on myhostname for now. The glibc
maintainer has indicated that he wants to wait for mymachines to be resolved,
but it's almost two months now and I don't see that being resolved soon.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane ***@nwra.com
Boulder, CO 80301 http://www.nwra.com
Michael Catanzaro
2016-01-22 00:36:45 UTC
Permalink
See https://bugzilla.redhat.com/show_bug.cgi?id=1284323 as well
For a while (from 197-1 until 228-5), systemd added "myhostname" to the end of
the hosts line in /etc/nsswitch.conf in %post via sed.  This has been
removed
as it is error prone, and the above request filed to add it by
default to
/etc/nsswitch.conf in glibc.  The glibc maintainer would like to see
discussion of this on the devel list, hence this email.
I don't care how it gets there, but I very much hope it gets there
somehow. mpich is not the only program that will be broken without
nss_myhostname.
Zbigniew Jędrzejewski-Szmek
2016-01-22 01:14:47 UTC
Permalink
Hi,

yes, it's been a while with little progress. Initially I thought
it would be just a packaging issue, but various issues were raised
which require upstream fixes. I let it slip, but I still hope
to get this finished. Thank you for pushing for a resolution.
Post by Orion Poplawski
- Is the change to nsswitch.conf in glibc (back to behavior that was the
default for quite a while) desired?
I think there is general agreement that it is desirable, but got
stalled on technical issue and tied up with nss_mymachines. The
technical issue was that nss_myhostname.so was overlinked. My pull
request was merged upstream yesterday, but unfortunately it doesn't
solve the issue completely. I was told that Debian patches the build
process to fix the issue, but I haven't looked into it. Maybe glibc
maintainers would be OK with adding nss_myhostname now (after systemd
is rebuilt with the patch), without waiting for nss_mymachines.
Post by Orion Poplawski
- If not, is there some other way we can get the koji builders' mock
configuration to be setup so they can at least resolve their own hostname?
Thanks.
PS - There is some other discussion around "mymachines" which seems much more
problematic. I'd like to just focus on myhostname for now. The glibc
maintainer has indicated that he wants to wait for mymachines to be resolved,
but it's almost two months now and I don't see that being resolved soon.
Yeah, mymachines is much more specific and problematic. It shouldn't
hold up myhostname.

Zbyszek
Florian Weimer
2016-01-22 18:06:26 UTC
Permalink
Post by Orion Poplawski
PS - There is some other discussion around "mymachines" which seems much more
problematic. I'd like to just focus on myhostname for now. The glibc
maintainer has indicated that he wants to wait for mymachines to be resolved,
but it's almost two months now and I don't see that being resolved soon.
I still have philosophical objects to myhostname as well. I find it odd
that at one end, we struggle with DNS name space hijacking, but on
another end, we do basically the same thing:

<https://github.com/systemd/systemd/issues/2026>

The order in nsswitch.conf does not matter (and neither does any non-DNS
name resolution mechanism) because if we end up having software which
expects that “gateway” resolves to the IP address of the default
gateway, we still have an interoperability problem. And if “gateway” is
never intended for name resolution, why synthesize the name at all?

Florian
Zbigniew Jędrzejewski-Szmek
2016-01-22 21:45:54 UTC
Permalink
Post by Florian Weimer
Post by Orion Poplawski
PS - There is some other discussion around "mymachines" which seems much more
problematic. I'd like to just focus on myhostname for now. The glibc
maintainer has indicated that he wants to wait for mymachines to be resolved,
but it's almost two months now and I don't see that being resolved soon.
I still have philosophical objects to myhostname as well. I find it odd
that at one end, we struggle with DNS name space hijacking, but on
<https://github.com/systemd/systemd/issues/2026>
The order in nsswitch.conf does not matter (and neither does any non-DNS
name resolution mechanism) because if we end up having software which
expects that “gateway” resolves to the IP address of the default
gateway, we still have an interoperability problem. And if “gateway” is
never intended for name resolution, why synthesize the name at all?
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)?

Zbyszek
Florian Weimer
2016-01-25 08:08:07 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Florian Weimer
Post by Orion Poplawski
PS - There is some other discussion around "mymachines" which seems much more
problematic. I'd like to just focus on myhostname for now. The glibc
maintainer has indicated that he wants to wait for mymachines to be resolved,
but it's almost two months now and I don't see that being resolved soon.
I still have philosophical objects to myhostname as well. I find it odd
that at one end, we struggle with DNS name space hijacking, but on
<https://github.com/systemd/systemd/issues/2026>
The order in nsswitch.conf does not matter (and neither does any non-DNS
name resolution mechanism) because if we end up having software which
expects that “gateway” resolves to the IP address of the default
gateway, we still have an interoperability problem. And if “gateway” is
never intended for name resolution, why synthesize the name at all?
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.
As I tried to explain above, I'm not really worried about nss_myhostname
overriding name resolution, but that software relies on the specific
functionality of the “gateway” name provided by nss_myhostname, but
*this* name is overridden by DNS (with a suitable search path) or
nss_files, so that it no longer resolves to the expected address.

From my point of view, the fact that software (or the user) cannot know
that “gateway” resolves to the default gateway makes the name pretty
much useless.

What am I missing?

Florian
Lennart Poettering
2016-01-25 14:23:16 UTC
Permalink
Post by Florian Weimer
Post by Zbigniew Jędrzejewski-Szmek
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.

I also know that in my local wlan, as well as in the one of my
girlfriend's or my parent's: I can reconfigure the router by typing
http://gateway/ into my webbrowser, without having to check IP
configuration, leave the web browser, or even know the router's brand
or default configuration.
Post by Florian Weimer
As I tried to explain above, I'm not really worried about nss_myhostname
overriding name resolution, but that software relies on the specific
functionality of the “gateway” name provided by nss_myhostname, but
*this* name is overridden by DNS (with a suitable search path) or
nss_files, so that it no longer resolves to the expected address.
Search lists are local configuration. Software which relies on
specific search paths to be configured will already break pretty much
everywhere...

Lennart
--
Lennart Poettering, Red Hat
Florian Weimer
2016-01-25 16:11:59 UTC
Permalink
Post by Lennart Poettering
Post by Florian Weimer
Post by Zbigniew Jędrzejewski-Szmek
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).

Because it's so unreliable, we cannot put this trick into documentation,
and we shouldn't train users to rely on this functionality.
Post by Lennart Poettering
Post by Florian Weimer
As I tried to explain above, I'm not really worried about nss_myhostname
overriding name resolution, but that software relies on the specific
functionality of the “gateway” name provided by nss_myhostname, but
*this* name is overridden by DNS (with a suitable search path) or
nss_files, so that it no longer resolves to the expected address.
Search lists are local configuration. Software which relies on
specific search paths to be configured will already break pretty much
everywhere...
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).

Florian
Lennart Poettering
2016-01-25 16:39:33 UTC
Permalink
Post by Florian Weimer
Post by Lennart Poettering
Post by Florian Weimer
Post by Zbigniew Jędrzejewski-Szmek
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.
Post by Florian Weimer
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).
Post by Florian Weimer
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".

Lennart
--
Lennart Poettering, Red Hat
Peter Robinson
2016-01-26 02:34:57 UTC
Permalink
Post by Lennart Poettering
Post by Florian Weimer
Post by Lennart Poettering
Post by Florian Weimer
Post by Zbigniew Jędrzejewski-Szmek
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.
Post by Florian Weimer
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).
Post by Florian Weimer
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".

Peter
Andrew Lutomirski
2016-01-26 03:43:35 UTC
Permalink
Post by Peter Robinson
Post by Lennart Poettering
Post by Florian Weimer
Post by Lennart Poettering
Post by Florian Weimer
Post by Zbigniew Jędrzejewski-Szmek
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.
Post by Florian Weimer
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).
Post by Florian Weimer
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.
3. Some programs seem to thing that gethostbyname(gethostname())
should return some reasonable concept of "my ip address" despite the
general nonexistence of such a concept.

I'll propose a strawman:

- gethostname(2) always returns "localhost".

- "localhost" always resolves to 127.0.0.1 or ::1

- bash learns to use some intelligent value derived from whatever
hostnamectl would return

- the default DHCP clients send a client identifier that's a function
only of the MAC address used to send the query

- Whatever systemd magic special-cases "localhost" as "trust what
DHCP says" goes away.

and that's it.

This trivially solves one silly annoyance: when I install Fedora, why
on Earth is "what's your hostname" a reasonable question to ask me?

Servers may have their own considerations, and NetworkManager and/or
networkd could consider having a client-id override. But I think that
my strawman proposal should cover almost all desktop usecases and even
almost all server usecases.

If people really want to force a non-"localhost" hostname on a server,
then forcing it to resolve to something intelligent might make sense,
as having everything fail when resolution times out or ends up with
SERVFAIL or NXDOMAIN is nasty. But when I force my hostname to
"foo.corp.bar.com", I probably have something other than 127.0.0.1 in
mind.

Heck, strawman #2 should cover every use case:

- Anaconda defaults the hostname to "localhost". For the workstation
product, Anaconda stops asking for a hostname entirely.

- "localhost" always resolves to 127.0.0.1 or ::1

- bash learns to use some intelligent value derived from whatever
hostnamectl would return if gethostname(2) says "localhost".

- If gethostname(2) returns "localhost", then the default DHCP
clients send a client identifier that's a function only of the MAC
address used to send the query

- Whatever systemd magic special-cases "localhost" as "trust what
DHCP says" goes away.

- (optional) We add something to nsswitch.conf that causes
gethostname(2) to resolve to 127.0.0.1 or ::1 if the actual resolution
attempt results in a failure.


--Andy
Dan Williams
2016-01-26 17:19:43 UTC
Permalink
Post by Andrew Lutomirski
Post by Peter Robinson
Post by Lennart Poettering
Post by Florian Weimer
Post by Lennart Poettering
Post by Florian Weimer
Post by Zbigniew Jędrzejewski-Szmek
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.
Post by Florian Weimer
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).
Post by Florian Weimer
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
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.

Dan
Post by Andrew Lutomirski
3. Some programs seem to thing that gethostbyname(gethostname())
should return some reasonable concept of "my ip address" despite the
general nonexistence of such a concept.
- gethostname(2) always returns "localhost".
- "localhost" always resolves to 127.0.0.1 or ::1
- bash learns to use some intelligent value derived from whatever
hostnamectl would return
- the default DHCP clients send a client identifier that's a
function
only of the MAC address used to send the query
- Whatever systemd magic special-cases "localhost" as "trust what
Post by Andrew Lutomirski
DHCP says" goes away.
and that's it.
This trivially solves one silly annoyance: when I install Fedora, why
on Earth is "what's your hostname" a reasonable question to ask me?
Servers may have their own considerations, and NetworkManager and/or
networkd could consider having a client-id override. But I think that
my strawman proposal should cover almost all desktop usecases and even
almost all server usecases.
If people really want to force a non-"localhost" hostname on a
server,
then forcing it to resolve to something intelligent might make sense,
as having everything fail when resolution times out or ends up with
SERVFAIL or NXDOMAIN is nasty. But when I force my hostname to
"foo.corp.bar.com", I probably have something other than 127.0.0.1 in
mind.
- Anaconda defaults the hostname to "localhost". For the
workstation
product, Anaconda stops asking for a hostname entirely.
- "localhost" always resolves to 127.0.0.1 or ::1
- bash learns to use some intelligent value derived from whatever
hostnamectl would return if gethostname(2) says "localhost".
- If gethostname(2) returns "localhost", then the default DHCP
clients send a client identifier that's a function only of the MAC
address used to send the query
- Whatever systemd magic special-cases "localhost" as "trust what
DHCP says" goes away.
- (optional) We add something to nsswitch.conf that causes
gethostname(2) to resolve to 127.0.0.1 or ::1 if the actual
resolution
attempt results in a failure.
--Andy
--
devel mailing list
org
Andrew Lutomirski
2016-01-26 17:47:02 UTC
Permalink
Post by Dan Williams
Post by Andrew Lutomirski
Post by Peter Robinson
Post by Lennart Poettering
Post by Florian Weimer
Post by Lennart Poettering
Post by Florian Weimer
Post by Zbigniew Jędrzejewski-Szmek
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.
Post by Florian Weimer
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).
Post by Florian Weimer
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
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.

--Andy
Dan Williams
2016-01-26 18:19:46 UTC
Permalink
Post by Andrew Lutomirski
Post by Dan Williams
On Mon, Jan 25, 2016 at 6:34 PM, Peter Robinson <
Post by Peter Robinson
Post by Lennart Poettering
Post by Florian Weimer
Post by Lennart Poettering
Post by Florian Weimer
Post by Zbigniew Jędrzejewski-Szmek
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.
Post by Florian Weimer
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).
Post by Florian Weimer
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
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
Samuel Sieb
2016-01-26 20:48:18 UTC
Permalink
Post by Andrew Lutomirski
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"?
It's not mandatory for installation. If your IP address resolves, it
uses whatever hostname is returned. If not, it stays at localhost. You
can manually modify that of course, but you aren't required to. This
works perfectly for me deploying computers with freeipa. I set up the
DHCP server, the installer picks up the right name and freeipa
configures correctly.
Andrew Lutomirski
2016-01-26 21:32:35 UTC
Permalink
Post by Andrew Lutomirski
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"?
It's not mandatory for installation. If your IP address resolves, it uses
whatever hostname is returned. If not, it stays at localhost. You can
manually modify that of course, but you aren't required to. This works
perfectly for me deploying computers with freeipa. I set up the DHCP
server, the installer picks up the right name and freeipa configures
correctly.
This is rather awkward for laptops in particular. It gets a bit
confusing when my laptop's idea of what it's called varies depending
on where I am.

--Andy
Dan Williams
2016-01-26 22:03:01 UTC
Permalink
Post by Andrew Lutomirski
Post by Andrew Lutomirski
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"?
It's not mandatory for installation. If your IP address resolves, it uses
whatever hostname is returned. If not, it stays at localhost. You can
manually modify that of course, but you aren't required to. This works
perfectly for me deploying computers with freeipa. I set up the DHCP
server, the installer picks up the right name and freeipa
configures
correctly.
This is rather awkward for laptops in particular. It gets a bit
confusing when my laptop's idea of what it's called varies depending
on where I am.
The only way to keep a stable, guaranteed hostname is by putting that
into /etc/hostname, regardless of whether it's localhost or something
else. So in the workstation case, just leaving it as localhost is
fine.

FWIW, NetworkManager will never send "localhost"-type hostnames to the
DHCP server for DDNS, even if you set dhcp-send-hostname=true.

Dan
Jan Pokorný
2016-01-27 22:57:37 UTC
Permalink
Post by Andrew Lutomirski
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
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.
3. Some programs seem to thing that gethostbyname(gethostname())
should return some reasonable concept of "my ip address" despite the
general nonexistence of such a concept.
- gethostname(2) always returns "localhost".
- "localhost" always resolves to 127.0.0.1 or ::1
attempt on settle this one down: http://tools.ietf.org/html/rfc6761
(also filed https://bugzilla.redhat.com/show_bug.cgi?id=975856)
Post by Andrew Lutomirski
- bash learns to use some intelligent value derived from whatever
hostnamectl would return
- the default DHCP clients send a client identifier that's a function
only of the MAC address used to send the query
- Whatever systemd magic special-cases "localhost" as "trust what
DHCP says" goes away.
and that's it.
--
Jan (Poki)
Zbigniew Jędrzejewski-Szmek
2016-02-03 15:34:43 UTC
Permalink
Hi,
Post by Jan Pokorný
attempt on settle this one down: http://tools.ietf.org/html/rfc6761
rfc6761 is a useful reference, but it doesn't really solve this
discussion one way or another.
It's concerned with names to be "carved off a sub-tree of the DNS
namespace in which the modified name treatment rules apply", but
single label names are already special anyway.
Post by Jan Pokorný
(also filed https://bugzilla.redhat.com/show_bug.cgi?id=975856)
This is one of the problems that myhostname solves.

Zbyszek
Petr Spacek
2016-02-04 09:05:12 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Hi,
Post by Jan Pokorný
attempt on settle this one down: http://tools.ietf.org/html/rfc6761
rfc6761 is a useful reference, but it doesn't really solve this
discussion one way or another.
It's concerned with names to be "carved off a sub-tree of the DNS
namespace in which the modified name treatment rules apply", but
single label names are already special anyway.
Well, all special names are specified in RFC 6761 and associated registry.

What RFC says that single-label names are 'special'?
In what sense 'special'?
How do you differentiate arbitrary 'single-label' from TLD in DNS?

Answers to these questions need backing from standards because all parties
doing name resolution need to do it consistently.
Post by Zbigniew Jędrzejewski-Szmek
Post by Jan Pokorný
(also filed https://bugzilla.redhat.com/show_bug.cgi?id=975856)
This is one of the problems that myhostname solves.
Zbigniew Jędrzejewski-Szmek
2016-02-03 16:44:15 UTC
Permalink
Sorry to reply with such a delay.
Post by Andrew Lutomirski
I also think that the whole gethostname(2) mechanism is terminally
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.
Like discussed elsewhere in the thread, this is used by DDNS, which is
very useful in closed environments. It is also useful for diagnostics:
if I look on the router what leases were made, it's much nicer to see
the names rather than just the MAC addresses. The hostname is
something that essentially is used to identify a machine for humans,
and not allowing the hostname to be visible defeats the purpose.

Not sending the hostname in DHCP requests on non-trusted networks was
discussed in the other part of the thread. It's a great idea, but not
really relevant to this discussion, since DHCP libraries already make
this configurable (e.g. SendHostname=, Hostname= settings described in
systemd.network(5)). The issue is knowing when to set it on and when
to off, but this is needs to be solved at a slightly higher level.
Post by Andrew Lutomirski
3. Some programs seem to thing that gethostbyname(gethostname())
should return some reasonable concept of "my ip address" despite the
general nonexistence of such a concept.
- gethostname(2) always returns "localhost".
So you are proposing to make the current hostname mechanism useless
and add a replacement mechanism. I don't get the point, if this
got implemented we would be in the same place a few years down the
road. If the point is to avoid DHCP sending out the hostname, this can
already be achieved with a simple config change.
Post by Andrew Lutomirski
- "localhost" always resolves to 127.0.0.1 or ::1
That's what nss-myhostname provides.
Post by Andrew Lutomirski
- bash learns to use some intelligent value derived from whatever
hostnamectl would return
I think bash is fine now: is shows gethostname(), which defaults
to contents of /etc/hostname.
Post by Andrew Lutomirski
- the default DHCP clients send a client identifier that's a function
only of the MAC address used to send the query
It's better not to send anything if not desired as discussed above.
DHCP servers don't use this to generate leases, so there's little
point in sending a random value.
Post by Andrew Lutomirski
- Whatever systemd magic special-cases "localhost" as "trust what
DHCP says" goes away.
No, systemd doesn't do that. First, nss-myhostname resolves
localhost statically to 127.0.0.1. Second, sd-dhcp refuses 'localhost'
as the lease name.

Systemd will use the DHCP provided "transient" name, but only if the
"static" name (from /etc/hostname is not set). The "transient" name
is a fallback value only.
Post by Andrew Lutomirski
This trivially solves one silly annoyance: when I install Fedora, why
on Earth is "what's your hostname" a reasonable question to ask me?
Because all installations of Fedora are similar and a 16 byte UUID
is not something that most humans can remember.
Post by Andrew Lutomirski
Servers may have their own considerations, and NetworkManager and/or
networkd could consider having a client-id override.
(They do.)
Post by Andrew Lutomirski
If people really want to force a non-"localhost" hostname on a server,
then forcing it to resolve to something intelligent might make sense,
as having everything fail when resolution times out or ends up with
SERVFAIL or NXDOMAIN is nasty. But when I force my hostname to
"foo.corp.bar.com", I probably have something other than 127.0.0.1 in
mind.
This is something to be discussed, certainly. We already ask for a
user name, so it might be nice to simply to default to a hostname
generated from that, and the automatically detected chassis type (user
'Mikey' → login 'mikey' → pretty hostname "Mikey's Laptop" → hostname
"mikeys-laptop"). This field should still be editable, but a sensible
default would work nicely. IIRC, this is what Windows does more or
less, and it is pretty intuitive. At least for Workstation.

Anaconda could say "This computer will be visible as "Mikey's Laptop"
in the local network." to make people aware that the name is visible.

Zbyszek
Andrew Lutomirski
2016-02-04 21:11:48 UTC
Permalink
On Wed, Feb 3, 2016 at 8:44 AM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
Sorry to reply with such a delay.
Post by Andrew Lutomirski
I also think that the whole gethostname(2) mechanism is terminally
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.
Like discussed elsewhere in the thread, this is used by DDNS, which is
if I look on the router what leases were made, it's much nicer to see
the names rather than just the MAC addresses. The hostname is
something that essentially is used to identify a machine for humans,
and not allowing the hostname to be visible defeats the purpose.
In my opinion, if I weight the privacy and tracking implications of
advertising my laptop's name to every network I connect to against the
minor convenience for network admins who like to read the leases file,
I think the privacy implication is so much more important that it's
silly to even consider the human-readable leases file at all.
Post by Zbigniew Jędrzejewski-Szmek
Not sending the hostname in DHCP requests on non-trusted networks was
discussed in the other part of the thread. It's a great idea, but not
really relevant to this discussion, since DHCP libraries already make
this configurable (e.g. SendHostname=, Hostname= settings described in
systemd.network(5)). The issue is knowing when to set it on and when
to off, but this is needs to be solved at a slightly higher level.
Post by Andrew Lutomirski
3. Some programs seem to thing that gethostbyname(gethostname())
should return some reasonable concept of "my ip address" despite the
general nonexistence of such a concept.
- gethostname(2) always returns "localhost".
So you are proposing to make the current hostname mechanism useless
and add a replacement mechanism. I don't get the point, if this
got implemented we would be in the same place a few years down the
road. If the point is to avoid DHCP sending out the hostname, this can
already be achieved with a simple config change.
The current situation seems to be worse than useless in a lot of
cases. I've literally never had it do anything useful except show up
in a bash prompt, whereas it's caused services to break for me due to
DNS resolution issues on many, many occasions.
Post by Zbigniew Jędrzejewski-Szmek
Post by Andrew Lutomirski
- "localhost" always resolves to 127.0.0.1 or ::1
That's what nss-myhostname provides.
It's part of what nss-myhostname provides. There's clearly no
consensus on the "gateway" feature.
Post by Zbigniew Jędrzejewski-Szmek
Post by Andrew Lutomirski
- the default DHCP clients send a client identifier that's a function
only of the MAC address used to send the query
It's better not to send anything if not desired as discussed above.
DHCP servers don't use this to generate leases, so there's little
point in sending a random value.
It's more of a compatibility thought. Do servers in the wild work if
the client id is missing entirely or if there are duplicates on the
same network? Hopefully they do, but I don't know that.
Post by Zbigniew Jędrzejewski-Szmek
Post by Andrew Lutomirski
- Whatever systemd magic special-cases "localhost" as "trust what
DHCP says" goes away.
No, systemd doesn't do that. First, nss-myhostname resolves
localhost statically to 127.0.0.1. Second, sd-dhcp refuses 'localhost'
as the lease name.
Something causes bash to show garbage that came from DHCP if I set
/etc/hostname to localhost. I don't know what it is. I've seen this
on a totally stock Fedora 23 system.
Post by Zbigniew Jędrzejewski-Szmek
Systemd will use the DHCP provided "transient" name, but only if the
"static" name (from /etc/hostname is not set). The "transient" name
is a fallback value only.
This is probably what I meant above. It caused a good deal of
confusion and it didn't improve anything for me. What's the point?
Post by Zbigniew Jędrzejewski-Szmek
Post by Andrew Lutomirski
This trivially solves one silly annoyance: when I install Fedora, why
on Earth is "what's your hostname" a reasonable question to ask me?
Because all installations of Fedora are similar and a 16 byte UUID
is not something that most humans can remember.
OK, but this doesn't answer the question at all. Pretend I'm a
regular computer user. Why am I supposed to name my computer? What's
in it for me?
Post by Zbigniew Jędrzejewski-Szmek
Post by Andrew Lutomirski
Servers may have their own considerations, and NetworkManager and/or
networkd could consider having a client-id override.
(They do.)
Post by Andrew Lutomirski
If people really want to force a non-"localhost" hostname on a server,
then forcing it to resolve to something intelligent might make sense,
as having everything fail when resolution times out or ends up with
SERVFAIL or NXDOMAIN is nasty. But when I force my hostname to
"foo.corp.bar.com", I probably have something other than 127.0.0.1 in
mind.
This is something to be discussed, certainly. We already ask for a
user name, so it might be nice to simply to default to a hostname
generated from that, and the automatically detected chassis type (user
'Mikey' → login 'mikey' → pretty hostname "Mikey's Laptop" → hostname
"mikeys-laptop"). This field should still be editable, but a sensible
default would work nicely. IIRC, this is what Windows does more or
less, and it is pretty intuitive. At least for Workstation.
Anaconda could say "This computer will be visible as "Mikey's Laptop"
in the local network." to make people aware that the name is visible.
Then Anaconda could offer a checkbox "don't do that" because if I'm a
normal person on a laptop, why the @*!& would I want my laptop to
advertise my pet name for it to the world?

--Andy
Zbigniew Jędrzejewski-Szmek
2016-02-05 02:44:10 UTC
Permalink
Post by Andrew Lutomirski
On Wed, Feb 3, 2016 at 8:44 AM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
Sorry to reply with such a delay.
Post by Andrew Lutomirski
I also think that the whole gethostname(2) mechanism is terminally
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.
Like discussed elsewhere in the thread, this is used by DDNS, which is
if I look on the router what leases were made, it's much nicer to see
the names rather than just the MAC addresses. The hostname is
something that essentially is used to identify a machine for humans,
and not allowing the hostname to be visible defeats the purpose.
In my opinion, if I weight the privacy and tracking implications of
advertising my laptop's name to every network I connect to against the
minor convenience for network admins who like to read the leases file,
I think the privacy implication is so much more important that it's
silly to even consider the human-readable leases file at all.
It's not just network admins. The primary use case is users connecting
to a different machine in the local network.
Post by Andrew Lutomirski
Post by Zbigniew Jędrzejewski-Szmek
Not sending the hostname in DHCP requests on non-trusted networks was
discussed in the other part of the thread. It's a great idea, but not
really relevant to this discussion, since DHCP libraries already make
this configurable (e.g. SendHostname=, Hostname= settings described in
systemd.network(5)). The issue is knowing when to set it on and when
to off, but this is needs to be solved at a slightly higher level.
Post by Andrew Lutomirski
3. Some programs seem to thing that gethostbyname(gethostname())
should return some reasonable concept of "my ip address" despite the
general nonexistence of such a concept.
- gethostname(2) always returns "localhost".
So you are proposing to make the current hostname mechanism useless
and add a replacement mechanism. I don't get the point, if this
got implemented we would be in the same place a few years down the
road. If the point is to avoid DHCP sending out the hostname, this can
already be achieved with a simple config change.
The current situation seems to be worse than useless in a lot of
cases. I've literally never had it do anything useful except show up
in a bash prompt, whereas it's caused services to break for me due to
DNS resolution issues on many, many occasions.
Sounds like a bug. Can you provide some details?
Post by Andrew Lutomirski
Post by Zbigniew Jędrzejewski-Szmek
Post by Andrew Lutomirski
- the default DHCP clients send a client identifier that's a function
only of the MAC address used to send the query
It's better not to send anything if not desired as discussed above.
DHCP servers don't use this to generate leases, so there's little
point in sending a random value.
It's more of a compatibility thought. Do servers in the wild work if
the client id is missing entirely or if there are duplicates on the
same network? Hopefully they do, but I don't know that.
Yeah, they seem to work fine.
Post by Andrew Lutomirski
Post by Zbigniew Jędrzejewski-Szmek
Post by Andrew Lutomirski
- Whatever systemd magic special-cases "localhost" as "trust what
DHCP says" goes away.
No, systemd doesn't do that. First, nss-myhostname resolves
localhost statically to 127.0.0.1. Second, sd-dhcp refuses 'localhost'
as the lease name.
Something causes bash to show garbage that came from DHCP if I set
/etc/hostname to localhost. I don't know what it is. I've seen this
on a totally stock Fedora 23 system.
Yes, if the hostname is localhost, the transient hostname from DHCP is
used. I think I now understand what you meant in the previous mail.
Just set the hostname to anything except localhost.
Post by Andrew Lutomirski
Post by Zbigniew Jędrzejewski-Szmek
Systemd will use the DHCP provided "transient" name, but only if the
"static" name (from /etc/hostname is not set). The "transient" name
is a fallback value only.
This is probably what I meant above. It caused a good deal of
confusion and it didn't improve anything for me. What's the point?
To make it easy to have machines configured over DHCP that have no local
state (e.g. public terminals at unirsity booted over the network).
Post by Andrew Lutomirski
Post by Zbigniew Jędrzejewski-Szmek
Post by Andrew Lutomirski
This trivially solves one silly annoyance: when I install Fedora, why
on Earth is "what's your hostname" a reasonable question to ask me?
Because all installations of Fedora are similar and a 16 byte UUID
is not something that most humans can remember.
OK, but this doesn't answer the question at all. Pretend I'm a
regular computer user. Why am I supposed to name my computer? What's
in it for me?
Post by Zbigniew Jędrzejewski-Szmek
Post by Andrew Lutomirski
Servers may have their own considerations, and NetworkManager and/or
networkd could consider having a client-id override.
(They do.)
Post by Andrew Lutomirski
If people really want to force a non-"localhost" hostname on a server,
then forcing it to resolve to something intelligent might make sense,
as having everything fail when resolution times out or ends up with
SERVFAIL or NXDOMAIN is nasty. But when I force my hostname to
"foo.corp.bar.com", I probably have something other than 127.0.0.1 in
mind.
This is something to be discussed, certainly. We already ask for a
user name, so it might be nice to simply to default to a hostname
generated from that, and the automatically detected chassis type (user
'Mikey' → login 'mikey' → pretty hostname "Mikey's Laptop" → hostname
"mikeys-laptop"). This field should still be editable, but a sensible
default would work nicely. IIRC, this is what Windows does more or
less, and it is pretty intuitive. At least for Workstation.
Anaconda could say "This computer will be visible as "Mikey's Laptop"
in the local network." to make people aware that the name is visible.
Then Anaconda could offer a checkbox "don't do that" because if I'm a
advertise my pet name for it to the world?
Well, if you want to call your machine something personal, that's your
choice. Something less private like "new laptop", "dell", "thinkpad",
"desktop" or even "machine12" work just as well. The idea is that
if you are on SOHO network, it is easy to identify your machines.

Zbyszek
Glen Turner
2016-02-08 08:15:23 UTC
Permalink
Post by Andrew Lutomirski
It's part of what nss-myhostname provides. There's clearly no
consensus on the "gateway" feature.
The belief of operating systems' programmers that a lack of a default
gateway must imply no network connectivity constricts useful network
designs.

My objection to the "gateway" name is simply that "ping gateway" gives
applications another way to test this incorrect belief.

-glen

Petr Spacek
2016-01-26 07:58:27 UTC
Permalink
Post by Lennart Poettering
Post by Florian Weimer
Post by Lennart Poettering
Post by Florian Weimer
Post by Zbigniew Jędrzejewski-Szmek
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.
Post by Florian Weimer
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).
Post by Florian Weimer
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".
I disagree with your disagreement. We have only 1 shared namespace for this
world, and like it or not, the root zone (and thus all single-label names in
it) is managed by ICANN.

Fritzbox already did the mistake and used "box." as fake TLD for their
"gateways", and this is going to cause trouble because Amazon bought box. TLD [1].

"gateway." (as any other single-label name) can face the same faith one day,
when somebody decides to spend $$$ and buy it. Training anyone to rely on
"gateway" or any other single-label name is a bad idea.

"gateway.local." is okay, because RFC 6762 reserved "local." for this purpose.

However, I agree with you that 'search' mechanism is broken by design. Still,
disabling the search mechanism does not make use of single-label names safe or
even reliable.

So, please, do not push "gateway." or any other single-label name forward. It
will cause trouble sooner or later.

[1]
https://gtldresult.icann.org/application-result/applicationstatus/applicationdetails/990
--
Petr Spacek @ Red Hat
Florian Weimer
2016-01-26 09:41:00 UTC
Permalink
Post by Petr Spacek
So, please, do not push "gateway." or any other single-label name forward. It
will cause trouble sooner or later.
I think “_gateway” or “gateway_” would work, despite being a single
label. We could give this one priority over DNS, even.

Florian
Lennart Poettering
2016-01-26 11:45:18 UTC
Permalink
Post by Petr Spacek
I disagree with your disagreement. We have only 1 shared namespace for this
world, and like it or not, the root zone (and thus all single-label names in
it) is managed by ICANN.
Well, did you actually read the earlier discussions in this thread?

Again: it is well-known that single-label (aka "dotless domains") are
supposed to be interpreted in a local context, using domain search
paths, LLMNR and other local configuration. This is widely documented
by various Internet bodies, for example here:

https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/

We only synthesize an address for the single-label name "gateway", not
for the whole domain, or stuff below it. We do not synthesize anything
for names with multiple dots, thus we are not in conflict with
documented Internet specifications, we simply locally define one of
those single-label names, fully in line with what the specs suggest.
Post by Petr Spacek
Fritzbox already did the mistake and used "box." as fake TLD for their
"gateways", and this is going to cause trouble because Amazon bought box. TLD [1].
Firstly, it's a very different case, because the fritzbox does not
touch any single-label name! The zone they fake (and where the first
address RRs are located) is actually "fritz.box", and not "box". In
fact, they fake exactly nothing, not even a SOA RR for "box".

(The fact that they did it this way actually buys them a
get-out-of-jail-free-card for the DNSSEC situation: as long as they
buy the fritz.box domain as soon as .box is delegated one day, they
can simply leave it unsigned, and then their routers can continue to
do what they want with it... But that's very much unrelated to the
discussion around single-label names here.)

(Also, as a matter of fact, not that it would matter much: you'll see
that the Amazon application has been withdrawn, just scroll down on
that page.)
Post by Petr Spacek
"gateway." (as any other single-label name) can face the same faith one day,
when somebody decides to spend $$$ and buy it. Training anyone to rely on
"gateway" or any other single-label name is a bad idea.
Nope. because IAB and ICANN and others made clear that single-label
domains are supposed to be resolved in local context, and gateway
hence is local.
Post by Petr Spacek
agateway.local." is okay, because RFC 6762 reserved "local." for
this purpose.
Nope! .local is the TLD for MulticastDNS, nothing else.

AFAICS not a single claim in your mail is correct...

Lennart
--
Lennart Poettering, Red Hat
Florian Weimer
2016-01-26 12:07:59 UTC
Permalink
Post by Lennart Poettering
Post by Petr Spacek
I disagree with your disagreement. We have only 1 shared namespace for this
world, and like it or not, the root zone (and thus all single-label names in
it) is managed by ICANN.
Well, did you actually read the earlier discussions in this thread?
Again: it is well-known that single-label (aka "dotless domains") are
supposed to be interpreted in a local context, using domain search
paths, LLMNR and other local configuration.
This is irrelevant for the concerns Petr and others have voiced.

You cannot use priorities to resolve namespace collisions. The
collision still exists with the low-priority synthesized “gateway” name
we have today. The name is not a stable reference to the address of the
default gateway because of its low priority. This makes it unreliable,
difficult to use, and unsuitable for documentation and other user
guidance. Changing it to something that does not collide with names in
the DNS namespace (such as “_gateway”) would change that because we
could give it higher priority and make sure that it is a stable name for
the gateway addresses.

Florian
Lennart Poettering
2016-01-25 14:19:21 UTC
Permalink
Post by Florian Weimer
Post by Orion Poplawski
PS - There is some other discussion around "mymachines" which seems much more
problematic. I'd like to just focus on myhostname for now. The glibc
maintainer has indicated that he wants to wait for mymachines to be resolved,
but it's almost two months now and I don't see that being resolved soon.
I still have philosophical objects to myhostname as well. I find it odd
that at one end, we struggle with DNS name space hijacking, but on
<https://github.com/systemd/systemd/issues/2026>
The order in nsswitch.conf does not matter (and neither does any non-DNS
name resolution mechanism) because if we end up having software which
expects that “gateway” resolves to the IP address of the default
gateway, we still have an interoperability problem. And if “gateway” is
never intended for name resolution, why synthesize the name at all?
nss-myhostname and systemd-resolved map the "gateway" name to the
addresses of the locally configured default routing gateway. Note that
we only do this for the single-label "gateway". A such it might
conflict with LLMNR names (which are all single-label names) as well
as search domain lists (which are generally applied to single-label
names), but generally not with classic DNS fqdns. This is because
A/AAAA RRs are generally not assigned to TLDs, and while that's not a
strict requirement (and in fact there are some TLDs which have A/AAAA
RRs, such as .dk), this is strongly recommended against by many
internet organizational bodies, including ICANN and IAB:

https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-08-13-en
https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/

They recommend against allowing TLDs with address RRs specifically
because they conflict with local uses of single-label domains, in the
contexts of search lists and systems such as LLMNR.

Now, with that background, which clearly suggests that single-label
names are subject to *local* interpretation, nss-myhostnames resolves
"gateway" locally to the locally configured gateway, and I believe
that's completely within the idea and general accepted logic of
single-label domains. Now, you can argue this might create conflicts
with search domain logic and LLMNR, but well, the basic idea of
LLMNR/search lists is that it is non-organized, that it creates a very
local view of the worrld and subject to first-come-first-serve
conflicts.

Lennart
--
Lennart Poettering, Red Hat
Stephen Gallagher
2016-01-25 14:29:21 UTC
Permalink
Post by Florian Weimer
Post by Orion Poplawski
PS - There is some other discussion around "mymachines" which seems much
more problematic. I'd like to just focus on myhostname for now. The
glibc maintainer has indicated that he wants to wait for mymachines to be
resolved, but it's almost two months now and I don't see that being
resolved soon.
I still have philosophical objects to myhostname as well. I find it odd
that at one end, we struggle with DNS name space hijacking, but on another
<https://github.com/systemd/systemd/issues/2026>
The order in nsswitch.conf does not matter (and neither does any non-DNS
name resolution mechanism) because if we end up having software which
expects that “gateway” resolves to the IP address of the default gateway,
we still have an interoperability problem. And if “gateway” is never
intended for name resolution, why synthesize the name at all?
For what it's worth, nss_myhostname is extremely valuable even without
"gateway". Having the the machine's hostname automatically resolving even to
DHCP-assigned addresses solves a lot of issues, including some extremely
common ones related to FreeIPA installation.

So if nothing else, I'd really like to see this feature back to being
installed by default.
Loading...