\
On Thu, Nov 25, 2010 at 2:50 AM, Matus UHLAR - fantomas
<uh...@fantomas.sk>wrote:
> On 25.11.10 10:10, Tech W. wrote:
> > We have a zone in Bind, for example, abc.com
> > We designate a subzone of it to another dns server, for eaxmple, F5's
> 3DNS.
> >
> > The corresponding RR in Bind is:
> >
> > games.abc.com. IN NS 3600 ns1.example.com.
> > games.abc.com. IN NS 3600 ns2.example.com.
>
> so, there are glue NS records in abc.com for games.abc.com, right?
>
> > But F5's 3DNS can't setup the NS records for games.abc.com.
> > That means, when query to:
> >
> > dig games.abc.com ns @ns1.example.com
>
> are the NS records for games.abc.com also in the games.abc.com ?
> They must be there, games.abc.com will not fetch glue records from abc.com
> .
>
> And in fact, since games.abc.com is authoritative for games.abc.com (of
> course... those in abc.com are JUST GLUE), there are probably no NS
> records
> for games.abc.com.
>
> > get nothing.
>
> try "dig any games.abc.com @ns1.example.com"
There may be a simpler answer.
If your NS resource record really looks like what was posted, it is in error
and the zone shouldn't even load. Check your logs for this when you start
named.
I suspect that the "3600" is an explicit TTL for the record, but this value
shouldn't be part of the resource record data, the part following the RR
type. The record should look more like:
games.abc.com. 3600 IN NS ns1.example.com.
games.abc.com. 3600 IN NS ns2.example.com.
Where the explicit TTL follows the domain name on the left hand side. Run
your zone file through "named-checkzone" to look for problems with your
data.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
