Bind 9.4.2 not resolving one domain
caio
elcaio at gmail.com
Mon Sep 8 11:20:14 UTC 2008
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
More information about the bind-users
mailing list