Are failures cached?
Mark Andrews
Mark_Andrews at isc.org
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
More information about the bind-users
mailing list