>> >>> 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".

Peter
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Reply via email to