Difference betwen failed request with addit RR and successfull without.

joseangel.martinezdelavara at telefonica.es joseangel.martinezdelavara at telefonica.es
Tue Feb 21 11:08:08 UTC 2006


Hi,
I've been searching since I got your response but could not find a way to
tell my DNS server how to handle EDNS requests anywhere else but on
explicit server directives.

I tried the "edns-udp-size 512;" option under the options section on
named-conf but it refuses to start the process because of "unknown option".
After cheching again the docs I could find it but I cannot be certin if it
can be used as a global option or just works on specific server definitions
(as both edns boolean and the udp size with integer value).

Any suggestion?

Thanks

---
Jose Angel Martinez
TME - Direccion de servicios de valor añadido
joseangel.martinezdelavara at telefonica.es
680011327
629805447


                                                                                                                                       
                                                                                                                                       
                             Mark Andrews                 Para:      joseangel.martinezdelavara at telefonica.es                          
                             <Mark_Andrews at isc.org           cc:     bind-users at isc.org                                                
                             >                           Asunto:     Re: Difference betwen failed request with addit RR and            
                                                           successfull     without.                                                    
                             Enviado por:                                                                                              
                             Mark_Andrews at isc.org                                                                                      
                                                                                                                                       
                                                                                                                                       
                                                                                                                                       
                                                                                                                                       
                             14/02/2006 22:19                                                                                          
                                                                                                                                       
                                                                                                                                       


                                                                           
                Telefónica Móviles España, S.A.                            
                                                                           







Why did you send this twice?

Message-ID:
<OF3176A708.3295FD8C-ONC1257115.004B27A0-C1257115.004E5C66 at telefonica.es>
Message-ID:
<OF3176A708.3295FD8C-ONC1257115.004B27A0-C1257115.004D8C19 at telefonica.es>


> Hi, there.
>
> I am having a weird problem here. It looks like my DNS server manages to
> resolve DNS queries to the internet name servers on fouth attempt.
Sniffing
> on the local interface I can see three unreplied requests sent to three
> different nameservers then a successful one to another one.

             The remote nameservers (or the firewall in front of them)
             is broken.  They are dropping EDNS queries rather than
             following RFC 1034/1035 and returning a error code when
             they get a query they can't interpret.  FORMERR is the most
             natural error code but NOTIMP or even SERVFAIL will work
             though the latter won't stop named sending out EDNS queries
             in the future.

             EDNS has been on the standards track for 6.5 years now.  No
             nameserver / firewall vendor should be selling a nameserver /
             firewall that doesn't understand EDNS anymore.

             Mark

Network Working Group                                            P. Vixie
Request for Comments: 2671                                            ISC
Category: Standards Track                                     August 1999


                  Extension Mechanisms for DNS (EDNS0)


> It would not be so rare if those first NS were dead, but they were not
> since a direct dig to them actually worked (and works).
>
> The only difference among failed and succesfull requests is that failed
> requests have a few more flags active, that is:
> - Non-authenticated data OK (meaning non-authenticated data is
acceptable)
> - Additional RRs flag (so there are additional records)
>
> The additional record present (according to ethereal decode of an snoop
run
> on my dns server) is a type OPT class unknown with the following fields:
> - name: <root>
> - type: EDNS0 option
> - UDP payload size: 2048
> - Higher bist in extended RCODE: 0x0
> - EDNS version: 0
> - Z: 0x0
> - Data length: 0
> - Data:
>
> It cannot be that the response from the servers arrives late because I
run
> snoop for quite some time after the test was finished. So, why are
requests
> without those flasgs active successfull and the others are not.
>
> BTW, those flags were not active on successfull direct requests with dig
> agains external dns servers (bypassing mine).
>
> I am running BIND 9.2.3 on this piece of hardware/software:
> root at mvicprb01b16 # uname -a
> SunOS mvicprb01b16 5.9 Generic_118558-10 sun4u sparc SUNW,Serverblade1
>
> I can provide with the snoop file to read with ethereal if requested, but
I
> do not feel I shoudl be posting a binary file here. :)
>
> Thanks a lot
>
> ---
> Jose Angel Martinez
> TME - Direccion de servicios de valor a𠣩do
> joseangel.martinezdelavara at telefonica.es
> 680011327
> 629805447
>
>
___________________________________________________________________________
>
> Este mensaje se dirige exclusivamente a su destinatario y puede contener
> informaci򬟰rivilegiada o confidencial. Si no es vd. el destinatario
> indicado, queda notificado de que la lectura, utilizaci򬪠divulgaci򬟹/o
> copia sin autorizaci򬟥st�rohibida en virtud de la legislaci򬟶igente.
> Si ha recibido este mensaje por error, le rogamos que nos lo comunique
> inmediatamente por esta misma v쟠y proceda a su destrucci򬬍
>
> El correo electr򭨣o v쟠Internet no permite asegurar la confidencialidad
> de los mensajes que se transmiten ni su integridad o correcta recepci򬬍
> Telef򭨣a no asume ninguna responsabilidad por estas circunstancias.
>
>
> This message is intended exclusively for its addressee and may contain
> information that is CONFIDENTIAL and protected by a professional
privilege
> or whose disclosure is prohibited by law.If you are not the intended
> recipient you are hereby notified that any read, dissemination, copy or
> disclosure of this communication is strictly prohibited by law. If this
> message has been received in error, please immediately notify us via
e-mail
> and delete it.
>
> Internet e-mail neither guarantees the confidentiality nor the integrity
or
> proper receipt of the messages sent. Telef򭨣a does not assume any
> liability for those circumstances.
>
___________________________________________________________________________
>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org

_____________________________________________________________________
Mensaje analizado y protegido, tecnologia antivirus www.trendmicro.es




___________________________________________________________________________

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si no es vd. el destinatario
indicado, queda notificado de que la lectura, utilización, divulgación y/o
copia sin autorización está prohibida en virtud de la legislación vigente.
Si ha recibido este mensaje por error, le rogamos que nos lo comunique
inmediatamente por esta misma vía y proceda a su destrucción.

El correo electrónico vía Internet no permite asegurar la confidencialidad
de los mensajes que se transmiten ni su integridad o correcta recepción.
Telefónica no asume ninguna responsabilidad por estas circunstancias.


This message is intended exclusively for its addressee and may contain
information that is CONFIDENTIAL and protected by a professional privilege
or whose disclosure is prohibited by law.If you are not the intended
recipient you are hereby notified that any read, dissemination, copy or
disclosure of this communication is strictly prohibited by law. If this
message has been received in error, please immediately notify us via e-mail
and delete it.

Internet e-mail neither guarantees the confidentiality nor the integrity or
proper receipt of the messages sent. Telefónica does not assume any
liability for those circumstances.
___________________________________________________________________________From spoo at isc.org  Tue Feb 21 13:01:10 2006
Received: with ECARTIS (v1.0.0; list bind-users); Tue, 21 Feb 2006 13:01:10 +0000 (UTC)
Return-Path: <spoo at isc.org>
X-Original-To: bind-users at webster.isc.org
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by webster.isc.org (Postfix) with ESMTP id 0417C10E418
	for <bind-users at webster.isc.org>; Tue, 21 Feb 2006 13:01:10 +0000 (UTC)
	(envelope-from spoo at isc.org)
Received: by farside.isc.org (Postfix, from userid 107)
	id DA754E60AE; Tue, 21 Feb 2006 13:01:09 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on farside.isc.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 
	autolearn=ham version=3.1.0
X-Original-To: spoo at farside.isc.org
Received: from sf1.isc.org (mx-1.isc.org [IPv6:2001:4f8:0:2::1c])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by farside.isc.org (Postfix) with ESMTP id EB49EE601C
	for <spoo at farside.isc.org>; Tue, 21 Feb 2006 13:01:08 +0000 (UTC)
	(envelope-from Mark_Andrews at isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:208:74ff:fe9f:eeae])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by sf1.isc.org (Postfix) with ESMTP id DA6F62844D
	for <bind-users at isc.org>; Tue, 21 Feb 2006 13:01:07 +0000 (UTC)
	(envelope-from marka at isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
	by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id k1LD13uY069966;
	Wed, 22 Feb 2006 00:01:04 +1100 (EST)
	(envelope-from marka at drugs.dv.isc.org)
Message-Id: <200602211301.k1LD13uY069966 at drugs.dv.isc.org>
To: joseangel.martinezdelavara at telefonica.es
Cc: bind-users at isc.org
From: Mark Andrews <Mark_Andrews at isc.org>
Subject: Re: Difference betwen failed request with addit RR and successfull without. 
In-reply-to: Your message of "Tue, 21 Feb 2006 12:08:08 BST."
             <OFDDEA1CB3.D9F3F099-ONC125711C.003B8B63-C125711C.003D770B at telefonica.es> 
Date: Wed, 22 Feb 2006 00:01:03 +1100
Sender: bind-users-bounce at isc.org
Errors-to: bind-users-bounce at isc.org
Precedence: bulk
List-unsubscribe: <mailto:bind-users-request at isc.org?Subject=unsubscribe>
List-Id: <bind-users.isc.org>
X-List-ID: <bind-users.isc.org>


> Hi,
> I've been searching since I got your response but could not find a way to
> tell my DNS server how to handle EDNS requests anywhere else but on
> explicit server directives.

	Well use them.  The majority of nameserver do handle EDNS just fine.
	The majority of the servers which don't understand EDNS do process
	the EDNS queries as you would expect a RFC 1034 server to.  i.e. they
	send back a FORMERR (or NOTIMP or SERVFAIL).  This introduces a extra
	round trip time the first time you talk to the server.  Subsequent
	queries won't use EDNS until the adb cache entry times out.

	There are very few broken servers which don't respond to EDNS and
	even then named will recover after timing out.
 
> I tried the "edns-udp-size 512;" option under the options section on
> named-conf but it refuses to start the process because of "unknown option".
> After cheching again the docs I could find it but I cannot be certin if it
> can be used as a global option or just works on specific server definitions
> (as both edns boolean and the udp size with integer value).

	Well upgrade to a version which does know about edns-udp-size,
	e.g. BIND 9.3.2.

	Mark
 
> Any suggestion?
> 
> Thanks
> 
> ---
> Jose Angel Martinez
> TME - Direccion de servicios de valor añadido
> joseangel.martinezdelavara at telefonica.es
> 680011327
> 629805447
> 
> 
>                                                                              
>                                                           
>                                                                              
>                                                           
>                              Mark Andrews                 Para:      joseange
> l.martinezdelavara at telefonica.es                          
>                              <Mark_Andrews at isc.org           cc:     bind-use
> rs at isc.org                                                
>                              >                           Asunto:     Re: Diff
> erence betwen failed request with addit RR and            
>                                                            successfull     wi
> thout.                                                    
>                              Enviado por:                                    
>                                                           
>                              Mark_Andrews at isc.org                            
>                                                           
>                                                                              
>                                                           
>                                                                              
>                                                           
>                                                                              
>                                                           
>                                                                              
>                                                           
>                              14/02/2006 22:19                                
>                                                           
>                                                                              
>                                                           
>                                                                              
>                                                           
> 
> 
>                                                                            
>                 Telefónica Móviles España, S.A.                            
>                                                                            
> 
> 
> 
> 
> 
> 
> 
> Why did you send this twice?
> 
> Message-ID:
> <OF3176A708.3295FD8C-ONC1257115.004B27A0-C1257115.004E5C66 at telefonica.es>
> Message-ID:
> <OF3176A708.3295FD8C-ONC1257115.004B27A0-C1257115.004D8C19 at telefonica.es>
> 
> 
> > Hi, there.
> >
> > I am having a weird problem here. It looks like my DNS server manages to
> > resolve DNS queries to the internet name servers on fouth attempt.
> Sniffing
> > on the local interface I can see three unreplied requests sent to three
> > different nameservers then a successful one to another one.
> 
>              The remote nameservers (or the firewall in front of them)
>              is broken.  They are dropping EDNS queries rather than
>              following RFC 1034/1035 and returning a error code when
>              they get a query they can't interpret.  FORMERR is the most
>              natural error code but NOTIMP or even SERVFAIL will work
>              though the latter won't stop named sending out EDNS queries
>              in the future.
> 
>              EDNS has been on the standards track for 6.5 years now.  No
>              nameserver / firewall vendor should be selling a nameserver /
>              firewall that doesn't understand EDNS anymore.
> 
>              Mark
> 
> Network Working Group                                            P. Vixie
> Request for Comments: 2671                                            ISC
> Category: Standards Track                                     August 1999
> 
> 
>                   Extension Mechanisms for DNS (EDNS0)
> 
> 
> > It would not be so rare if those first NS were dead, but they were not
> > since a direct dig to them actually worked (and works).
> >
> > The only difference among failed and succesfull requests is that failed
> > requests have a few more flags active, that is:
> > - Non-authenticated data OK (meaning non-authenticated data is
> acceptable)
> > - Additional RRs flag (so there are additional records)
> >
> > The additional record present (according to ethereal decode of an snoop
> run
> > on my dns server) is a type OPT class unknown with the following fields:
> > - name: <root>
> > - type: EDNS0 option
> > - UDP payload size: 2048
> > - Higher bist in extended RCODE: 0x0
> > - EDNS version: 0
> - Z: 0x0
> > - Data length: 0
> > - Data:
> >
> > It cannot be that the response from the servers arrives late because I
> run
> > snoop for quite some time after the test was finished. So, why are
> requests
> > without those flasgs active successfull and the others are not.
> >
> > BTW, those flags were not active on successfull direct requests with dig
> > agains external dns servers (bypassing mine).
> >
> > I am running BIND 9.2.3 on this piece of hardware/software:
> > root at mvicprb01b16 # uname -a
> > SunOS mvicprb01b16 5.9 Generic_118558-10 sun4u sparc SUNW,Serverblade1
> >
> > I can provide with the snoop file to read with ethereal if requested, but
> I
> > do not feel I shoudl be posting a binary file here. :)
> >
> > Thanks a lot
> >
> > ---
> > Jose Angel Martinez
> > TME - Direccion de servicios de valor a𠣩do
> > joseangel.martinezdelavara at telefonica.es
> > 680011327
> > 629805447
> >
> >
> ___________________________________________________________________________
> >
> > Este mensaje se dirige exclusivamente a su destinatario y puede contener
> > informaci򬟰rivilegiada o confidencial. Si no es vd. el destinatario
> > indicado, queda notificado de que la lectura, utilizaci򬪠divulgaci򬟹/o
> > copia sin autorizaci򬟥st�rohibida en virtud de la legislaci򬟶igente.
> > Si ha recibido este mensaje por error, le rogamos que nos lo comunique
> > inmediatamente por esta misma v쟠y proceda a su destrucci򬬍
> >
> > El correo electr򭨣o v쟠Internet no permite asegurar la confidencialidad
> > de los mensajes que se transmiten ni su integridad o correcta recepci򬬍
> > Telef򭨣a no asume ninguna responsabilidad por estas circunstancias.
> >
> >
> > This message is intended exclusively for its addressee and may contain
> > information that is CONFIDENTIAL and protected by a professional
> privilege
> > or whose disclosure is prohibited by law.If you are not the intended
> > recipient you are hereby notified that any read, dissemination, copy or
> > disclosure of this communication is strictly prohibited by law. If this
> > message has been received in error, please immediately notify us via
> e-mail
> > and delete it.
> >
> > Internet e-mail neither guarantees the confidentiality nor the integrity
> or
> > proper receipt of the messages sent. Telef򭨣a does not assume any
> > liability for those circumstances.
> >
> ___________________________________________________________________________
> >
> >
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
> 
> _____________________________________________________________________
> Mensaje analizado y protegido, tecnologia antivirus www.trendmicro.es
> 
> 
> 
> 
> ___________________________________________________________________________
> 
> Este mensaje se dirige exclusivamente a su destinatario y puede contener
> información privilegiada o confidencial. Si no es vd. el destinatario
> indicado, queda notificado de que la lectura, utilización, divulgación y/o
> copia sin autorización está prohibida en virtud de la legislación vigente.
> Si ha recibido este mensaje por error, le rogamos que nos lo comunique
> inmediatamente por esta misma vía y proceda a su destrucción.
> 
> El correo electrónico vía Internet no permite asegurar la confidencialidad
> de los mensajes que se transmiten ni su integridad o correcta recepción.
> Telefónica no asume ninguna responsabilidad por estas circunstancias.
> 
> 
> This message is intended exclusively for its addressee and may contain
> information that is CONFIDENTIAL and protected by a professional privilege
> or whose disclosure is prohibited by law.If you are not the intended
> recipient you are hereby notified that any read, dissemination, copy or
> disclosure of this communication is strictly prohibited by law. If this
> message has been received in error, please immediately notify us via e-mail
> and delete it.
> 
> Internet e-mail neither guarantees the confidentiality nor the integrity or
> proper receipt of the messages sent. Telefónica does not assume any
> liability for those circumstances.
> ___________________________________________________________________________
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



More information about the bind-users mailing list