My mistake. I see the first hop is my gateway.
This is the ncat output from a LAN computer:
nc -zv google.com 443
Ncat: Version 7.92 ( Ncat - Netcat for the 21st Century )
Ncat: Could not resolve hostname “google.com”: Name or service not known. QUITTING.
firewall-cmd --list-all
external (active)
target: default
icmp-block-inversion: no
interfaces: enp1s0
sources:
services: dns ssh
ports:
protocols:
forward: yes
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
firewall-cmd --zone=internal --list-all
internal (active)
target: default
icmp-block-inversion: no
interfaces: enp2s0
sources: 192.168.99.0/24
services: cockpit dhcpv6-client dns http https mdns nfs samba-client ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
systemctl status resolvd
Unit resolvd.service could not be found.
sudo systemctl status named
● named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; preset: disabled)
Active: active (running) since Sun 2026-03-29 18:23:10 PDT; 14min ago
Process: 1680 ExecStartPre=/bin/bash -c if [ ! “$DISABLE_ZONE_CHECKING” == “yes” ]; then /usr/sbin/named-checkconf -z “$NAMEDCONF”; else echo “Checking of zone files is disabled”>
Process: 1683 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 1684 (named)
Tasks: 10 (limit: 48180)
Memory: 36.5M (peak: 38.4M)
CPU: 216ms
CGroup: /system.slice/named.service
└─1684 /usr/sbin/named -u named -c /etc/named.conf
Mar 29 18:23:11 ipcop named[1684]: REFUSED unexpected RCODE resolving ‘./DNSKEY/IN’: 198.97.190.53#53
Mar 29 18:23:11 ipcop named[1684]: REFUSED unexpected RCODE resolving ‘./NS/IN’: 198.97.190.53#53
Mar 29 18:23:11 ipcop named[1684]: REFUSED unexpected RCODE resolving ‘./DNSKEY/IN’: 192.203.230.10#53
Mar 29 18:23:11 ipcop named[1684]: REFUSED unexpected RCODE resolving ‘./NS/IN’: 192.203.230.10#53
Mar 29 18:23:11 ipcop named[1684]: REFUSED unexpected RCODE resolving ‘./DNSKEY/IN’: 170.247.170.2#53
Mar 29 18:23:11 ipcop named[1684]: REFUSED unexpected RCODE resolving ‘./NS/IN’: 170.247.170.2#53
Mar 29 18:23:11 ipcop named[1684]: REFUSED unexpected RCODE resolving ‘./DNSKEY/IN’: 192.5.5.241#53
Mar 29 18:23:11 ipcop named[1684]: managed-keys-zone: Unable to fetch DNSKEY set ‘.’: failure
Mar 29 18:23:11 ipcop named[1684]: REFUSED unexpected RCODE resolving ‘./NS/IN’: 192.5.5.241#53
Mar 29 18:23:11 ipcop named[1684]: resolver priming query complete
That shows an issue with name resolution.
A server with IP address 8.8.8.8 does exist and should respond to ping:
ping -c 1 8.8.8.8
If you run that on the router and get no reply, then your ISP blocks it.
If router gets reply, but LAN computer does not, then router does not route.
If LAN computer gets a reply, then router config is ok.
Check these first.
For the name resolution, the LAN computers must have address(es) of DNS server(s).
- One could use some “known” server. For example, the 8.8.8.8 is Google’s DNS server?
- One could run
nmclion the router, and copy server address(es) from the “DNS configuration” section - One could set up a caching DNS server on the router. If done, then clients use 192.168.99.1 as DNS server
The ‘named’ is a full-blown DNS server. It is probably easier to set up ’ dnsmasq’.
The `masquerade: no` in your `internal-external` policy is the root cause. Masquerade is what performs NAT — without it your LAN computers’ packets go out with their 192.168.99.x source addresses which the internet simply drops.
Fix:
```
firewall-cmd --policy=internal-external --add-masquerade --permanent
firewall-cmd --reload
```
Then verify IP forwarding is on: `sysctl net.ipv4.ip_forward` should return 1. If it shows 0, add `net.ipv4.ip_forward=1` to `/etc/sysctl.d/99-router.conf` and run `sysctl --system`.
The “Name or service not known” from post 39 is a separate DNS issue — your LAN computers need a DNS server configured. Either point them at the T-Mobile gateway (192.168.12.1 if it serves DNS) or use 8.8.8.8 or 1.1.1.1. Check `/etc/resolv.conf` or the static NM connection on each LAN machine.
Your routing table in post 37 looks correct and the traceroute confirms the router itself reaches the internet fine — once masquerade is on, forwarded traffic from the LAN should follow.
I added masquerade ti the policy “internal-external”:
firewall-cmd --list-all-policies
allow-host-ipv6 (active)
priority: -15000
target: CONTINUE
ingress-zones: ANY
egress-zones: HOST
services:
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family=“ipv6” icmp-type name=“neighbour-advertisement” accept
rule family=“ipv6” icmp-type name=“neighbour-solicitation” accept
rule family=“ipv6” icmp-type name=“router-advertisement” accept
rule family=“ipv6” icmp-type name=“redirect” accept
rule family=“ipv6” icmp-type name=“mld-listener-done” accept
rule family=“ipv6” icmp-type name=“mld-listener-query” accept
rule family=“ipv6” icmp-type name=“mld-listener-report” accept
rule family=“ipv6” icmp-type name=“mld2-listener-report” accept
internal-external (active)
priority: -1
target: ACCEPT
ingress-zones: internal
egress-zones: external
services:
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
When I had dnsmasq installed itgave me a number of problems so i removed dnsmasq and installed isc-dhcp and bind9. I agree that the issue seems to be with name resolution. From the LAN computers I can ping 8.8.8.8 but not google.com. when I check the status of named this is what I get:
systemctl status named
● named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset: disabled)
Active: active (running) since Mon 2026-03-30 13:29:21 PDT; 2s ago
Process: 1754 ExecStartPre=/bin/bash -c if [ ! “$DISABLE_ZONE_CHECKING” == “yes” ]; then /usr/sbin/named-checkconf -z “$NAMEDCONF”; else echo “Checking of zone files is disabled”>
Process: 1757 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 1758 (named)
Tasks: 8 (limit: 48180)
Memory: 32.5M (peak: 33.3M)
CPU: 189ms
CGroup: /system.slice/named.service
└─1758 /usr/sbin/named -u named -c /etc/named.conf
Mar 30 13:29:21 ipcop named[1758]: REFUSED unexpected RCODE resolving ‘./DNSKEY/IN’: 192.58.128.30#53
Mar 30 13:29:21 ipcop named[1758]: REFUSED unexpected RCODE resolving ‘./NS/IN’: 192.58.128.30#53
Mar 30 13:29:22 ipcop named[1758]: REFUSED unexpected RCODE resolving ‘./DNSKEY/IN’: 192.112.36.4#53
Mar 30 13:29:22 ipcop named[1758]: REFUSED unexpected RCODE resolving ‘./NS/IN’: 192.112.36.4#53
Mar 30 13:29:22 ipcop named[1758]: REFUSED unexpected RCODE resolving ‘./DNSKEY/IN’: 170.247.170.2#53
Mar 30 13:29:22 ipcop named[1758]: REFUSED unexpected RCODE resolving ‘./NS/IN’: 170.247.170.2#53
Mar 30 13:29:22 ipcop named[1758]: REFUSED unexpected RCODE resolving ‘./DNSKEY/IN’: 199.7.83.42#53
Mar 30 13:29:22 ipcop named[1758]: managed-keys-zone: Unable to fetch DNSKEY set ‘.’: failure
Mar 30 13:29:22 ipcop named[1758]: REFUSED unexpected RCODE resolving ‘./NS/IN’: 199.7.83.42#53
Mar 30 13:29:22 ipcop named[1758]: resolver priming query complete
If everything else is working and you have given all of your local network computers a static address then you don’t need to play around with dns at all if you don’t want to.
Tell your computers that their dns server is 8.8.8.8 (or whatever you want it to be) and call it done.
When I run named-checkconf the results are puzzling. named-checkconf -t /var/named/ /etc/named.conf
open: /etc/named.conf: file not found
The file /etc/named.conf is definitely there.
I have a wireless AP that is part of my LAN. There are, on occasion, guests who use my internet and they log on to the WIFI and are assigned an ip address through dhcp. So, I need dns.
Actually no. You don’t need dns. You need dhcp, which you can use to assign an external dns server address (like 8.8.8.8) to the dhcp clients.
So, I can remove bind and just have dhcp? Should I use isc-dhcp or just use the dhcp part of dnsmasq?
I have removed bind and I checked and dnsmasq is not installed. The LAN computers can ping 8.8.8.8 but not google.com.
Each LAN computer should have one or more DNS server addresses listed in its config.
Do they have any? If they do, then which servers?
Well, that did it. Providing a dns address on the hosts on mt LAN did the trick. BUT, this begs the question: Why isn’t my firewall/router providing the dns info?
It doesn’t beg any question, though it does raise one.
The answer is simple: If you’re using dynamic ip addresses, then you didn’t configure your dhcp server to do that.
If you’re using static addresses then that’s the way it works. You have to provide the network address, mask and the dns server address(es) in the network configuration.
I agree with @FrankCox a tiny bit.
Preface:
When we use a name, our machine has to resolve it into address, because it needs address of destination to send (almost) anything. DNS is the normal method to resolve addresses. In it our machine sends a query to DNS server. The DNS server is a service that runs on some computer and handles DNS queries. A query like: “What is address of name?”. Our machine naturally needs the address of DNS server in order to send the query.
To me that did initially read:
Why isn’t 192.168.99.1 replying to DNS queries?
If so, then that is not about how the LAN machine is configured to send DNS queries to 192.168.99.1,
but a question:
Why does 192.168.99.1 not have DNS service running?
For that we do have an answer:
That is, no DNS service has been installed nor configured in the router.
Looking at what I wrote above, I see an another interpretation for the:
Maybe that really asks:
Why does the DHCP in the router not provide any/correct DNS server address for the clients?
Like @FrankCox wrote, the DHCP service has to be configured to send an appropriate DNS server address along the other configuration data.
As I wrote earlier, I do use ‘dnsmasq’ for DHCP and DNS.
However, I keep the dnsmasq.service disabled. I let NetworkManager do the work.
I have in /etc/NetworkManager/conf.d/00-dns.conf:
[main]
dns=dnsmasq
When the NetworkManager starts, it starts also a dnsmasq process to background, configured as caching relay, and configures the machine to send DNS queries to the dnsmasq. The dnsmasq does then forward the queries to the DNS servers that ISP told us.
The default name resolution routine is in glibc library. The dnsmasq is a bit smarter than the default, but naturally has the cost of an additional process.
The above is DNS just for this machine. We can give it additional config to enable the DHCP.
Something like:
In file /etc/NetworkManager/dnsmasq.d/dnsmasq-dlrapp.conf:
domain-needed
bogus-priv
expand-hosts
domain=dlrapp,192.168.99.0/24,local
interface=enp2s0
listen-address=192.168.99.1
# DHCP pool setup
dhcp-range=192.168.99.100,192.168.99.240,24h
dhcp-option=option:router,192.168.99.1
# Static mappings
dhcp-host=52:54:00:01:02:03,192.168.99.2
The dnsmasq will automatically include dhcp-option=option:dns-server,192.168.99.1
In the above config
- if a machine has MAC address
52:54:00:01:02:03, then it will always get IP address192.168.99.2 - If MAC of machine is not in any ‘dhcp-host’, then it will get next unused address from range
192.168.99.100--192.168.99.240
The firewall has to allow LAN machines to talk with the dnsmasq in the router:
firewall-cmd --zone=internal --permanent --add-service=dns
firewall-cmd --reload
but that you do already have.
Note:
The sources: 192.168.99.0/24 is redundant.
The above config says that when a packet comes in:
- IF it has source address in
192.168.99.0/24(regardless of interface) THEN it is in zone internal - IF it came via interface
enp2s0THEN it is in zone internal
That means that if there were someone on the enp1s0 side with a address 192.168.99.x, then that too would be allowed what zone internal allows.
To get your Rocky Linux router handing out DNS to LAN clients automatically, the cleanest approach is dnsmasq acting as both DHCP server and DNS forwarder. Install it with dnf install dnsmasq, then add to /etc/dnsmasq.conf: interface=enp2s0 on its own line, then dhcp-range=192.168.99.50,192.168.99.200,12h and dhcp-option=6,192.168.99.1 - where 192.168.99.1 is your router’s LAN IP. Dnsmasq will then tell every DHCP client to use the router itself as DNS resolver, and it forwards those queries upstream automatically. Enable and start it with systemctl enable --now dnsmasq. Just make sure nothing else is running DHCP on that interface first.