$GENERATE forwarding problem

Mark Andrews Mark_Andrews at isc.org
Tue Jan 4 22:06:43 UTC 2005


> Here's the deal:
> 
> We have been assigned our addresses from ARIN.  We suballocate (I think
> that's the proper term) some of our addresses to other companies in our =
> AS,
> which then again suballocate to their customers.
> 
> Our nameserver is running BIND 9.2.1.
> 
> Our colleagues nameserver is running BIND 9.2.1.
> 
> So, in one of our subnets, I have the following config:
> 
> 
> 
> $TTL    1h
> 245.21.64.in-addr.arpa. IN      SOA     ns.stellarnet.com.
> hostmaster.stellarnet.com. (
>                                 2               ; Serial
>                                 10800           ; Refresh 3 hours
>                                 3600            ; Retry   1 hour
>                                 604800          ; Expire  1 week
>                                 86400 )         ; Minimum 24 hours
> ;------------------------------------------------------------------------=
> -
> ; Name Servers
> ;------------------------------------------------------------------------=
> -
>         IN      NS      ns.stellarnet.com.
>         IN      NS      ns1.stellarnet.com.
>         IN      NS      ns2.stellarnet.com.
> ;------------------------------------------------------------------------=
> -
> ; Host Addresses point to canonical name
> ;------------------------------------------------------------------------=
> -
> 245/24  IN      NS      ns1.itgdata.net.
> 245/24  IN      NS      ns2.itgdata.net.
> $GENERATE       0-255   $       NS      ns1.itgdata.net.
> $GENERATE       0-255   $       NS      ns2.itgdata.net.
> 
> 
> 
> Now, our colleagues have the following:
> 
> 
> 
> ;
> ; Authoritative data for 245.21.64.in-addr.arpa (ORIGIN assumed
> 245.21.64.in-addr.arpa)
> ;
> $TTL    5m
> 245.21.64.in-addr.arpa. IN      SOA     ns1.itgdata.net.
> hostmaster.ideaone.net. (
>                                 2005010304      ; Serial
>                                 10800           ; Refresh 3 hours
>                                 3600            ; Retry   1 hour
>                                 604800          ; Expire  1 week
>                                 86400 )         ; Minimum 24 hours
> ;------------------------------------------------------------------------=
> -
> ; Name Servers (The name '@' is implied)
> ;------------------------------------------------------------------------=
> -
>         IN      NS      ns1.itgdata.net.
>         IN      NS      ns2.itgdata.net.
> ;------------------------------------------------------------------------=
> -
> ; Addresses point to canonical name
> ;------------------------------------------------------------------------=
> -
> 1       IN      PTR     ideaone-245-1.ideaone.net.
> 2       IN      PTR     ideaone-245-2.ideaone.net.
> ---snip----
> 126     IN      PTR     ideaone-245-126.ideaone.net.
> 127     IN      PTR     ideaone-245-127.ideaone.net.
> ; SUN DOT Communications Forwarding=20
> 128/26  IN      NS      ns2.sdnets.com.
> $GENERATE       128-191 $       NS      ns2.sdnets.com.
> ;
> 192     IN      PTR     ideaone-245-192.ideaone.net.
> 193     IN      PTR     ideaone-245-193.ideaone.net.
> ---snip to end of class "c"---
> 
> 
> 
> Locally at the ideaone server, the ip addresses in the $GENERATE subset
> resolve properly.  However, our nameserver reports a "server failed":
> 
> 
> 
> dig 64.21.245.156
> 
> ; <<>> DiG 9.2.1 <<>> 64.21.245.156
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34566
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> ;; QUESTION SECTION:
> ;64.21.245.156.                 IN      A
> ;; AUTHORITY SECTION:
> .                       8356    IN      SOA     A.ROOT-SERVERS.NET.
> NSTLD.VERISIGN-GRS.COM. 2005010400 1800 900 604800 86400
> ;; Query time: 3 msec
> ;; SERVER: 66.163.129.19#53(66.163.129.19)
> ;; WHEN: Tue Jan  4 09:06:27 2005
> ;; MSG SIZE  rcvd: 106
> 
> 
> 
> However, outside of the $GENERATEd subset, it works fine:
> 
> 
> 
> dig 64.21.245.127=20
> ; <<>> DiG 9.2.1 <<>> 64.21.245.127
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17032
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> ;; QUESTION SECTION:
> ;64.21.245.127.                 IN      A
> ;; AUTHORITY SECTION:
> .                       9911    IN      SOA     A.ROOT-SERVERS.NET.
> NSTLD.VERISIGN-GRS.COM. 2005010400 1800 900 604800 86400
> ;; Query time: 3 msec
> ;; SERVER: 66.163.129.19#53(66.163.129.19)
> ;; WHEN: Tue Jan  4 09:07:02 2005
> ;; MSG SIZE  rcvd: 106
> 
> 
> 
> Also, dnsstuff gives the following information:
> 
> 
> 
> Country: UNITED STATES
> 
> Preparation:
> The  reverse DNS entry for an IP is found by reversing the IP, adding it =
> to
> "in-addr.arpa", and looking up the PTR record.
> So, the reverse DNS entry for 64.21.245.156 is found by looking up the =
> PTR
> record for 156.245.21.64.in-addr.arpa.
> All DNS requests start by asking the root servers, and they let us know =
> what
> to do next.
> See How Reverse DNS Lookups Work for more information.
> 
> How I am searching:
> Asking f.root-servers.net for 156.245.21.64.in-addr.arpa PTR record: =20
>        f.root-servers.net says to go to figwort.arin.net. (zone:
> 64.in-addr.arpa.)
> Asking figwort.arin.net. for 156.245.21.64.in-addr.arpa PTR record: =20
>        figwort.arin.net [192.42.93.32] says to go to ns2.stellarnet.com.
> (zone: 245.21.64.in-addr.arpa.)
> Asking ns2.stellarnet.com. for 156.245.21.64.in-addr.arpa PTR record: =20
>        ns2.stellarnet.com [66.163.128.15] says to go to ns2.itgdata.net.
> (zone: 156.245.21.64.in-addr.arpa.)
> Asking ns2.itgdata.net. for 156.245.21.64.in-addr.arpa PTR record: =20
>        ns2.itgdata.net [64.21.232.3] says to go to ns2.sdnets.com. =
> (zone:
> 156.245.21.64.in-addr.arpa.)
> 
> WARNING: Duplicate zone found (156.245.21.64.in-addr.arpa. is repeated).
> This can prevent the lookup from continuing
>          (BIND8 and BIND9 will cause a 'server failure' response).  =
> Although
> I will continue, be aware that
>          most DNS servers will not see your reverse DNS entry.
> 
> Asking ns2.sdnets.com. for 156.245.21.64.in-addr.arpa PTR record:  =
> Reports
> ns1.scheelssports.com. [from 66.97.248.17]
> 
> Answer:
> 64.21.245.156 PTR record: ns1.scheelssports.com. [TTL 400s]
> [A=3D64.21.245.156]
> 
> 
> 
> So what did I misconfigure???  Thanks for any suggestions or ideas, I'm
> stumped.
> 
> Alex Moen
> Operations Technology Specialist
> NDTC=20

North Dakota Telephone Co. NDTEL-2-NDTC (NET-64-21-224-0-1)
                                  64.21.224.0 - 64.21.255.255
IdeaOne Telecom IDEAONE-1 (NET-64-21-232-0-1)
                                  64.21.232.0 - 64.21.247.255
Sun Dot Communications, LLC IDEAONE-64-21-245-0 (NET-64-21-245-128-1)
                                  64.21.245.128 - 64.21.245.255


	Delegations in the DNS are strictly heirarchical.  Sideways 
	delegations DO NOT WORK.

	You need need to tell ARIN that IdeaOne Telecom's nameservers
	are the reverse servers for 64.21.232.0 - 64.21.247.255.  You
	can do this by updating NET-64-21-232-0-1.  ARIN and all RIRs
	are setup to handle this.

	IdeaOne Telecom and Sun Dot Communications then use a RFC 2317
	style delegation for 64.21.245.128 - 64.21.245.255 as it is
	smaller than a /24.

	If the final delegation was a /24 (64.21.245.0 - 64.21.245.255) then
	ARIN would have Agri ImaGIS's nameservers listed for this range
	not IdeaOne Telecom's.

	This is done because address space can be delegated on boundaries
	other than /8, /16 or /24.  The DNS is delegated on /8, /16 and /24.

	If you had a /16 (or larger) then you would be sub-delegating
	the /24's below your /16's.  As you don't the owner of the /16
	above you delegates the IN-ADDR.ARPA zones for the /24's below you
	directly.

	The delegations should look something like.
	
.			379550	IN	NS	A.ROOT-SERVERS.NET.
.			379550	IN	NS	B.ROOT-SERVERS.NET.
.			379550	IN	NS	C.ROOT-SERVERS.NET.
.			379550	IN	NS	D.ROOT-SERVERS.NET.
.			379550	IN	NS	E.ROOT-SERVERS.NET.
.			379550	IN	NS	F.ROOT-SERVERS.NET.
.			379550	IN	NS	G.ROOT-SERVERS.NET.
.			379550	IN	NS	H.ROOT-SERVERS.NET.
.			379550	IN	NS	I.ROOT-SERVERS.NET.
.			379550	IN	NS	J.ROOT-SERVERS.NET.
.			379550	IN	NS	K.ROOT-SERVERS.NET.
.			379550	IN	NS	L.ROOT-SERVERS.NET.
.			379550	IN	NS	M.ROOT-SERVERS.NET.

64.in-addr.arpa.	86400	IN	NS	chia.ARIN.NET.
64.in-addr.arpa.	86400	IN	NS	dill.ARIN.NET.
64.in-addr.arpa.	86400	IN	NS	BASIL.ARIN.NET.
64.in-addr.arpa.	86400	IN	NS	henna.ARIN.NET.
64.in-addr.arpa.	86400	IN	NS	indigo.ARIN.NET.
64.in-addr.arpa.	86400	IN	NS	epazote.ARIN.NET.
64.in-addr.arpa.	86400	IN	NS	figwort.ARIN.NET.

156.245.21.64.in-addr.arpa. 3600 IN	NS	ns1.itgdata.net.
156.245.21.64.in-addr.arpa. 3600 IN	NS	ns2.itgdata.net.

128-255.245.21.64.in-addr.arpa.	400	IN	NS	ns2.sdnets.com.
128-255.245.21.64.in-addr.arpa.	400	IN	NS	ns1.sundotcom.net.
$GENERATE 128-255 $ CNAME $.128-255.245.21.64.in-addr.arpa.

	The name of the final zone may differ.  Some common alternates are.

128/17.245.21.64.in-addr.arpa.	400	IN	NS	ns2.sdnets.com.
128/17.245.21.64.in-addr.arpa.	400	IN	NS	ns1.sundotcom.net.
$GENERATE 128-255 $ CNAME $.128/17.245.21.64.in-addr.arpa.

128.245.21.64.in-addr.arpa.	400	IN	NS	ns2.sdnets.com.
128.245.21.64.in-addr.arpa.	400	IN	NS	ns1.sundotcom.net.
$GENERATE 129-255 $ CNAME $.128.245.21.64.in-addr.arpa.

	Or the PTR's may be put in a forward zone. e.g.

$GENERATE 128-255 $ CNAME $.245.21.64.sundotcom.com.

	Or use a traditional delegation to individual zones for each of
	the addresses in the range.

$GENERATE 128-255 $ NS ns2.sdnets.com.
$GENERATE 128-255 $ NS ns1.sundotcom.net.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



More information about the bind-users mailing list