delegation broken after migrating to new BIND config

[Bob Harold]

On Thu, Dec 8, 2016 at 11:09 PM, blrmaani <blrmaani at gmail.com> wrote:

> I migrated our bind resolvers to a new config (new named.conf) and I see
> delegation broken. How do I trouble-shoot?
>
> - The resolvers (are slaves) and are authoritative for zone1.example.com
> and example.com
> - the resolvers forward queries to our companies DNS to resolve external
> names like microsoft.com, isc.com etc
> - The resolver has views and match same destinations in both old and new
> config.
>
>
>
> the zone is zone1.example.com which contains a record
> name1.zone1.example.com as below:
> name1.zone1.example.com. NS othername1.example.com.
> othername1.example.com.    A   1.2.3.4
>
>
> dig @localhost  name1.zone1.example.com.  # this doesn't give any hint.
>
> Here are the steps I tried and still no luck:
>
> 1. Compared zone transfer output of zone1.example.com before and after
> migration, both look similar and contains delegation entry.
>
> 2. I tried this and works ok (before and after migration) in both cases
> indicating that the NS
>     is still reachable and respond to DNS queries before and after
> migration.
>
> dig     @othername1.example.com.  name1.zone1.example.com.
> ## Returns 5.6.7.8 as expected  ACLs broken
>
>
> 3. Checked cache dump file (db file) - I see the following entry when it
> works (pre-migration):
> cache_dump.db:; 1.2.3.4  [srtt 0] [flags 00000000] [ttl 1797]
>
> however, the above entry is missing after I migrate to new BIND config.
>
>
> I compared the BIND configs before and after migration and I don't see any
> significant difference which might cause this issue.. wondering what am I
> missed?
>
> Thanks
> Blr
>

Looks to me like "othername1.example.com" is not in the zone "
zone1.example.com" and is not below that zone, so it is not proper glue,
and should not be in that zone at all.  The name server should ignore it.
It is in zone "example.com <http://othername1.example.com/>" and that zone
should be queried to find it.

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20161209/08f5fccc/attachment.html>