Forward zone files not working on Bind 9.3.6-P1 for Solaris and OpenSolaris??

[Kaya Saman]

Hi,

I'm not sure if there is a syntax error or if I've missed to include
something but for some reason my forward zone files don't seem to be
working :-(

I pulled the skeleton of the files straight off my working Solaris 9
boxes which use Bind 9 from Blastwave! I checked and double checked the
paths in named.conf as Blastwave has all it's files stored in
/opt/csw/.... and /etc/opt/csw... directories; while with native Sol10
and OpenSol Bind I can use /etc and /var/named respectively.

The zone files 'domain' are just so that I can use the Sun Secure Global
Desktop software in a test platform which is why I have decided to
allocated the FQDN of sgd.test.

These are the zone files:

{Forward}

;
; BIND data file for example.com
;
$TTL 1d
@ IN SOA ns-m.test. mail.test. (
2009103007 ; Serial
7200 ; Refresh
120 ; Retry
2419200 ; Expire
86400) ; Default TTL
;
IN NS ns-m.test.
ns-m.test. IN A 192.168.2.24
sgd.test. IN A 192.168.2.24

{Reverse}

$TTL 1d ;
$ORIGIN 2.168.192.IN-ADDR.ARPA.
@ IN SOA ns-m.test. mail.test. (
2009103002
7200
120
2419200
86400
)

IN NS ns-m.test.
24 IN PTR ns-m.test.
24 IN PTR sgd.test.

This is the error I receive from OpenSol:

Oct 30 13:24:11 sgd named[2025]: [ID 873579 daemon.notice] starting BIND
9.3.6-P1
Oct 30 13:24:11 sgd named[2025]: [ID 873579 daemon.notice] command
channel listening on 127.0.0.1#953
Oct 30 13:24:11 sgd named[2025]: [ID 873579 daemon.warning]
/var/named/sgd.db:13: ignoring out-of-zone data (ns-m.test)
Oct 30 13:24:11 sgd named[2025]: [ID 873579 daemon.notice] running

Also the same error for Sol10:

Oct 30 13:43:31 sgd named[1857]: [ID 873579 daemon.notice] starting BIND
9.3.6-P1
Oct 30 13:43:31 sgd named[1857]: [ID 873579 daemon.notice] command
channel listening on 127.0.0.1#953
Oct 30 13:43:31 sgd named[1857]: [ID 873579 daemon.warning]
/var/named/sgd.db:13: ignoring out-of-zone data (ns-m.test)
Oct 30 13:43:31 sgd named[1857]: [ID 873579 daemon.notice] running

Reverse lookups are all perfectly ok!!

What am I missing here???

In Debian Etch ages ago I had to include the statement:

test. IN NS ns-m.test.

but of course with this version of Bind it doesn't like it.....

I am completely lost as I've said above on my Sol9 boxes running Bind 9
from Blastwave all is fine using exact same syntax in zone files so why
don't my forward zone files work now???

Many thanks for any help!

--Kaya

[Kevin Darcy]

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

> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>

[Kaya Saman]

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

[Kevin Darcy]

Kaya Saman wrote:
> 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;

I think the last significant update to the master-file syntax was when
$TTL was defined in RFC 2308 (circa 1998).

>
> 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; };
> }

No, that won't work. The names in the zone file are all under
"domain.com", but you're trying to load the zone as simply "domain",
which is not in the same naming hierarchy; in fact it's a completely
different TLD (top-level domain).

As well as setting the default $ORIGIN, the name of a zone in named.conf
also defines the allowable scope of all owner names within it. You can't
just pick some name arbitrarily, like you can with, for examples, "view"
or "acl". It actually forms a branch in the DNS database; all of the
owner names in the zone must then be at or underneath that point in the
hierarchy.

- Kevin

[Kaya Saman]

> No, that won't work. The names in the zone file are all under
> "domain.com", but you're trying to load the zone as simply "domain",
> which is not in the same naming hierarchy; in fact it's a completely
> different TLD (top-level domain).
>
> As well as setting the default $ORIGIN, the name of a zone in
> named.conf also defines the allowable scope of all owner names within
> it. You can't just pick some name arbitrarily, like you can with, for
> examples, "view" or "acl". It actually forms a branch in the DNS
> database; all of the owner names in the zone must then be at or
> underneath that point in the hierarchy.
>
> - Kevin
>

> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Many thanks again Kevin, I think I am starting to see this more clearly:

where I have sgd.test basically the .test Bind is trying to use as the
TLD....

so for example a .com address could be such as domain.com where the zone
would then be called 'domain' so then Bind would then see the NS record as:

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

such as I pointed out before.

So the question now becomes, since the DNS TLD hierarchy is of format
.com, .org, .co.{country prefix}, .gov etc....

Bind itself won't be able to use my .test setup at all will it?? I have
to name it as something like sgd.test.com where the zone within the
named.conf file then can be called test and the zone file records then
become:

IN NS ns-m.test.com.
ns-m.test.com. IN A 192.168.2.24
sgd.test.com. IN A 192.168.2.24

Am I right in assuming this??

Thank you for your patience and sorry for being slow with all of this :-)

[Kaya Saman]

>
>
> Am I right in assuming this??
>

Otherwise, with my setup taking an example of google.com - I was trying
to use the .com with the .test where I actually wanted to use the .test
as the secondary level domain of google but not append a TLD to it.....
I think this is against all DNS rules no??

[Kaya Saman]

Luc I. Suryo wrote:
> you have to become auth for the .test and then in that zone define the subdomain's NS
> make sense?
>
>
> nb: old company we had .prv for internal use :)
>
> -ls
>
>
Thanks Luc,

I think I understand now! The TLD for my domain has become .test
therefor the secondary level domain becomes sgd so inevitably the ns
must be ns-m.sgd.test then.....

and zone should be called sgd then??

[Kaya Saman]

> Thanks Luc,
>
> I think I understand now! The TLD for my domain has become .test
> therefor the secondary level domain becomes sgd so inevitably the ns
> must be ns-m.sgd.test then.....
>
> and zone should be called sgd then??
>

> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Many thanks Kevin and Luc for all the help!!! :-)

My DNS is fine now.... taking the concept of TLD, secondary domain, and
sub domain; ns-m became a sub domain to the secondary sgd with .test
being the TLD. And go figure it all works!

That was a nice and pleasant learning experience, thanks for bearing
with me too - much appreciated :-D

Best regards,

--Kaya