Add new subnet on multi-homed hosts

Mark Andrews Mark_Andrews at isc.org
Mon Mar 6 21:09:12 UTC 2006


> Barry Margolin <barmar at alum.mit.edu> writes:
> 
> > In article <due7jv$2sv9$1 at sf1.isc.org>,
> >  Harry Putnam <reader at newsguy.com> wrote:
> >
> >> db.192.168.1
> >> ===========================
> >> $TTL 1D 
> >> @       IN SOA  reader.local.lan. reader.reader.local.lan. (
> >>               200405190  ; serial
> >>               28800      ; refresh (8 hours)
> >>               14400      ; retry (4 hours)
> >>               2419200    ; expire (4 weeks)
> >>               86400      ; minimum (1 day)
> >>               )
> >> ;
> >> ; Name servers (The name '@' is implied)
> >> ;
> >>                   IN      NS     reader
> >
> > That should be "reader.local.lan."
> >
> >> ;
> >> ; Addresses point to canonical names
> >> ;
> >> 
> >> 192.168.1.2.      IN      PTR    rdmz.local.lan.
> >> 192.168.1.1.      IN      PTR    fwdmz.local.lan.
> >
> > Didn't you get error messages complaining about names outside the zone 
> > when you loaded this?  Those should be:
> 
> I've been trying lots of different stuff and may have gotten the error
> messages for this thread mixed up.  In OP I said there were none but
> as you've noted.  That does generate `out of zone' errors.
> 
> > 2 IN PTR rdmz.local.lan.
> > 1 IN PTR fwdmz.local.lan.
> 
> Ok, with changes suggested made:
> 
> Restart of named shows nothing of note...
> Further the problem I was noting of nslookup not knowing about the two
> IP s on 192.168.1/24  has disappeared too.
> 
>   reader > nslookup 192.168.1.2
>   Server:         127.0.0.1
>   Address:        127.0.0.1#53
> 
>   2.1.168.192.in-addr.arpa        name = rdmz.local.lan.
> 
> Those were small config changes but did what was needed 
> .. thanks.
> 
> I'm still confused about how $ORIGIN works and when it matters.
> 
> When db.192.168.1 is loaded.  Its ORIGIN is initially set from
> named.conf right?.   So that would be:
>    1.168.192.in-addr.arpa.
> 
> In this line:
>                    IN      NS     reader.local.lan.
> (with your correction)
> reader.local.lan is a different $ORIGIN yet it causes no errors about
> out of zone since the notation of (.) dot at the end indicates this is
> a canonical address.

	It's the *owner* of the record that has to be in zone.
	If you expand the above line you get

		1.168.192.in-addr.arpa. IN NS reader.local.lan.

	Which clearly is in zone (ends in the zones name).

 
> In OP I had (prior to your corrections)
> 
> 192.168.1.2.      IN      PTR    rdmz.local.lan.
> 192.168.1.1.      IN      PTR    fwdmz.local.lan.
> 
> Which is canonical on both ends and in the $ORIGIN, yet it was rejected
> as `out of zone'

	192.168.1.2. doesn't end in 1.168.192.in-addr.arpa.
	192.168.1.1. doesn't end in 1.168.192.in-addr.arpa.
 
> Something more that just using shortcuts is going on there.

	No.  You just need to learn more.

	Mark
--
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