Problem resolving a domain on my cache server. (part II)

Mark Andrews Mark_Andrews at isc.org
Wed Mar 23 22:55:51 UTC 2005


> 
> > Hi Mark,
> > 
> > I know what you mean. The problem is that my cache server keeps
> > resolving for a while but somehow from time to times this host
> > (www.redecard.com.br) cannot be resolved by my cache server (my server
> > answer with timeout responses). But when this host cannot be resolved by
> > my cache server I setup a script that dig this host directly from their
> > two ns
> > 
> > dig -b mycacheserver_ip_address#the_same_src_port_namded_is_using
> > www.redecard.com.br @200.211.224.110
> > dig -b mycacheserver_ip_address#the_same_src_port_namded_is_using
> > www.redecard.com.br @200.211.224.111
> > 
> > I get positive answers. So I suppose it is not communication fault or
> > their fault.
> > 
> > Don't you think my cache server daemon may be losing something when it
> > tries to resolve this specific host?
> > =20
> > Thanks in advance,
> > 
> > Fabiano
> 
> 	It looks like they are running the Microsoft Windows 2000
> 	nameserver version which has a dead timer after they get a
> 	EDNS query.  It returns a FORMERR then doesn't respond to
> 	EDNS queries from the same IP address for 60 seconds.
> 
> 	This really hurts when there are multiple nameservers behind
> 	a NAT (as they all appear to come from the same address)
> 	but can also hurt a non NAT'd nameserver if the timing is
> 	right.
>  
> 	http://support.microsoft.com/default.aspx?scid=kb;en-us;837928
> 
> 	Bcc'd postmaster at credicard.com.br so they fix their nameserver.
> 
> 	Perform the following two queries.  The first will be
> 	responded to.  The second (and subsequent queries) will be
> 	dropped.
> 
> 	dig +bufsize=512 www.redecard.com.br @200.211.224.111
> 	dig +bufsize=512 www.redecard.com.br @200.211.224.111
> 
> 	Mark

	I ment to add you can use a server clause to disable the use
	of EDNS with these servers until they fix them.

	e.g.
		server 200.211.224.111 {
			edns no;
		};

	Mark

> > -----Original Message-----
> > From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org]=20
> > Sent: Tuesday, March 22, 2005 6:08 PM
> > To: Fabiano Silos Reis
> > Cc: bind-users at isc.org
> > Subject: Re: Problem resolving a domain on my cache server. (part II)=20
> > 
> > 
> > >=20
> > > Hi list,
> > >=20
> > > Some months ago I asked here about a domain I can=3DB4t resolve on my =
> > =3D
> > > cache server because of a firewall on the dns that hosts this domain =
> > =3D
> > > (they were blocking everyone doing queries using source udp port
> > bellow =3D
> > > 53). Today I will ask again about one domain I can=3DB4t resolve on my =
> > =3D
> > > cache server.=3D20
> > >=20
> > > To make sure the problem is not firewall issue again I tested it using
> > =3D
> > > DIG and setting the source ip/port exactly to what named process is =
> > =3D
> > > using to make queries. I receive answer without problems.
> > >=20
> > > Actually I have problem to resolve just one hostname -> =3D
> > > www.redecard.com.br. When I startup my cache server process and make
> > one =3D
> > > query to it I receive the answer from my server. But after some time =
> > =3D
> > > running (and memory cache getting bigger) only this domain stops =3D
> > > working. I=3DB4m not owner of domain redecard.com.br but the problem =
> > is
> > =3D
> > > some of my cache clients are complaining that they could not resolve =
> > =3D
> > > this domain using my cache server. I couldn't understand why and how =
> > =3D
> > > this is happening. I tried some things trying to fix it. Doing rndc =
> > =3D
> > > flusname for some times I can resolve this domain but some times rndc
> > =3D
> > > flushname makes no difference.
> > >=20
> > > Do someone have a clue on how to trace this kind of problem? Is the =
> > =3D
> > > problem my cache or the problem is on a mistake at redecard.com.br dns
> > =3D
> > > servers?
> > >=20
> > > Bellow I will paste my named configure line, version and named.conf. I
> > =3D
> > > would appreciate any help on this.=3D20
> > >=20
> > > Thanks
> > >=20
> > > Fabiano
> > 
> > 	Well they don't have a robust nameserver setup.  There
> > 	are plenty of opportunities for single point failures to
> > 	make both nameservers unreachable when using consecutive
> > 	addresses.
> > 
> > 	Any routing problems will affect both servers simultaneously
> > 	(same AS path).
> > 
> > 	Highly likely that there are common power failure points that
> > 	will make both servers unreachable.
> > 
> > 	Mark
> > 
> > ; <<>> DiG 8.3 <<>> redecard.com.br ns=20
> > ;; res options: init recurs defnam dnsrch
> > ;; got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29000
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
> > ;; QUERY SECTION:
> > ;;	redecard.com.br, type =3D NS, class =3D IN
> > 
> > ;; ANSWER SECTION:
> > redecard.com.br.	59m49s IN NS	canopus1.credicard.com.br.
> > redecard.com.br.	59m49s IN NS	regulus1.credicard.com.br.
> > 
> > ;; ADDITIONAL SECTION:
> > canopus1.credicard.com.br.  52m28s IN A  200.211.224.111
> > regulus1.credicard.com.br.  52m29s IN A  200.211.224.110
> > 
> > ;; Total query time: 0 msec
> > ;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1
> > ;; WHEN: Wed Mar 23 08:02:52 2005
> > ;; MSG SIZE  sent: 33  rcvd: 121
> > 
> > 
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
> > 
> > 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
--
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