[lug] forwarding authoritative responses for classful reverse lookups

[Nate Duehr]

Ah-ha! I KNEW I'd forgotten something!

There's also a faster way to do this, and some other administrivia that will
help things... first...

In the SOA record, list HIS nameserver as the SOA, not yours.  Then resolvers
will cache that and go straight to him if they have a cached SOA record.  I'm
not sure if this is "best practice", but it works... Also, you can replace the
NS records in the zone with names of HIS servers to help things along also... no
need to have everyone come back to your servers to check SOA or TTL information
only to have to then bounce down to his servers.

Also, don't forget a $TTL statement at the top of the zone if you're using newer
versions of BIND to avoid the "TTL value not found, using SOA minimum value
instead" message in your logs.  The TTL value in newer versions of BIND is used
for the NEGATIVE cache timer value now.

So the SOA will look like this:

@ IN SOA his.nameserver.com ( ... etc etc...

For the other stuff, use a GENERATE statement...

$ GENERATE 1-254 $ NS ns1.customernameserver.com

... and if he has two nameservers... you CAN have two GENERATE statements.

$ GENERATE 1-254 $ NS ns2.customernameserver.com

Sean and I were having an off-list discussion about this, and this was the part
I forgot and couldn't remember to make it all work.

Remember this discussion is about how to delegate an ENTIRE Class-C.  This will
NOT be the appropriate way to delegate a partial (CIDR) block of names.

And it DOES have a major caveat.  Your nameserver HAS to be up and answering
queries for the delegation to work... if your nameserver goes off line, anyone
who doesn't have a cached set of responses (hasn't been to his site before) will
not be able to reverse-resolve his Class-C.

Cheers,

Quoting charles at lunarmedia.net:

> 
> I found that contacting ARIN is not necessary and all. It just wouldnt
> be
> practical do so when you just want to delegate a /24 from say, a larger
> /20 that you have. You would end up calling ARIN every time you add a
> new
> customer, and just think when this customer leaves, you'd have to call
> ARIN again. Its easier than that.
> 
> What you can do, in turns out, is create your regular zone file:
> 
> @ IN SOA my.nameserver.isp hostmaster.nameserver.isp (
> 	2001021400
> 	10800
> 	3600
> 	604800
> 	86400 )
> 
> 	IN NS ns1.nameserver.isp
> 	IN NS ns2.nameserver.isp
> 
> 
> now, put in an NS record in it for each individual ip that you want your
> customer to be responsible for:
> 
> 1  IN   NS   ns1.customer.inc
>    IN   NS   ns2.customer.inc
> 2  IN   NS   ns1.customer.inc
> etc...
> 
> this will allow your customer to be fully authoritative for reverse
> lookups of this block without having to deal with arin everytime you
> reassign this block to a new customer. its similar to the classless
> reverse delegation, but a bit more simple.
> 
> the other option you can do is create a larger aggregate for your block
> and assign the smaller blocks with ns records. the downside to this is
> that if your nameserver is doing recursive lookups, you need to make
> sure
> that you are authoritative for the larger block as well. so if you have
> 200.168.192.in-addr.arpa, you can create a 168.192.in-addr.arpa file and
> delegate smaller blocks from there:
> 
> 200  IN  NS  ns1.customer.inc
>              ns2.customer.inc
> 
> but, if only have a /20 rather than that whole /16, you will have killed
> anyone using your nameserver for recursive lookups from finding the rest
> of that /16.
> 
> so, its a bit crufy, but the first method works pretty well.
> 
> -cjm
> 
> 
> 
> 
> On Tue, 13 Feb 2001, Sean Reifschneider wrote:
> 
> > On Tue, Feb 13, 2001 at 09:37:36PM -0600, charles at lunarmedia.net
> wrote:
> > >i really do not want to have my server act as a slave for the
> client's
> > >nameserver. can't i delegate the block to the client through bind?
> >
> > In that case, you'll have to get ARIN to change the DNS server(s)
> listed
> > for that block.
> >
> > Sean
> >
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> 



--
Nate Duehr, nate at natetech.com

"Never underestimate the bandwidth of a 747 filled with CD-ROM's."