On Thu, 04 Jul 2019 11:16:00 +0930
Tim via users <users(a)lists.fedoraproject.org> wrote:
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
$ 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
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.
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.
Yeah, businesses seem to like that.
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 suspect that is what the router is doing. Or the ISP upstream is
monitoring traffic, and blocking inbound port 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).
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.
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.
That doesn't sound like my system, since I get assigned a dhcp address
by the router.
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.
It doesn't support IPv6. But given the dig failure above, I probably
won't be running a server. I have it disabled in the router, and in
the connection (well, ignore).
What assigns your machines their LAN IP addresses? A DHCP server in
your router, in a server PC, nothing? Do you manually set IPs?
DHCP in the router.
What IP range does your LAN use? 192.168.x.y 10.x.y.z 168.254.x.y
I'm in the 192.168.x.y category.