Stan: > $ dig example.com @1.1.1.1 > > ; <<>> DiG 9.11.8-RedHat-9.11.8-1.fc31 <<>> example.com @1.1.1.1 > ;; global options: +cmd > ;; connection timed out; no servers could be reached Tim: >> If that kind of thing fails, then you won't be able to run your own >> DNS server, there's something blocking necessary network traffic. > That explains the bind / named failure I'm seeing. You could test whether its your service provider or your router blocking that traffic. Set the router to use 8.8.8.8 as its DNS server, and see if it can still resolve names. Use the dig command with the @ portion set to the router's IP. Try and resolve a name it won't have an already cached answer for. If the router is the problem, look for its firewall settings. >> That's an odd hostname. [localhost.Home.localhost.Home] > I wonder if my thrashing around on this issue did something that is > somehow causing the change. I don't recall seeing it before. > > Jul 03 08:18:22 localhost.Home systemd-hostnamed[858]: Changed host name to 'localhost.Home' > Jul 03 08:18:22 localhost.localdomain systemd[1]: Started Hostname Service. > Jul 03 08:18:21 localhost.localdomain NetworkManager[20472]: <info> [1562167101.6542] policy: set-hostname: set hostname to 'localhost.Home' (from address lookup) > > Definitely something I did. I should probably figure out what I did > and reverse it in case there are things that expect localdomain > instead of Home. On Linux, and elsewhere, most things expect localhost and 127.0.0.1 to resolve into each other in both directions. And they are the equivalent of the computer seeing itself in the mirror, and saying "me". The computer should resolve that without resorting to a DNS server, since it's in /etc/hosts (which is consulted first). But most DNS servers have an entry for localhost, for completeness's sake. The .localdomain suffix is a Linux oddity, and I know of nothing that needs it, nowadays. In the past, I'd noticed something like sendmail demanded at least one dot in the hostname. The .home suffix is often used by routers which provide DHCP, and sometimes an integrated DNS server (where it can resolve its doled out hostnames). It was/is quite common that routers will assign hostnames with DHCP, but provide no way for the names to be resolved. Other hostnames shouldn't horse around with localhost. In other words, set a unique hostname for the computers network IP, that doesn't use the word. Give services the hostname that other devices will find them at, not localhost (that name only applies to itself, all other devices will also think of themselves as localhost). e.g. /etc/hosts #IP name alternative names (aliases) 127.0.0.1 localhost localhost.localdomain 192.168.0.1 backup backup.lan backup.home backup.localdomain 192.168.0.2 filestore.home filestore Just giving multiple examples of how can be used. The first name after the IP is the one given if something checks for the hostname of an IP. The other names will also be associated with the IP. With a DNS server, the hosts file only needs to carry the 127.0.0.1 line, all other names and IPs would be resolved by the DNS server. >> Link-local addresses are not resolved by traditional DNS servers, on >> port 53. It uses multicast DNS (mdns) on a different port, such as >> 5353. It runs independently, and is not co-operative with >> traditional DNS. > That doesn't sound like my system, since I get assigned a dhcp > address by the router. Without testing, I couldn't say what scheme/schemes your router supports. So many things use it now, such as home network printers. If it's enabled in your computer, it can use all of these different schemes. And the first one to answer wins. So slow DHCP servers will be a problem. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
