Difference betwen failed request with addit RR and successfull without.

[Mark Andrews]

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ñadido
> joseangel.martinezdelavara at telefonica.es
> 680011327
> 629805447
> 
> ___________________________________________________________________________
> 
> 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