[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: delegating in-addr.arpa.




not to beat the subject into the ground, but here is some other info that
i found on delegating a /24
i am not sure if this is recommended as "best practice", but it makes
sense.

put the nameserver of the customer in the SOA record of the zone:

@	IN	SOA	ns1.customer.isp dnsadmin.foo.bar (

also go ahead and put in their nameservers for the NS records

	IN	NS	ns1.customer.isp
	IN	NS	ns2.customer.isp

finally, and this point is no different than what your perl script did,
but just uses facilities native to bind:

$ GENERATE 1-254 $ NS ns1.customer.isp
$ GENERATE 1-254 $ NS ns2.customer.isp


i think adding the customer's nameserver to your soa allows remote
nameservers to cache the entry and head straight to the customer's
nameserver to get NS entries rather than to hit yours first and then head
over to the customer.

on a related note, but not entirely specific to this case, i found that i
had to hard set a $TTL value within the zone file for this to finally
work. i think that has more to do with running bind9 rather than
delegating address space.

-cjm


On Wed, 14 Feb 2001, Steven Pritchard wrote:

> charles@lunarmedia.net said:
> > the block in question: 192.168.200 (changed to protect the innocent)
> [...]
> > can anyone tell me what exactly i am missing on this?
> > do i need to create an aggregate like 8.216.in-addr.arpa and then delegate
> > from there?
>
> (So much for changing the block to protect the innocent.  ;)
>
> Yes, *but* this is one of those times when people using your primary
> nameserver as a recursive resolver will bite you in the ass.  If you
> do that, and you don't own the entire block, then anyone using you as
> a resolver will not be able to look up anything in that block (that
> you aren't doing DNS for anyway).
>
> If that's not a concern (in other words, if you've long since set your
> nameserver to be non-recursive), then go for it.  Otherwise, just run
> the following (modified appropriately, of course):
>
>     perl -e 'for ($n=0;$n<256;$n++) { print "$n\tIN\tNS\tns.foo.bar\n" }' \
>         >> /var/named/db.192.168.200
>
> It's ugly, but it will work.
>
> Another alternative would be to use a wildcard, but the O'Reilly book
> seems to frown on that.  I'll admit that I'm not sure why, and I don't
> have the book handy to check.  Perhaps someone else would care to
> enlighten us...
>
> Steve
>


-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.