$GENERATE forwarding problem -- RESOLVED
Alex Moen
alexm at ndtel.com
Wed Jan 5 16:09:09 UTC 2005
> -----Original Message-----
> From: bind-users-bounce at isc.org
> [mailto:bind-users-bounce at isc.org] On Behalf Of Mark Andrews
> Sent: Tuesday, January 04, 2005 4:07 PM
> To: Alex Moen
> Cc: bind-users at isc.org
> Subject: Re: $GENERATE forwarding problem
>
>
>
> > 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
Mark,
Thanks for the reply... It makes total sense and explains the symptoms. We
are going to have the ARIN records repaired and the problem should go away.
A case of not fully understanding how things are supposed to work. God
protect us all from those who know just enough to be dangerous!!! :)
Again, thanks for taking the time to reply and explain all of this. It is
very appreciated.
Alex
More information about the bind-users
mailing list