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!

4 Answers4

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.

Community
  • 1
Mike Scott
  • 7,993
  • 31
  • 26
  • 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. –  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/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. –  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
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.

James O'Gorman
  • 5,329
  • 2
  • 24
  • 28
  • 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. –  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 `*.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. –  Jan 13 '12 at 15:09
0

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

Mathias R. Jessen
  • 25,161
  • 4
  • 63
  • 95
  • 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. –  Dec 30 '11 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. –  Jan 13 '12 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.

Kyle Brantley
  • 1,331
  • 1
  • 11
  • 14
  • 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. –  Dec 30 '11 at 15:40
  • Do you mean CNAME records, or NS records? –  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 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 '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. –  Jan 13 '12 at 15:02