named-checkconf error

[Chris Thompson]

On Dec 7 2008, Mark Andrews wrote:

>named-checkzone calls getaddrinfo() to lookup addresses of servers
>which are not in the zone.  That lookup has failed.
>
>For a start I would fix this delegation error.  The NS RRset on both
>sides of the delegation should be the same.
>
>capmark.com.            172800  IN      NS      ns1.gmaccm.com.
>capmark.com.            172800  IN      NS      ns2.gmaccm.com.
>;; Received 116 bytes from 192.42.93.30#53(G.GTLD-SERVERS.NET) in 175 ms
>
>quarantine1.capmark.com. 7200   IN      A       216.83.188.21
>capmark.com.            86400   IN      NS      ns1.capmark.com.
>capmark.com.            86400   IN      NS      ns2.capmark.com.
>;; Received 125 bytes from 216.83.188.8#53(ns1.gmaccm.com) in 227 ms

It seems rather unlikely that this has anything to do with the OP's problem,
as the IP addresses of ns{1,2}.gmaccm.com and ns{1,2}.capmark.com are the
same, i.e. 216.83.188.{8,9}, in the glue as well as in the zones.

But technically, of course, Mark is right: you ought to fix this
(for gmaccm.com as well as for capmark.com).

In message <493B2B5D.40903 at shockley.net>, Steve Shockley wrote:

> I'm running BIND 9.4.2 on OpenBSD 4.3.  I'm getting some errors with 
> named-checkconf I don't really understand.  I'm running:
>
> named-checkzone -t /var/named capmarksecurities.com 
> /master/db.capmarksecurities.com
>
> and I get:
> 
> zone capmarksecurities.com/IN: getaddrinfo(quarantine1.capmark.com) 
> failed: non-recoverable failure in name resolution
[etc.]
> This appears to happen with all zones with MX records that are in a 
> different zone.  The zone loads and seems to work as expected.  What's 
> going wrong?

Something is wrong with the configuration of the host on which you
ran named-checkzone. Either its resolver configuration is screwed,
or getaddrinfo() isn't getting as far as using the resolver. Can
you do host address lookups at all there?

You can suppress the check by using "-i local" on named-checkzone
(see the man page). But it would be better to fix the configuration
problem, of course.

-- 
Chris Thompson
Email: cet1 at cam.ac.uk