Re: BIND 9.5.0b2 named-checkzone gives false diagnostic messages

5 msg	view for a zone?
1 msg	Re: Recursion ceases for 5-10 minutes at random...
6 msg	Bind and possible redundancy flaw.

BIND 9.5.0b2 named-checkzone gives false diagno...
\ Niall O'Reilly (20 Feb 2008)
. \ Mark Andrews (21 Feb 2008)
. . \ Niall O'Reilly (21 Feb 2008)

2 msg	debugging
1 msg	BIND 9.4.2 Debian setup
2 msg	Compiling 9.4.2 on Solaris10 127111-05 gcc 3.4....
9 msg	Domain unresolved in Singapore
2 msg	bind9.4.1-P1 prints log message time as GMT?
3 msg	Slave DNS Server: what the significance of sh m...
2 msg	Calculating QPS
2 msg	dig segment fault
3 msg	named executables not found in my box ;(Copied ...
3 msg	Bind listening on IPs it shouldn't
2 msg	linux blog for sys administrators
2 msg	Strange failure with recursive zen.spamhaus.org...
3 msg	allow-update to localhost and (but not or) TSIG...
2 msg	named forcestart ,not working -FreeBSD-6.2-Release
6 msg	Delegation
3 msg	Understanding concepts

Subject:	Re: BIND 9.5.0b2 named-checkzone gives false diagnostic messages
Group:	Bind-users
From:	Niall O'Reilly
Date:	21 Feb 2008

On 21 Feb 2008, at 00:32, Mark Andrews wrote:

> s/CNAME/ALIAS/

and please also s/..illegal.//
as there is no basis for making such an assertion.

> getaddrinfo() reports relay.esat.net as being a ALIAS.
>
> Yes, we could go and make a A and also make a AAAA query
> rather than making them indirectly by calling getaddrinfo().

That would be a better (and, IMHO, the right) method. Using
getaddrinfo() involves too many levels of (administrative)
indirection.

> getaddrinfo() may use /etc/host and NIS. It should however
> return the fully qualified name.

It can at best return _a_ fully qualified domain name. Defining
what _the_ fully qualified name should be involves assumptions
which cannot be relied on.

> If it isn't then you have
> /etc/host or NIS misconfigured or you have a broken getaddrinfo()
> implementation.
>
> Note: the "out of zone" queries will always be problematic as
> they are not made in the context of the view in which the
> zone is held.

Of course. What should be checked here is the content of
the (as we might call it) relevant "companion" zone, not some
arbitrarily chosen, more distantly related information. The
companion zone is related directly to the zone being checked,
as it is referenced in RDATA. Performing the equivalent of
a reverse lookup on the data found in the companion zone
(whether via PTR, NIS, or /etc/hosts) involves a second
"relationship hop"; that's just too tenuous in a situation
which, as you say, is already "problematic".

Best regards,

Niall O'Reilly
University College Dublin IT Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9