All of a sudden the resolution of PTR records on the authoritative DNS server stopped working. Translations of other record types (A, MX, TXT, ..) work. The server is running Debian 10. BIND version: BIND 9.11.5-P4-5.1+deb10u3-Debian (Extended Support Version) I tested the scenario from several networks. I also tried resolving records as localhost. Some zones are not loaded with .err on end of the file name. Could there be a connection? These zones were there even before the PTR record translation problem occurred. But what I'm concerned about is correctly loaded zones. I'll give you an example: zone 3.3.2.1.in-addr.arpa Zone is loaded OK - checked with named-checkzone Zone configuration on named.conf.local: zone "3.2.1.in-addr.arpa" { type master; file "/etc/bind/pri.3.2.1.in-addr.arpa"; }; zone file: $TTL 3600 @ IN SOA server.domain.cz. support.domain.cz ( 2023031010 ; serial, todays date + todays serial # 16384 ; refresh, seconds 2048 ; retry, seconds 1048577 ; expire, seconds 2560 ) ; minimum, seconds ; @ 86400 NS server.domain.cz. 3.2.1.in-addr.arpa 3600 NS server.domain.cz. 3.2.1.in-addr.arpa 3600 NS server2.domain.cz. 4.3.2.1.in-addr.arpa 3600 PTR gw-01-79.domain.cz. I set myself (localhost) as DNS server nslookup search: set type=PTR 1.2.3.4 nslookup output: server can't find 4.3.2.1.in-addr.arpa: NXDOMAIN In some cases (with records in other reverse zones), the server responds: server can't find 130.64.83.80.in-addr.arpa: SERVFAIL I haven't found a reason why the answers differ. Could you help me solve the problem please? Best regards Jan Brodecky
Yes. Fix the errors first. I would use host command when testing the name server. Please post the listings in CODE tags. Are you sure the NS entries in zone file are correct? The syntax you used I have not seen. Perhaps the DNS and Bind Book by Albitz and Liu helps here.
PTR's are in the hands of your ISP (just like your IP's). I would ask if they have done any changes in their DNS/PTR management. I have run in to same problem with our (email servers) PTR records being changed on the fly away from our control. It's basically only issue when dealing with email servers and even with them it's usually no problem.
I would use dig to find the answer. Try: [email protected] -x 1.2.3.4 or something like: [email protected] www.server.com
