I have problems with reverse lookup zone (i am new).

For exmaple my domain is (my REAL domain name is registered in domain registration service -Network Infomation Centre - nic and in nic there is a ns resource record - - my dns server ip and server name ).

My dns server 53 udp port is working and visible to internet.

My active directory domain name is

*
So, i have 2 zones....
-first zone
Forward lookup zone (stored in AD) -
Reverse lookup zone 1.

In this local zone are stored all lan pc, and this zone is not
forwarded to any servers (zone transfer is disabled).

- Now my goal is to create second zone (on same dns) TEST.COM,
but this zone
must be forwarded to any dns servers outside company, because
in this zone i store resource records like: A-www, MX, A-ftp

For this zone TEST.COM i created reverse lookup zone with
appropriate real ip.


When i test reverse lookup zone (inside organization) for with nslookup, i have normal answer - no error, nslookup can resolve by ip address.

But from outside online services give me an error, that i have no reverse lookup zone for

On reverse lookup zone () zone transfer is enabled to any servers).

Please , give some solution for newbie.

thanks.

Dani AI

Generated

— quick diagnosis and a practical path forward. The behavior described (internal nslookup works but public services report "no reverse lookup") almost always means the in-addr.arpa parent for the public IP is not delegated to the company DNS. PTR records for public IPs are controlled by the owner of the IP block (usually the ISP or hosting provider). Creating a reverse zone on the local Windows DNS does not make it authoritative on the Internet unless the parent in-addr.arpa points to it. is correct to stress coordination with the ISP for public A/MX records and port forwarding.

Concrete next steps (actionable and precise):

  1. Identify the public IP(s) that need PTRs (the WAN/NAT address(es)).
  2. Ask the ISP/host for one of these two options: either (A) set the PTR(s) on their reverse DNS to the desired hostname(s) (example: 203.0.113.5 -> mail.test.com), or (B) delegate the appropriate in-addr.arpa zone (or use RFC2317 classless delegation) to the company nameservers so the reverse zone served locally becomes authoritative. ISPs usually do (A) for single IPs and (B) only for full blocks (/24).
  3. Ensure the forward A record for the hostname exists and matches the IP used in the PTR (forward/reverse consistency is important for mail). Confirm port/protocol exposure: public UDP/TCP 53 must be reachable if the server is to be authoritative externally (and TCP 53 is needed for some queries and for AXFR).
  4. Lock down zone transfers: do not permit AXFR to "any" — restrict to known secondary DNS IPs.

Quick verification commands (run from any external host):

dig -x 203.0.113.5 +short
dig NS 113.0.203.in-addr.arpa +short
dig +trace -x 203.0.113.5

Example support-ticket text for the ISP:

Please set PTR for 203.0.113.5 to mail.test.com (and ensure the reverse resolves publicly).  Alternatively, delegate 113.0.203.in-addr.arpa to ns1.example.net / ns2.example.net (glue if needed).

Cautions and reminders: keep the private 192.168.* reverse zone internal only; do not publish private RFC1918 addresses. If the nameserver hostname lives inside test.com, ensure proper glue records are registered at the registrar and provide at least two public NS records for resilience.

You need to contact your ISP and get them to setup your MX records for your email server and A records for your webserver. These will point to your public address. Then on your firewall you will have to forward all port 80 traffic to your webserver's internal address and forward all SMTP traffic to your email server's address. You cannot publish private LAN addresses to the internet DNS servers.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.