Bind 9.4.2 not resolving one domain

[caio]

Chris Buxton escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sep 4, 2008, at 6:08 PM, Barry Margolin wrote:
>> In article <g9no1k$cjm$1 at sf1.isc.org>,
>> Chris Buxton <cbuxton at menandmice.com> wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> That still sounds like a performance problem, as Kevin hinted.
>>>
>>> In this case, the qname is an alias of an alias (bad, but not
>>> uncommon), and all three names are in different zones.
>>>
>>> www.yahoo.com.ar.	1800	IN	CNAME	hp2.latam.g1.b.yahoo.com.
>>> hp2.latam.g1.b.yahoo.com. 300	IN	CNAME	us.hp2.latam.a1.b.yahoo.com.
>>> us.hp2.latam.a1.b.yahoo.com. 300 IN	A	98.136.43.19
>>>
>>> That's at least 9 queries if the cache is empty at the beginning,  
>>> more
>>> if the resolver is verifying glue records.
>> I only count 4 queries:
>>
>> www.yahoo.com.ar to ROOT returns delegation to AR servers
>> www.yahoo.com.ar to AR server returns delegation to ns#.yahoo.com
>> www.yahoo.com.ar to ns#.yahoo.com returns CNAME + delegation to
>> yf#.yahoo.com
>> hp2.latam.g1.b.yahoo.com to yf#.yahoo.com returns second CNAME and  
>> final
>> answer
>>
>> All the delegations included glue records.
> 
> Trusting all glue records that I have any right to trust, I get:
[cut]
> 
> So that's 8 queries (I miscounted, I guess). Sure, if the resolver  
> hits yf{1,2} for the second alias name, that server can give both  
> CNAME and A records. However, only 2 of 7 of those servers are  
> authoritative for both subzones of yahoo.com.
> 
> The only reason the glue in the response to query 5 is usable is  
> because we've already been told that the yahoo.com servers are  
> authoritative for yahoo.com. Otherwise, we'd have to go verify those  
> glue records. However, it's conceivable the resolver might be a bit  
> more paranoid than that, or it may not recognize that this otherwise  
> out-of-bailiwick delegation and glue are reasonable; in that case, add  
> more queries.
> 
> Also, it's conceivable that a resolver may want to validate all glue  
> records, only trusting them long enough to get an authoritative answer  
> containing the same A records. In that case, add a lot more queries.
> 
> Chris Buxton
> Professional Services
> Men & Mice
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> 
> iEYEARECAAYFAkjAuHYACgkQ0p/8Jp6Boi2hwQCguOJSFrCToSgc0bcxvL760cSZ
> OEsAnR22405JcWEtmbFYX8I6ZfqANqrB
> =Slx1
> -----END PGP SIGNATURE-----
> 

sorry guys, but how to fix this problem wasn't clearly understood:
is it due a network issue?
performance issue? (bearing in mind it has only 512MB of RAM)
few cname common configuration?
misconfiguration? a version bug?
do not know why this problem exist only with one domain..

thanks all your answers..

--
caio