On 25.1.2016 17:39, Lennart Poettering wrote: > On Mon, 25.01.16 17:11, Florian Weimer (fweimer@xxxxxxxxxx) wrote: > >> On 01/25/2016 03:23 PM, Lennart Poettering wrote: >>> On Mon, 25.01.16 09:08, Florian Weimer (fweimer@xxxxxxxxxx) 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". 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
