Bug 1469221 - Fedora 26 does not default anymore to automatic inclusion of internal domain names when resolving network addresses
Fedora 26 does not default anymore to automatic inclusion of internal domain ...
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: iputils (Show other bugs)
26
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan Synacek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-10 12:40 EDT by Francesco Simula
Modified: 2017-07-25 13:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-25 13:32:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Francesco Simula 2017-07-10 12:40:28 EDT
Description of problem:
Upgrading a Fedora 25 machine to Fedora 26 popped up this very annoying problem; any command (for example 'ping' or 'ssh') targeting a network address fails to be resolved unless the address is completed with the domain name.

To be sure, I tried with freshly installed virtual machines in QEMU: a freshly installed Fedora 25 (and I'm quite sure that all previous Fedora's did the same) resolved network names without needing a trailing domain name, Fedora 26 does instead.

In both cases, no configuration was done to the network options; the DHCP and DNS servers correctly assign an address and a name to the machine, which has no problem accessing the internal and external network in any other way.

Is it a bug?
Is it a new default of some configuration option I'm unaware of?

Version-Release number of selected component (if applicable):
iputils-20161105-2.fc26.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Fresh, minimal Fedora 26 install with no user creation (only root) and no customization whatsoever
2. ping (or ssh) a known, existing address of your network
3. the address is not recognized unless you add the complete domain name

Actual results:
[fsimula@ottosette ~]$ ping ronin
ping: ronin: No address associated with hostname

[fsimula@ottosette ~]$ ping ronin.ape
PING ronin.ape (10.0.0.64) 56(84) bytes of data.
64 bytes from ronin.ape (10.0.0.64): icmp_seq=1 ttl=64 time=0.475 ms
64 bytes from ronin.ape (10.0.0.64): icmp_seq=2 ttl=64 time=0.505 ms
...

Expected results:
[fsimula@ottosette ~]$ ping ronin
PING ronin.ape (10.0.0.64) 56(84) bytes of data.
64 bytes from ronin.ape (10.0.0.64): icmp_seq=1 ttl=64 time=0.703 ms
64 bytes from ronin.ape (10.0.0.64): icmp_seq=2 ttl=64 time=0.636 ms
64 bytes from ronin.ape (10.0.0.64): icmp_seq=3 ttl=64 time=0.645 ms
...

Additional info:
The internal network obviously has a DNS and a DHCP server that are working correctly and have not been touched in any way during these trials.
Comment 1 Francesco Simula 2017-07-25 13:31:27 EDT
At the present time, I noticed that the problem (after a number of system updates and to the running kernel) has vanished; the 'ping' command does not need anymore the full domain name but just the hostname to reach the requested address.

Note You need to log in before you can comment on or make changes to this bug.