Kevin Darcy wrote:
If you're loading a zone as "sgd.test", then an owner name of
ns-m.test doesn't belong in it, and BIND is correct to reject it.
Either change that name to something under sgd.test, or set up a
separate zone for ns-m.test or anything above that in the hierarchy
(i.e. "test" or root).
I don't know why this would have worked in your old environment, but
then again I don't know what version "BIND 9 from Blastwave" is, or
what you mean by "skeleton of the files".
- Kevin
Hi Keven,
thanks for responding :-)
By skeleton I meant format. Sorry if put badly but basically I have
noticed that through different versions of Bind the overall layout and
format of the zone files does change for some reason especially since I
have gone from various Linux distros to Solaris now;
To give you an example of what I mean, taking the domain as domain.com:
;
; BIND data file for example.com
;
$TTL 1d
@ IN SOA ns-m.domain.com. mail.domain.com. (
2009103007 ; Serial
7200 ; Refresh
120 ; Retry
2419200 ; Expire
86400) ; Default TTL
;
IN NS ns-m.domain.com.
ns-m.domain.com. IN A 192.168.2.24
sgd.domain.com. IN A 192.168.2.24
Then reference this in named.conf calling the zone 'domain', like so:
zone "domain" {
type master;
file "/var/named/domain.db";
allow-query { internals; };
}
Actually I think I see what you mean about: "If you're loading a zone as
"sgd.test", then an owner name of ns-m.test doesn't belong in it, and
BIND is correct to reject it". as the zone should be called test within
named.conf not sgd.test!!
This is quite a good learning point actually since the $ORIGIN statement
then gets negated as the zone's origin becomes 'test' at least in my case.
Am I correct in my evaluation with the last two sentences???
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users