Re: IPv4 not working reverse on /24 cidr
On Mon, Jul 22, 2013 at 12:17:12PM -0400, Barry Margolin wrote: In article mailman.879.1374506938.20661.bind-us...@lists.isc.org, Ryan Pavely para...@nac.net wrote: So that would suggest any time any block a /24 is hosted you must actually host the parent zone, pointing to the larger cidr, and then have your normal files for each cider in that block. Of course. How else do you expect DNS to figure out that it should look in the RFC 1918 zone? The CNAMEs are the link between the normal reverse DNS name and the CIDR-style name. There's nothing automatic about RFC 1918. ITYM RFC 2317, Classless IN-ADDR.ARPA delegation: https://tools.ietf.org/html/rfc2317 -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv4 not working reverse on /24 cidr
In article mailman.877.1374504592.20661.bind-us...@lists.isc.org,
Ryan Pavely para...@nac.net wrote:
Ok. What am I doing wrong? As far as I know this has worked for years
and sometime, weeks, months, years, ago it stopped.
This is for doing /24 (greater in cidr smaller in size)
Example: we have a /25 that we host... and another /25 we host.. so we
split it up into smaller files unless we own the entire/24
The config is loaded.
Rndc reload reports all is well.
But a lookup fails.
Help?
BIND 9.9.3-P1 on Linux
== included file in named.conf
zone 128/27.1.10.10.IN-ADDR.ARPA {
type master;
file /usr/named/rev/10.10.1.128.rev;
};
Do you also have a 1.10.10.in-addr.arpa zone, and does it have all the
necessary CNAME records pointing x.1.10.10.in-addr.arpa to
x.128/27.1.10.10.in-addr.arpa?
--
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv4 not working reverse on /24 cidr
On Mon, 22 Jul 2013, Ryan Pavely wrote: Ryan Pavely Net Access Corporation http://www.nac.net/ So that would suggest any time any block a /24 is hosted you must actually host the parent zone, pointing to the larger cidr, and then have your normal files for each cider in that block. This was on the list a few days ago: https://dougbarton.us/DNS/2317.html Dave -- David Forrest St. Louis, Missouri ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv4 not working reverse on /24 cidr
Ryan Pavely
Net Access Corporation
http://www.nac.net/
On 7/22/2013 11:00 AM, Barry Margolin wrote:
In article mailman.877.1374504592.20661.bind-us...@lists.isc.org,
Ryan Pavely para...@nac.net wrote:
Ok. What am I doing wrong? As far as I know this has worked for years
and sometime, weeks, months, years, ago it stopped.
This is for doing /24 (greater in cidr smaller in size)
Example: we have a /25 that we host... and another /25 we host.. so we
split it up into smaller files unless we own the entire/24
The config is loaded.
Rndc reload reports all is well.
But a lookup fails.
Help?
BIND 9.9.3-P1 on Linux
== included file in named.conf
zone 128/27.1.10.10.IN-ADDR.ARPA {
type master;
file /usr/named/rev/10.10.1.128.rev;
};
Do you also have a 1.10.10.in-addr.arpa zone, and does it have all the
necessary CNAME records pointing x.1.10.10.in-addr.arpa to
x.128/27.1.10.10.in-addr.arpa?
I do not. 10.10.1.128/27 is a RFC1918 sample. In a real-world example
I also have some ATT address space 12.44.51.192/27 or so.. They point it
to me.
If I host a partial class, in this case 10.10.x.x I need to have a
parent file that cnames?
Am I correct I would do something like the following...
$GENERATE 128-160 $ CNAME $.128/27.1.10.10.IN-ADDR.ARPA.
What about when the block is already cnamed - pointed - delegated to
my host from an external source?
I tested this. It appears to be true. Interesting.
So that would suggest any time any block a /24 is hosted you must
actually host the parent zone, pointing to the larger cidr, and then
have your normal files for each cider in that block.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv4 not working reverse on /24 cidr
In article mailman.879.1374506938.20661.bind-us...@lists.isc.org, Ryan Pavely para...@nac.net wrote: So that would suggest any time any block a /24 is hosted you must actually host the parent zone, pointing to the larger cidr, and then have your normal files for each cider in that block. Of course. How else do you expect DNS to figure out that it should look in the RFC 1918 zone? The CNAMEs are the link between the normal reverse DNS name and the CIDR-style name. There's nothing automatic about RFC 1918. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv4 not working reverse on /24 cidr
On 22.07.13 12:29, Ryan Pavely wrote: I always thought I had to break up the CIDR's into the proper blocks so then my downstream customer can slave that partial zone. I don't want them slaving 10.10.1/24... etc.. So to do that you break up the block into all its parts, each with an origin, ttl, etc etc... So now it appears I need both the 10.10.1.rev and each 10.10.1.XX-YY.rev file. Seems redundant. It's not redundant. The /24 block owner has its own 1.10.10.in-addr.arpa zone which contains CNAMEs pointing to other zones. The clients have those other zones which the owner should slave. It's just recommended to give those zones names like 0/27.1.10.10.in-addr.arpa so it's clear what the zone does. Example is 1.1.10.10.in-addr.arpa CNAME 1.0/27.1.10.10.in-addr.arpa in the reverze zone. This will cause the lookups go to 0/27.1.10.10.in-addr.arpa maintained by the client. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv4 not working reverse on /24 cidr
I only mentioned rfc1918 as I am directly hosting them, versus my
upstream pointing cnames at me for other blocks. I didn't expect
anything different about them.
I thought, and it worked in the past (2008/2009 perhaps), that having
the full cidr notation and such in the named.conf files you are doing
the link.
e.g.
zone 0/27.1.10.10.IN-ADDR.ARPA {
type master;
file /usr/named/rev/10.10.1.0-27.rev;
};
And then that file announces
Origin 0/27.1.10.10.IN-ADDR.ARPA.
I always thought I had to break up the CIDR's into the proper blocks so
then my downstream customer can slave that partial zone. I don't want
them slaving 10.10.1/24... etc.. So to do that you break up the block
into all its parts, each with an origin, ttl, etc etc...
So now it appears I need both the 10.10.1.rev and each
10.10.1.XX-YY.rev file. Seems redundant.
Ryan Pavely
Net Access Corporation
http://www.nac.net/
On 7/22/2013 12:17 PM, Barry Margolin wrote:
In article mailman.879.1374506938.20661.bind-us...@lists.isc.org,
Ryan Pavely para...@nac.net wrote:
So that would suggest any time any block a /24 is hosted you must
actually host the parent zone, pointing to the larger cidr, and then
have your normal files for each cider in that block.
Of course. How else do you expect DNS to figure out that it should look
in the RFC 1918 zone? The CNAMEs are the link between the normal reverse
DNS name and the CIDR-style name. There's nothing automatic about RFC
1918.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
