0

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:

z.y.x.in-addr.arpa   IN   NS   nsa.domain.com
z.y.x.in-addr.arpa   IN   NS   nsb.domain.com

However, my company has been delegated a /17 from ARIN, so we don't have a y.x.in-addr.arpa 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 y.z.in-addr.arpa 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 y.x.in-addr.arpa 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!

Improve this question

4 Answers 4

Reset to default
1

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.

Improve this answer
3
  • 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.
    – user84272
    Dec 30, 2011 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, 2011 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 *.z.y.x.in-addr.arpa IN NS ns.elsewhere.com wouldn't work because they would then only be authoritative for subdomains of *.z.y.x.in-addr.arpa, but it works perfectly. If you don't mind, add your comment to your answer for future readers.
    – user84272
    Jan 13, 2012 at 15:09
2

RFC 2317 defines how to do this. Whoever controls y.x.in-addr.arpa needs to delegate 0/17.y.x.in-addr.arpa to you and create a lot of CNAMEs so that 1.1.0/17.y.x.in-addr.arpa is a CNAME for 1.1.y.x.in-addr.arpa, and so on. Then whoever has the other /17 can do the same with 128/17.y.x.in-addr.arpa. 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/17.y.x.in-addr.arpa (or whatever) and do the same again with CNAMEs like 1.1/24.0/17.y.x.in-addr.arpa for 1.1.0/17.y.x.in-addr.arpa.

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.

Improve this answer
4
  • 1
    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.
    – user84272
    Dec 30, 2011 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, 2011 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/17.y.x.in-addr.arpa" would be a nightmare in terms of maintenance, and lookups would fail if they didn't know the correct subnet.
    – user84272
    Jan 13, 2012 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, 2012 at 16:12
0

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

Improve this answer
2
  • Delegation only works if you're delegating a subdomain. Thus, I need a /16 zone to delegate from. I can't delegate z.y.x.in-addr.arpa from the z.y.x.in-addr.arpa zone.
    – user84272
    Dec 30, 2011 at 15:35
  • 1
    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.
    – user84272
    Jan 13, 2012 at 15:03
0

Create a zone for x.y.in-addr.arpa. and then adding NS records back up to in-addr.arpa. 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.

Improve this answer
4
  • 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.
    – user84272
    Dec 30, 2011 at 15:40
  • Do you mean CNAME records, or NS records?
    – user84272
    Dec 30, 2011 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 x.y.in-addr.arpa. and instead asking the internet to Do The Right Thing (which it will, thanks to the NS records in place at the in-addr.arpa. level) you would be presented with a proper view of in-addr.arpa. If NS1 is your internal recursive resolver and NS2 is authorative for your subnet, the request would go client -> NS1 -> in-addr.arpa. -> NS2. Again, because in-addr.arpa. has proper delegations, it doesn't matter what NS2 thinks it is authorative for.
    – Kyle Brantley
    Dec 30, 2011 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.
    – user84272
    Jan 13, 2012 at 15:02

You must log in to answer this question.