Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

guys. I have a problem I've run into with our DNS setup at my company. (I'm running BIND9 on a Linux platform, but this is not BIND-specific.)

I need to delegate a /24 reverse zone to another set of DNS servers outside of my control, using a set of statements like this:   IN   NS   IN   NS

However, my company has been delegated a /17 from ARIN, so we don't have a zone loaded into our DNS, meaning that I don't have a place to put in the redelegation statements.

I'm looking for some ideas from anyone who has ever run into this problem. The main dilemma is that if I create the zone, that zone will cover the whole /16. I'll be breaking reverse lookups for the /17 block we don't control for anyone using our DNS servers. However, if I don't create the zone, I can't redelegate the /24.

Any ideas?

(As a note, as I was writing this, I had a concept - perhaps I could create the zone, and simply generate NS records for the octets I don't control. These NS records could refer up the chain to ARIN's nameservers. (This might result in a bad referral message, though, but it might work.) Any thoughts on this idea would be greatly appreciated.)

Thank you in advance!

share|improve this question
up vote 1 down vote accepted

It's quite possible that ARIN have added your /17 delegation as a whole bunch of /24s. You should be able to verify this by running a dig +trace of the zones you've been delegated.

If that's the case, simply ask ARIN to change the delegation for the /24 you want changed.

share|improve this answer
I've run dig +traces for these zones before - I think that you're correct about that, but unfortunately, I'm tied by my company. We need to retain complete control of that block, which means that we have to redelegate, not ARIN. – lunchmeat317 Dec 30 '11 at 17:13
In that case you might be able to use a wildcard record in the /24 hosted on your own servers, delegating to the third-party nameservers but I'm not 100% that will work. Never tried doing anything quite like that! – James O'Gorman Dec 30 '11 at 17:23
I did exactly that, thinking it wouldn't work, and it did. I now see why it did, but I can't believe I overlooked it before. I assumed that doing * IN NS wouldn't work because they would then only be authoritative for subdomains of *, but it works perfectly. If you don't mind, add your comment to your answer for future readers. – lunchmeat317 Jan 13 '12 at 15:09

Well... Create 128 /24 zones, delegate the ones you need to

share|improve this answer
Delegation only works if you're delegating a subdomain. Thus, I need a /16 zone to delegate from. I can't delegate from the zone. – lunchmeat317 Dec 30 '11 at 15:35
This answer isn't quite right, and neither is my comment, but it's worth an upvote. I skipped the simple solution because I didn't think it would work, but it did. – lunchmeat317 Jan 13 '12 at 15:03

RFC 2317 defines how to do this. Whoever controls needs to delegate 0/ to you and create a lot of CNAMEs so that 1.1.0/ is a CNAME for, and so on. Then whoever has the other /17 can do the same with 128/ Admittedly, with a subnet as large as a /17, that's a lot of CNAME records that have to be created.

Then to redelegate the /24, you can create 1/24.0/ (or whatever) and do the same again with CNAMEs like 1.1/24.0/ for 1.1.0/

EDIT: When delegating /24 or larger blocks, there is a proper technique which should be used. The delegating authority still retains ultimate authority and can revoke the delegation whenever they wish.

share|improve this answer
I'm aware of that RFC, but that generally only comes into play when you're delegating something smaller than a /24. Additionally, if you want to redelegate a /24, you'd simply redelegate on octet lines, instead of using the RFC. – lunchmeat317 Dec 30 '11 at 16:04
It is required for delegating something smaller than a /24. I don't recall anything specifying is isn't applicable to larger delegations. Bind has some command which make generating the delegations easier. – BillThor Dec 30 '11 at 21:15
@BillThor You could use it that way for larger delegations, but it'd be pretty unwieldy. A zone like "1.1/24.0/" would be a nightmare in terms of maintenance, and lookups would fail if they didn't know the correct subnet. – lunchmeat317 Jan 13 '12 at 14:59
@lunchmeat317 It really isn't the proper way to delegate large blocks. That really should be done by delegating the appropriate /24 or larger block. However, the RFC describes how to do delegate PTR records using CNAMEs as I specified. There are no issues looking up the records. Whenever you don't do things the right way maintenance becomes more difficult. – BillThor Jan 13 '12 at 16:12

Create a zone for and then adding NS records back up to for the sections that you don't control would work. Keep in mind that:

  1. Requests from the internet are only going to be headed to the bits that you DO control, so
  2. Internally, you really only have to worry about the bits that you don't own for consistency of your own resolvers.

Another way to handle this would be to have a nameserver that is not used at all internally, but is queried externally. Your own internal resolvers would reach out to the internet, and when it hits your subnet, it would query... your nameserver.

share|improve this answer
Requests from the internet, I'm not worried about. I'm worried about the customers who use that nameserver for recursive queries. The resolver idea is a good one. Unfortunately, I can't change the network and DNS server design here, so I can't do internal/external resolvers, meaning I'm stuck in the current situation. I hadn't thought about referring it back to the TLD, though. That may indeed be a sound plan. – lunchmeat317 Dec 30 '11 at 15:40
Do you mean CNAME records, or NS records? – lunchmeat317 Dec 30 '11 at 16:31
Really, I'm rehashing what your idea was and altering the topology a bit. By making your resolver non-authorative for your and instead asking the internet to Do The Right Thing (which it will, thanks to the NS records in place at the level) you would be presented with a proper view of If NS1 is your internal recursive resolver and NS2 is authorative for your subnet, the request would go client -> NS1 -> -> NS2. Again, because has proper delegations, it doesn't matter what NS2 thinks it is authorative for. – Kyle Brantley Dec 30 '11 at 19:08
This, unfortunately, didn't work. The solution was much simpler than I'd thought - I skipped it because I didn't think it would work. – lunchmeat317 Jan 13 '12 at 15:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.