Bind 9.4.2 not resolving one domain

[Chris Buxton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Look at performance issues of your network connection. It's also  
possible that the server itself is being overtaxed.

The problem appears to be that looking up this name requires a very  
large number of lookups, and that your connection to certain parts of  
the Internet is simply too slow to get them all done in time.

You might have to consider forwarding queries to a resolving name  
server with faster bandwidth.

Chris Buxton
Professional Services
Men & Mice

On Sep 8, 2008, at 4:20 AM, caio wrote:

> 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
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjFxukACgkQ0p/8Jp6Boi0wqwCdH/WLDegwDVUM2PEoQe8yXShb
tH8AoKBWeNBU2vy0qeklBZBNIqNVFHW2
=lwbs
-----END PGP SIGNATURE-----