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
> informacirivilegiada o confidencial. Si no es vd. el destinatario
> indicado, queda notificado de que la lectura, utilizacidivulgaci/o
> copia sin autorizacist�rohibida en virtud de la legislaciigente.
> 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 electro v쟠Internet no permite asegurar la confidencialidad
> de los mensajes que se transmiten ni su integridad o correcta recepci
> Telefa 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. Telefa 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
> > informacirivilegiada o confidencial. Si no es vd. el destinatario
> > indicado, queda notificado de que la lectura, utilizacidivulgaci/o
> > copia sin autorizacist�rohibida en virtud de la legislaciigente.
> > 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 electro v쟠Internet no permite asegurar la confidencialidad
> > de los mensajes que se transmiten ni su integridad o correcta recepci
> > Telefa 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. Telefa 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