Are failures cached?

Wed Apr 30 21:17:35 UTC 2008

> I am listening but perhaps not understanding.
> 
> The TTL coming from COM makes sense but in your earlier response you
> said that failed lookups would be cached for "~10 minutes".

	The lame server cache timeout is 10 minutes.  When named gets
	a response indicating that the server is lame it remembers that
	for 10 minutes.

> Is it
> instead cached based on TTL of COM or the incorrect delegation servers
> even though they didn't provide actual records for the domain?  Or is
> caching of which delegation servers to use themselves that is the issue?

	It's the information learnt from the parent zone.
 
> Not that it really matters but for the record - I didn't make a mistake
> - someone else changed the delegation and we've gotten inconsistent
> statements from the registrar as to who changed it.  Initially they told
> us it wasn't changed by our login.  Later they said it was.  Later yet
> they said it was changed by "someone in Toronto" before reverting to the
> claim that our login had changed it.  We think it was the registrar that
> screwed up but of course can't prove it since we don't have direct
> access to their logs.
> 
> 
> 
> -----Original Message-----
> From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org]=20
> Sent: Tuesday, April 29, 2008 6:49 PM
> To: Jeff Lightner
> Cc: bind-users at isc.org
> Subject: Re: Are failures cached?=20
> 
> 
> > The 2 day TTL you mention is what was on our DNS servers.
> 
> 	Look again at the query.  The TTL there is comming from the
> 	servers for COM, not the servers for WATER.COM.
> 
> > As noted in
> > the original problem our servers weren't being delegated to so that
> TTL
> > shouldn't have mattered.  =3D20
> >=20
> > In fact your response seems to imply I shouldn't have had an issue at
> > all given that the delegation issue was discovered about 5 hours after
> > it occurred.  If folks truly waited 48 hours to do a new lookup they
> > wouldn't have interrogated the wrong DNS servers because they'd have
> > already cached my original records which hadn't changed.
> >=20
> > Again my question isn't about how my servers work but rather why a
> > lookup that returned NO records from the wrongly delegated DNS servers
> > would seemingly have been cached?
> 
> 	You are failing to understand how the DNS works and you are not
> 	listening to someone (me) who first ran a DNS server nearly 20
> 	years ago.
> 
> 	I got my first addresses blocks from the InterNIC in '88 and was
> 	running DNS servers soon after that.
> =20
> > Or to put it another way why did it take only 5 hours (or less) for
> DNS
> > servers that didn't claim to be authoritative for our domain to hose
> us
> > up completely but then take 2-3 days for that to clear once the DNS
> > delegation was corrected?   It seems that at worst it should be the
> same
> > amount of time both ways.
> 
> 	First, things were hosed the moment there was a query using
> 	the bad delegation.  When that first query was really depends
> 	on the old (distributed) cache state prior to the bad
> delegation.
> 
> 	The cleanup time is dependent on the TLL's of the records giving
> 	the bad delegation information.
> 
> 	This is no different from changing a delegation.  It takes
> 	the max(delegation ttl,zone ttl) + zone transfer delays
> 	for a delegation to change to complete provided you have
> 	the old servers for a zone serve the new content.
> 
> 	If you make a mistake with the DNS it is available
> instanteously.
> 	It will be seen once there is a query which can't be answered
> from
> 	cached information.
> 
> 	Mark
> =09
> > -----Original Message-----
> From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org]=3D20
> > Sent: Monday, April 28, 2008 8:15 PM
> > To: Jeff Lightner
> > Cc: bind-users at isc.org
> > Subject: Re: Are failures cached?=3D20
> >=20
> >=20
> > > We had an issue last week where our Registrar displayed incorrect
> DNS
> > > servers for our primary domain for several hours before we realized
> it
> > > and corrected the issue.  We're still investigating how the original
> > > problem occurred but my question isn't about that.   There was no
> > spoof
> > > site corrected as attempts to resolve our domain website or its MX
> > > record returned no information as it wasn't on the (wrong) target
> DNS
> > > servers.
> > > The issue was that it appeared many people (including AT&T) seemed
> to
> > > fairly quickly get the wrong information so quit sending us email
> but
> > > took 2-3 days to get the right information once we'd corrected the
> > > situation.   Are failures to resolve domains cached?
> >=20
> > 	Yes.  ~10 minutes.
> >=20
> > 	Your problem is that the bad delegation records were cached and
> > 	it took some time to flush from caches that learnt the wrong
> > 	values.
> >=20
> > 	Note: the 2 day TTL.
> >=20
> > ; <<>> DiG 9.3.4-P1 <<>> water.com @a.gtld-servers.net
> > ; (2 servers found)
> > ;; global options:  printcmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7566
> > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
> >=20
> > ;; QUESTION SECTION:
> > ;water.com.			IN	A
> >=20
> > ;; AUTHORITY SECTION:
> > water.com.		172800	IN	NS	dswadns1.water.com.
> > water.com.		172800	IN	NS	dswadns2.water.com.
> >=20
> > ;; ADDITIONAL SECTION:
> > dswadns1.water.com.	172800	IN	A	12.44.84.213
> > dswadns2.water.com.	172800	IN	A	12.44.84.214
> >=20
> > ;; Query time: 373 msec
> > ;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30)
> > ;; WHEN: Tue Apr 29 10:13:21 2008
> > ;; MSG SIZE  rcvd: 105
> >=20
> > 	Mark
> >=20
> > > If so are they
> > > cached longer than actual domain records?  Would the TTL for the
> wrong
> > > DNS server be used for a domain for which it wasn't authoritative
> when
> > > determining how long to keep a cached record?
> > > ----------------------------------
> > > CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
> > confidential in
> > > formation and is for the sole use of the intended recipient(s). If
> you
> > are no
> > > t the intended recipient, any disclosure, copying, distribution, or
> > use of th
> > > e contents of this information is prohibited and may be unlawful. If
> > you have
> > >  received this electronic transmission in error, please reply
> > immediately to=3D20
> > > the sender that you have received the message in error, and delete
> it.
> > Thank=3D20
> > > you.
> > > ----------------------------------
> > >=3D20
> > >=3D20
> > --=3D20
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
> > ----------------------------------
> > CONFIDENTIALITY NOTICE: This e-mail may contain privileged or =3D
> > confidential information and is for the sole use of the intended =3D
> > recipient(s). If you are not the intended recipient, any disclosure, =
> =3D
> > copying, distribution, or use of the contents of this information is =
> =3D
> > prohibited and may be unlawful. If you have received this electronic =
> =3D
> > transmission in error, please reply immediately to the sender that you
> =3D
> > have received the message in error, and delete it. Thank you.
> > ----------------------------------
> --=20
> 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