Subject: An interoperability disaster

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Jan 2000 22:16:43 -0000

One of ibm.net's caches, ns1.us.prserv.net, times out right now on
recursive lookups for www.ipapilot.org. Can anyone explain why?

1. As you can see, the ns1.us.prserv.net cache has

   ipapilot.org NS a.ns.ipapilot.org
   ipapilot.org NS b.ns.ipapilot.org

without the corresponding A records.

What could have happened to the A records? The ipapilot.org servers
provide the A records as additional data, with the same TTL as the NS
records.

2. Normal caches recognize this situation and quickly recover from it.
(It's rare, but it does happen, and DNSEXT should document it.)

dnscache, for example, will fall back to the roots. BIND will drop the
query but start a background ``sysquery'' to a higher-level server,
hoping to have the records cached by the time the query is retried.

But this cache simply times out. What could prevent a cache from
recovering?

3. As an experiment, I tried looking up network-surveys.cr.yp.to and
then leap.yp.to a few times through ns1.us.prserv.net.

There was something very strange about the cached results, perhaps tied
to the problems described above: the TTL for the yp.to NS records, and
the TTLs for the corresponding A records, continued to count down, even
though the authoritative leap.yp.to answer came with renewed TTLs.

What could cause a cache to discard the new A records in favor of older
records? The obsolete ``credibility'' rules don't seem relevant here---
the old A records have exactly the same TTL as the NS records, so
presumably they come from additional data, just like the new ones.

---Dan

---

From: Mats Dufberg <[email-masked]>
Date: Wed, 12 Jan 2000 07:00:06 +0100 (CET)

[ all, please move this thread to the bind-users list and dnsop.  -- rb ]

> provide the A records as additional data, with the same TTL as the NS

If it was missing in the delegation from the ORG servers... The delegation
from ORG seems to have been updated (or not updated):

ipapilot.org.   172800  NS      NS2.PALOMINE.NET.
ipapilot.org.   172800  NS      SHEMP.PALOMINE.NET.

According to the nameservers SHEMP.PALOMINE.NET and NS2.PALOMINE.NET the
delegation should be

ipapilot.org.   259200  NS      a.ns.ipapilot.org.
ipapilot.org.   259200  NS      b.ns.ipapilot.org.
ipapilot.org.   259200  NS      c.ns.ipapilot.org.
a.ns.ipapilot.org.      259200  A       205.198.88.200
b.ns.ipapilot.org.      259200  A       205.198.89.22
c.ns.ipapilot.org.      259200  A       205.198.89.22

Start with putting them in sync.

Mats

-----------------------------------------------------------------
Mats Dufberg                                    [email-masked]
NIC-SE                                           +46-8-545 857 06
Box 5774                                    fax: +46-8-545 857 29
SE-114 87 Stockholm                         http://www.nic-se.se/

---

From: [email-masked]
Date: Wed, 12 Jan 2000 15:52:11 +1100

> recursive lookups for www.ipapilot.org. Can anyone explain why?

	Yes.  They have not updated there delegation to reflect the
	zone contents.

   Domain Name: IPAPILOT.ORG
   Registrar: NETWORK SOLUTIONS, INC.
   Whois Server: whois.networksolutions.com
   Referral URL: www.networksolutions.com
   Name Server: NS2.PALOMINE.NET
   Name Server: SHEMP.PALOMINE.NET

> But this cache simply times out. What could prevent a cache from

	When the nameserver asks the com servers for the addresses
	a.ns.ipapilot.org and b.ns.ipapilot.org they return referrals
	to shemp.palomine.net and ns2.palomine.net.  However the
	NS RRset is correctly rejected as not being as credable as
	that from the child zone.

	This would not be a problem if the zone delegation was correctly
	managed.

	Before you make more complaints about credability checks, think
	about the case when zone are actually signed.  To get out of this
	case you would have to throw out signed data in favour of unsigned
	data.
> records?

	To work around other mis-management where old servers are not
	decommisioned or made stealth servers when the delegation is
	changed.  There were cases where customers changes ISP's and
	the old ISP refused to decommision the servers.  Unless we
	allowed the data to time out you would stay locked on the
	old servers.

	Mark

> The obsolete ``credibility'' rules don't seem relevant here---
--
Mark Andrews, Nominum Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]