-----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 <[EMAIL PROTECTED]>,
>>> Chris Buxton <[EMAIL PROTECTED]> 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-----
