Link to home
Start Free TrialLog in
Avatar of derrickonline
derrickonlineFlag for United States of America

asked on

Need Help Setting Up Reverse DNS (it was authority was delegated by ISP)

We manage our own DNS in house.  Reverse DNS has been tricky however because apparently Verizon (our T1 provider) didn't delegate authority to us initially.

We just had them delegate authority to us, but we have a /29.  Because we have a /29 apparently setting up a reverse DNS zone is different.

I'm having a hell of a time figuring out how to create a reverse DNS zone for a /29 using Microsoft Windows Server 2008 DNS.  

Can someone provide a walk-thru of creating a reverse DNS zone for a /29.  
Avatar of Chris Dent
Chris Dent
Flag of United Kingdom of Great Britain and Northern Ireland image

Have they told you the notation they've used to delegate?

Can you run:

nslookup -q=cname

Where should be replaced with an IP within your block.

I'd expect something like:


If that is the case, we need to create a zone called 3/ I think it'll let you in the GUI provided you force it to use a name rather than filling in the boxes for for an IP address. If it doesn't let you there we can probably do it with dnscmd instead.

Avatar of derrickonline


I'm getting this: 18542 IN      CNAME
Here's the information Verizon sent:


Our side is now ready per below. Also, below your reverse zone is an explanation of what you need to do to setup your side:

This request has now been completed. Please be advised that it may take up to one hour for propagation to begin, and up to 8 hours for FULL Internet propagation. Please review the reverse zone print listed below:

; allocated 152-159 to
152             IN      NS
152             IN      NS
153             IN      CNAME
154             IN      CNAME
155             IN      CNAME
156             IN      CNAME
157             IN      CNAME
158             IN      CNAME

Setting up classless in-addr files on your nameserver is slightly different than setting up a zone for an entire CIDR: /24 (255 IPs).

Here is an example using a hypothetical subnet,, or, the first 128 IPs in this CIDR: /24.
If you have 128 IP addresses in a particular block we would make the following entries into the CIDR: /24 zonefile on 'Verizon' servers:

0       IN      NS
0       IN      NS
1       IN      CNAME
2       IN      CNAME
3       IN      CNAME

This points all queries for the first 128 IP addresses to a zone on your nameserver called

The zonefile you create will look just like a normal zonefile (with PTR records etc.), only the zone file name will have a 4th octet noting the net address, or first IP in your subnet ......

Here is a sample of what your zonefile should look like:

1       IN      PTR
2       IN      PTR
3       IN      PTR

OR     IN      PTR     IN      PTR     IN      PTR

For more info on subnetted in-addr on an NT machine you can also see the

Microsoft website's white paper:

Windows GUI may not let you edit the named.boot file manually, so this might not apply to you.  If you are using BIND or a similar platform you

should put the following directive into your named.boot file:

primary       db.reversefilename
BIND  named.conf would look similar to:

zone "" {
        type master;
        file "";

For more information about Classless IN-ADDR.ARPA Delegation, please see RFC2317.

(please leave the ticket number in the subject field should you reply back to this email. This will allow your reply email to populate into this same ticket)

Thank you,
Verizon Technical Support
Toll-free: 1-800-900-0241

Avatar of Chris Dent
Chris Dent
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial

Depending on your network topology, don't be too surprised if you cannot resolve your own PTR records.

That is, any internal DNS service will attempt to reach your external DNS service via the delegation posted at Verizon.

You cannot simply create a forwarder in this scenario, your own server doesn't actually have answers for the real version of the PTR (, you only have the classless version and you'll only ever get that via the CNAME record hosted at Verizon.

But the impact there depends a lot on your topology so don't worry too much for now :)

Ok, so I have the zone created using your aforementioned command.  But when I go to create a PTR record, it shows:

So I try to delete 152 and replace it with the octet of the IP I'm trying to create a record for, it won't let me delete.

So according to your comments there should in fact be a fifth octet, so I try to add the last octet of the IP for which I'm trying to create a record for:   But then I get error invalid IP?  I'm confused.
Regarding your comment on our internal DNS.  We actually have our internal DNS answering for our actual domain using internal IP addresses.  We're also no too worried about reverse lookups internally.

The issue is we're hosting our own mail and spam filtering, we're being rejected at some mail gateways for not having a PTR record for our mail server.  I should have just asked Verizon to set one up, but I like to control everything.
Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
My last comment made no sense.  I was saying our internal clients hit our internal dns server.  If they want to resolve anything on our actual domain  (, it's done using the internal IP address.  Not the external.  
Ahh success!  Thank you!  I guess I can't add them via the GUI.  Per your instructions I also kept the trailing dots.  I did a reverse lookup and it finally worked properly!

You've been a wonderful help!  Thank you.
Thank you very much!

Yeah, that was the problem I was getting at.

You won't be able to tell it to use the internal IP for the PTR records as your server doesn't actually host a zone that can answer the base request.

For example, you can't run this against your public server and get an answer:

nslookup -q=ptr TheInternalIPAddress

It's not really a big problem, just don't be entirely surprised if it doesn't test successfully inside your network after all of this.

Got cha.  I've been doing all my testing externally to maintain my sanity.  Internal reverse lookups are less important for us.  But thank you for the heads up.