other subnet CANNOT resolve internal host name but can resovle internet host name

Peter Lam

New Member
Joined
May 11, 2023
Messages
3
Reaction score
0
Credits
39
Hi All,

I am new in linux. I have setup a Ubuntu with Bind service (192.168.1.100). We have 3 subnet in the network. 192.168.0.0/23, 192.168.33.0/24 and 192.168.88.0/24.

A DNS server was configured in 192.168.0.0/23 network, The client in 192.168.0.0/23 network can resolve Internet Host name and Internal host name without problem.

But in 192.168.33.0/24 and 192.168.88.0/24 netoworks. The clients can resolve the Internet Host name such www.google.com. But I cannot resolve the right IP for the internal host. When I try to resovle an internal host. It will return the IP 208.91.112.55. Whatever I have tried to resolve host name, it will resolve to this IP 208.91.211.55.

options file.png
local file.png
zone file.png
ping result from other subnet.png
 


I am new in linux. I have setup a Ubuntu with Bind service (192.168.1.100). We have 3 subnet in the network. 192.168.0.0/23, 192.168.33.0/24 and 192.168.88.0/24.

A DNS server was configured in 192.168.0.0/23 network, The client in 192.168.0.0/23 network can resolve Internet Host name and Internal host name without problem.

But in 192.168.33.0/24 and 192.168.88.0/24 netoworks. The clients can resolve the Internet Host name such www.google.com. But I cannot resolve the right IP for the internal host. When I try to resovle an internal host. It will return the IP 208.91.112.55. Whatever I have tried to resolve host name, it will resolve to this IP 208.91.211.55.


The reason the client can resolve in the 0.0. subnet, is because it's in the same subnet as the dns server.

First, what is your default gateway IP? Are you using three gateways?
Are you using dhcp, or static IPs on these hosts? How is the address of the dns server assigned to these clients?

Second, Do you have a router between these subnets?
The netmask/subnet does not overlap between these. You will need a router.

If you want to use 3 subnets without a router, you will need a netmask of /22 ( 255.255.252.0 )
These subnets will have to be contiguous. ( right next to each other numerically )
For example...

192.168.1.0/22
192.168.2.0/22
192.168.3.0/22

But you can't just arbitrarily just jump to say 192.168.88.0

88 is 87 subnets away from 1. Your netmask would have to account for that.
That would be a very large subnet with a lot of wasted space.

If you clients can resolve external domains ( google.com ) but not internal domains, that
almost certainly means your dns client is pointed to an external dns server.
 
The reason the client can resolve in the 0.0. subnet, is because it's in the same subnet as the dns server.

First, what is your default gateway IP? Are you using three gateways?
Are you using dhcp, or static IPs on these hosts? How is the address of the dns server assigned to these clients?

Second, Do you have a router between these subnets?
The netmask/subnet does not overlap between these. You will need a router.

If you want to use 3 subnets without a router, you will need a netmask of /22 ( 255.255.252.0 )
These subnets will have to be contiguous. ( right next to each other numerically )
For example...

192.168.1.0/22
192.168.2.0/22
192.168.3.0/22

But you can't just arbitrarily just jump to say 192.168.88.0

88 is 87 subnets away from 1. Your netmask would have to account for that.
That would be a very large subnet with a lot of wasted space.

If you clients can resolve external domains ( google.com ) but not internal domains, that
almost certainly means your dns client is pointed to an external dns server.
i have a Fortigate firewall for these 3 subnet. They have their own gateway 88.1, 33.1 and 1.1. The client are assigned IP from DHCP server with DNS server 192.168.1.100(Bind server). So all the client have the same DNS server 192.168.1.100.

I tried to stop the bind serivce and all the clients could not resolve external and internal host name. The meant the clients in other subnet also relied on the DNS server 192.168.1.100.
 
@dos2unix is very knowledgeable and I trust their responses. I am confused by their post above, where they talk about changing the subnet mask or routing to fix your DNS issues. dos2unix appears to have determined that the cause of your DNS problems are routing issues. I wonder whether that is true, or did I miss an important detail?

When I first read the description of the problem, I wondered whether the cause might be a DNS client or DNS server configuration issue, not routing.

-> Since stopping the bind service prevents DNS resolution for external names on all subnets, it appears to be a DNS server configuration issue.

-> I say that with a grain of salt, because the example external DNS queries in the original post are to ".localnet", which is not a valid internet top level domain. The IP address in the example (208.91.112.55) is publicly accessible from the internet, but "nasb.localnet" is not a valid domain name (FQDN).

Does any of this help?
 
@dos2unix is very knowledgeable and I trust their responses. I am confused by their post above, where they talk about changing the subnet mask or routing to fix your DNS issues. dos2unix appears to have determined that the cause of your DNS problems are routing issues. I wonder whether that is true, or did I miss an important detail?

When I first read the description of the problem, I wondered whether the cause might be a DNS client or DNS server configuration issue, not routing.

-> Since stopping the bind service prevents DNS resolution for external names on all subnets, it appears to be a DNS server configuration issue.

-> I say that with a grain of salt, because the example external DNS queries in the original post are to ".localnet", which is not a valid internet top level domain. The IP address in the example (208.91.112.55) is publicly accessible from the internet, but "nasb.localnet" is not a valid domain name (FQDN).

Does any of this help?
I also think it should be the the DNS issue instead of the routing problem. Cos no DNS queries will be done if I stop the Bind service.

But I don't understand the following:
"-> I say that with a grain of salt, because the example external DNS queries in the original post are to ".localnet", which is not a valid internet top level domain. The IP address in the example (208.91.112.55) is publicly accessible from the internet, but "nasb.localnet" is not a valid domain name (FQDN).
"
The other subnets can resolve all external DNS queries by using the Bind server192.168.1.100. But when they try to resolve the Internal host they will get the same IP 208.91.112.55. No matter what is the Internal host name, they will get the same IP address 208.91.112.55. I am wondering how can they get this IP 208.91.112.55.


And i have just tried to stop the recursion and changed the forwarder to be 127.0.0.1. So that Bind CANNOT do any external queries for all clients. After this the subnet cannot resolve the external DNS queries. It makes sense. But the other subnets still resolve all the Internal Host to be 208.91.112.55. It is weird. The 192.168.0.0/23 has no problem. Though it cannot resolve the External but it can resolve the Internal host name RIGHT
 
Last edited:
What I meant was that anything with a TLD of ".localnet" is not on the public internet. You did not provide any examples of lookups of true internet FQDNs like "google.com" or "www.linux.org".

The public address 208.91.112.55 is owned by Fortinet and appears to be some kind of shared server. There are many domain names that point to that IP address.

I looked at a few of the domains that point to the IP address 208.91.112.55. Here are a few examples: beenet.gov.in, bsiag.at, centralcarolinainteriors.com, ciratx.com, and many more.

When I open one of those domains in a browser window, it redirects to an HTTP (not HTTPS) webpage that says, "Web Page Blocked! You have tried to access a web page which belongs to a category that is blocked." You can see it for yourself - just type one of the names from the previous paragraph in your browser address bar.

I note that Fortinet is the company that makes your Fortigate firewall.

Everything here points to Fortinet and maybe that Fortigate firewall of yours. I wonder if your problems may be related to a firewall misconfiguration issue.

P.S. Humor:
While typing this post, the darned spell-check/auto-correct kept changing the words "Fortinet" and "Fortigate" into "Fortunate". Well, at least the spell check has a positive view of them. :)
 
I also think it should be the the DNS issue instead of the routing problem.

That could be the case. But if you can't ping the dns server, ( or at least get to it on port 53 )
The DNS isn't going to work. I was trying to start at the bottom.

1. Can you ping the dns server from all the clients?
2. Are the clients configured to use your internal DNS server?
 

Members online


Top