Tim: >> This will query specific servers: >> dig example.com @1.1.1.1 stan: > When the first failed, skipped this. In what way did it fail? Using the dig tool will directly query DNS servers. So a test of "dig example.com @8.8.8.8", for example, will see if you can access an external DNS server. This test won't make use of any of your DNS servers, nor your ISPs, it'll directly query the DNS server at: 8.8.8.8 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. It's not unusual for an ISP to block access to other servers, forcing all queries through their own. That way they can control you. It wouldn't be impossible for a modem/router to intercept DNS queries and put them through their own server. That way your LAN would just work, even if not properly configured. But, you would get name resolution answers, not broken service. It acts like a transparent proxy. > I am seeing entries like this in the logs when the named dns server > is running and I try to resolve a name. 1.1.1.1 and 9.9.9.9 are the > forwarding dns servers. > > Jul 03 08:40:24 localhost.Home named[11573]: timed out resolving > 'localhost.Home.localhost.Home/A/IN': 1.1.1.1#53 > Jul 03 08:40:23 localhost.Home named[11573]: timed out resolving > 'localhost.Home.localhost.Home/A/IN': 9.9.9.9#53 That's an odd hostname. Traditionally 127.0.0.1 resolved to just "localhost", and (doing things its own way) Linux liked to add in an additional "localhost.localdomain" (which seemed to be more about having at least one dot in a faked fully-qualified domain name, than any other reason). If I recall correctly, the .home suffix is used by things using link- local automatic IP addressing. Where, in the absence of something (like a DHCP server) giving it an address, devices assign themselves their own IPs by randomly picking a 168.254.x.y address, and seeing if nothing else is apparently using it on the LAN (if something responds, it tries another random IP address). Thereafter, networking with other things on your LAN works by just putting out feelers, and seeing what responds (want to connect to <myothermachine> asks anything on the LAN to respond, rather than DNS resolving name to IP and trying that IP). 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. > And these, that look like ipv6 addresses, though I have it disabled. If your network/ISP doesn't support IPv6, then disable settings in your servers so they don't try to use it. It can really be a bottleneck if something thinks it can use IPv6, but the network doesn't support it. There's these long delays while it attempts. What assigns your machines their LAN IP addresses? A DHCP server in your router, in a server PC, nothing? Do you manually set IPs? What IP range does your LAN use? 192.168.x.y 10.x.y.z 168.254.x.y _______________________________________________ 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
