Excessive Queries [- was Re: Core dumps -]

Original Spanish copy below, I have a feeling this translate is not as  
good as the last one.  Sorry if I do not follow along all that well.   
I do appreciate your response though.

> Forgive Scott by two things:
>
> 1 .- Do not read the thread completely and answered hastily without  
> knowing that you did not refer specifically to DLZ. My answer is  
> based on my experience with DLZ. At least that is how it worked for  
> consultations "dig." To our luck, I do not think that this much  
> impact, since the end DLZ uses the interfaces of bind9 SDB, and  
> treatment apparently appears to be the same in both cases, something  
> which I think is logical.
>
>> Why would it try so hard to locate a record? if you www.example.com
>> no zone, why not return 0 and move on?
>>
>
> At least DLZ (which seems to have a similar bind-sdb RPM),

You know, I have never understood this.  What is the difference of DLZ  
and SDB?

> has no a priori way to respond if this zone (example.com) is  
> supported or not in all records of your database. DLZ simply trying  
> to locate an area to which your DNS server is authoritative and  
> coincides with part of the sub string in the first consultation. One  
> disadvantage I see that this comes at the time to delegate a  
> subdomain, at least I could not do so, if you do, please write in  
> the language you want.

But why does the DLZ or SDB for that matter explode a lookup into all  
it's parts?  If I ask for foo.example.com it should look for  
foo.example.com and stop there.  If there is no record for it, reply  
with no record and be done.

To lookup .com, example.com and foo.example.com is a complete waste.   
At the very least, all domains end in some tld, a caching database of  
the tlds could avoid the .tld lookup entirely.

A database can answer many queries very well.  In this case, I use  
MySql, it has it's limits though.  I believe I would call any MySql  
server that can answer hundreds of queries per second high  
performance.  I now need a pretty high performance MySql server if I  
want to run DLZ with it?

dig a.b.c.d.e***,com where *** is a string of 100 characters long,  
would produce over 100 MySql queries.

http://www.faqs.org//rfcs/rfc1035.html I believe states a domain can  
be only up to 63 characters long.  That could be one limitation there,  
where no part before the tld could be greater than 63 chars, or just  
return no answer.

Am I off base here in that this seems a darn simple way to take out  
any DLZ driven server?

> 2 .- Sorry for not answer you in English, but I do not know what is  
> less professional, if you respond with grammatical errors by using a  
> tool like you or to respond in my native language. Similarly I  
> endeavor to read your questions, so I believe we are on hand. :)  
> Cheers, and hope it will not bother.

No trouble at all.  Your first reply translated really well, this one,  
I managed to fill in the blanks good enough.  Thanks for your time.


On May 8, 2009, at 4:51 AM, Reyner Herrpinark Lugo wrote:

> Perdóname Scott por dos cosas:
>
> 1.- No había leído el hilo completo y respondí apresuradamente sin  
> saber que no te referías al DLZ específicamente. Mi respuesta va  
> basada en mi experiencia con el DLZ. Al menos, así es como se  
> trabajan las consultas hechas por "dig". Para nuestra suerte, no  
> creo que esto repercuta mucho, pues al final DLZ hace uso de las  
> interfaces SDB del bind9, y el tratamiento al parecer resulta ser el  
> mismo en ambos casos, cosa que considero lógico.
>
>> Why would it try so hard to locate a record?  if www.example.com has
> no zone, why not return 0 and move on?
>
> Al menos DLZ (que parece tener un comportamiento similar al RPM bind- 
> sdb), no tiene forma de a priori responderte si esta zona  
> (example.com) es soportada o no dentro de todos los registros de  
> vuestra base de datos. DLZ sencillamente intenta ubicar una zona a  
> la cual tu servidor de DNS es autoritaria y coincida con parte de la  
> sub cadena en la primera consulta. Una desventaja que le veo a esto  
> surge en el momento de delegar un subdominio, al menos no he podido  
> lograrlo, si lo haces, por favor, escríbeme en el idioma que quieras.
>
> 2.- Disculpa por no responderte en inglés, pero no sé qué es menos  
> profesional, si responderte con errores gramaticales por usar una  
> herramienta al igual que tú o responderte en mi idioma nativo. De  
> igual modo yo me esfuerzo para leer sus preguntas, así que considero  
> que estamos a mano. :) Saludos, y espero que no se moleste.

-- 
Scott * If you contact me off list replace talklists@ with scott@ *


------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com