I am currently encountering DNS configuration issues with bind9. I have installed bind9 and made the following adjustments to the configuration files:
In the "named.conf.options" file, I added a new access control list block for my trusted clients, like this:
acl "trusted" {
192.168.5.0/24;
localhost;
};
I also allowed specific properties in the "options" section, including recursion, allow-recursion, listen-on 192.168.5.3 (my DNS server), allow-transfer (none), and allow-query (trusted). Additionally, I added forwarders like this:
forwarders {
10.100.0.1;
10.100.0.2;
};
For the forward and reverse zones, I created two files and referenced them in the "named.conf.local".
zone "MyFQDN" {
type: master;
file "etc/bind/db.MyFQDN";
allow-transfer { 192.168.5.1; };
};
zone "5.168.192.in-addr.arpa" {
type: master;
file "/etc/bind/db.5.168.192";
allow-transfer { 192.168.5.1; };
};
My reverse zone file:
$TTL 604800
@ IN SOA MyFQDN admin.MyFQDN (
8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expired
604800 ) ; Negative Cache TTL
1 IN PTR ns2.MyFQDN ; 192.168.5.1
2 IN PTR ns2.MyFQDN ; 192.168.5.2
3 IN PTR ns2.MyFQDN ; 192.168.5.3
4 IN PTR ns2.MyFQDN ; 192.168.5.4
My forward zone file:
$TTL 604800
@ IN SOA MyFQDN admin.MyFQDN (
12 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expired
604800 ) ; Negative Cache TTL
@ IN NS ns1.MyFQDN
@ IN NS ns2.MyFQDN
@ IN MX 0 mail.MyFQDN
ns1 IN A 192.168.5.3
www IN A 192.168.5.2
MyFQDN IN MX 10 mail.MyFQDN
ns1.MyFQDN IN A 192.168.5.3
ns2.MyFQDN IN A 192.168.5.1
www.MyFQDN IN A 192.168.5.2
mail.MyFQDN IN A 192.168.5.4
I am currently experiencing a DNS resolution issue with my DNS server configuration using bind9. The specific problem is that DNS entries for various hostnames cannot be resolved correctly. Here's a breakdown of the issues and some additional details:
ns1 could not be resolved right on ns1: When attempting to resolve the hostname 'ns1' from the DNS server 'ns1,' the DNS resolution fails. This issue is impacting the local DNS server's ability to resolve its own hostname.
ns2 could not be resolved right on ns1: Similar to the first issue, when trying to resolve 'ns2' from the DNS server 'ns1,' the resolution fails. This issue suggests an internal DNS problem.
www could not be resolved right on ns1: The hostname 'www' is also unable to be resolved when queried on the local DNS server 'ns1.' This issue affects the ability to resolve common hostnames within the local network.
Reverse entry for ns1 could not be resolved right on ns1: When attempting to resolve the reverse DNS entry for 'ns1' from the local DNS server 'ns1,' the resolution fails. This problem may be indicative of a reverse DNS misconfiguration.
Reverse entry for ns2 could not be resolved right on ns1: Similar to the previous issue, the reverse DNS entry for 'ns2' is not being resolved correctly when queried on the local DNS server 'ns1.' This could point to reverse DNS issues within the network.
Reverse entry for www could not be resolved right on ns1: The reverse DNS entry for 'www' is also encountering resolution problems when queried from the local DNS server 'ns1.'
I have already reviewed my bind9 configuration files and verified the entries. However, despite my efforts, these DNS resolution issues persist, impacting the functionality of my DNS server. Any insights or guidance on resolving these issues would be greatly appreciated.
.dot and otherwise it is considered short-hand. Your obfuscation makes it impossible to say if you're usingns1.MyFQDNwithout a trailing.and which will be expanded tons1.MyFQDN.MyFQDN.or formatting the hostname correctly asns1.MyFQDN.- Second DNS testing tools expect you to test with a FQDN and don't automatically append your search domain(s) to queries i.e.dig @192.168.5.3 ns1should fail and result in a NXDOMAIN error wheredig @192.168.5.3 ns1.MyFQDN.should return the correctArecord192.168.5.3