Subject: Primary also being secondary

From: Gunnar Lindberg <[email-masked]>
Date: Mon, 28 Jun 1999 15:11:57 +0200 (MET DST)

I'm not sure if this belongs here, but I am sure you'll redirect :-).

This is real life, although I've modified some names to make it a
little less confusing.  SW is bind-8.1.2.

: chalmers.se.              IN NS ns1.chalmers.se.                 pri
:                           IN NS ns2.chalmers.se.                 sec
:
: hemmet.s-hem.chalmers.se. IN NS glutus.hemmet.s-hem.chalmers.se. pri
:                           IN NS ns1.chalmers.se.                 sec

So, this is a delegated subdomain, where the upper domain's primary is
also secondary for the delegated domain. Straight forward. Between
them they share NS(hemmet.s-hem.chalmers.se) info, and this is where
my report/question comes in.

Now, the people at hemmet.s-hem.chalmers.se screwed up their NS info:

: hemmet.s-hem.chalmers.se.
:     IN NS glutus.hemmet.s-hem.chalmers.se.hemmet.s-hem.chalmers.se.
:     IN NS ns1.chalmers.se.hemmet.s-hem.chalmers.se.

We've all done this at least once...

ns1.chalmers.se noticed the higher version number and fetched the zone,
including the erronous NS(hemmet.s-hem.chalmers.se). This did *not*
change the SOA version for zone chalmers.se.

Later on, there were other changes made to zone chalmers.se and the
SOA version was changed. ns2.chalmers.se noticed and fetched the data;
and now got the erronous NS(hemmet.s-hem.chalmers.se) - the erronous
one that ns1.chalmers.se fetched some time ago and obviously installed
in zone chalmers.se.

The people at hemmet.s-hem.chalmers.se soon found the error, fixed it
and incremented their SOA version. ns1.chalmers.se fetched again, with
correct info this time. However, SOA(chalmers.se) was not updated, so
ns2.chalmers.se did NOT fetch any new data; instead it was stuck with
the erronous NS(hemmet.s-hem.chalmers.se) info.

My conclusion is that, at least in bind-8.1.2, the delegated zone's
version of the shared NS-info gets precedence over the delegating
zone's version (the config file). Although I can see cases where this
may be good and useful I'm not sure this is generally so - the case
above is one counter example. I've not found anything in the RFCs
that tell which one is considered "correct" or even "better".

My 1c is that this is wrong and that the data sent to a secondary,
i.e. AXFR, should be the original data from the config file(s), and
not be a "copy of a copy".

	Gunnar Lindberg

---

From: Edward Lewis <[email-masked]>
Date: Mon, 28 Jun 1999 10:38:39 -0400

>that tell which one is considered "correct" or even "better".

RFC 2181 (Clarifications to DNS):
#6.1. Zone authority
...
#   another zone.  The NS records that indicate a zone cut are the
#   property of the child zone created, as are any other records for the
#   origin of that child zone, or any sub-domains of it.  A server for a
#   zone should not return authoritative answers for queries related to
#   names in another zone, which includes the NS, and perhaps A, records
#   at a zone cut, unless it also happens to be a server for the other
#   zone.

So, the child's is authoritative, the parent's is merely glue.

>not be a "copy of a copy".

Since the parent's zone file copy of the child's set of servers is glue,
and the child is also local to the server, the parent's set is forgotten.
But you seem to have identified a situation where the protocol is not
fail-safe.  I am not convinced that this is something that has to be fixed
- perhaps, perhaps, the occurrances of mismatched parent-child sets is more
commonly erring in favor of the child and perhaps you have witnessed an
unfortunate incident.

I suggest that you post your message to [email-masked] for more
discussion.  That is a forum that deals with such issues more frequently,
since this may turn out to be a BIND-ism and not a DNSism.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda

Opinions expressed are property of my evil twin, not my employer.

---

From: Peter Koch <[email-masked]>
Date: Mon, 28 Jun 1999 17:15:56 +0200

> the erronous NS(hemmet.s-hem.chalmers.se) info.

We've seen this a couple of times even with 2nd level domains. One
recommendation I'd derive from this is that the primary (ar any master)
for a zone should not run as a secondary for a delegated zone. However,
this is in conflict with advice from years ago, when it was usually a good
idea to also serve child zones. Also it is in conflict with RFC2317 practice,
where for efficiency reasons you'd run secondary service for the child
zones on the/all parent zone's auth servers.

So, in your case, if ns2.chalmers.se becomes a (stealth) slave for
hemmet.s-hem.chalmers.se - probably a good idea anyway - the problem you
noticed should be avoided.

Anyway, it's a feature, not a bug, due to zone boundary enforcement.

-Peter

---

From: [email-masked]
Date: Tue, 29 Jun 1999 01:21:54 +1000

> that tell which one is considered "correct" or even "better".

	When you delegate authority you delegate the authority for ALL
	record types (NXT is a special case).  The child zone is always
	correct.

	NOTE: If the rules about which copy of the NS rrset were reversed
	you can create the same error by switching the roles around.

> not be a "copy of a copy".
	BIND 8 is limited in that there is one big database.  BIND 9 will
	have seperate databases for each zone.  AXFR (and IXFR) will send
	the NS list from the parent zone but answer from the child zone
	when queried for the NS RRset.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Henk Langeveld - ENS Europe <[email-masked]>
Date: Mon, 28 Jun 1999 17:24:41 +0200

> commonly erring in favor of the child and perhaps you have witnessed an

I believe BIND actually includes a "stub" directive as a hint for a parent
that's acting as a secondary for a child.  I'm too lazy now to look up
the details.  Look at the bind doc.

Henk

---

From: Robert Elz <[email-masked]>
Date: Tue, 29 Jun 1999 10:41:05 +1000

Date:        Mon, 28 Jun 1999 15:11:57 +0200 (MET DST)
    From:        Gunnar Lindberg <[email-masked]>
    Message-ID:  <[email-masked]>

  | My 1c is that this is wrong and that the data sent to a secondary,
  | i.e. AXFR, should be the original data from the config file(s), and
  | not be a "copy of a copy".

Yes, it is a bug.    Servers should not be modifying data in a zone
without incrementing the serial number.

The primary server (ns1) which is also a secondary for a sub-domain should
certainly return the answers from the sub-domain when it is queried, those
are more authoritative.   But that answer is coming from the zone which
contains the sub-domain.

When it is asked to transfer the parent zone, it should be transferring that
one, and not a mangling of the parent and child zones.

The example you showed is one case where this happens, there are a few
others as well.

In bind, this has been a long standing bug since day 1, and it is very nice
to hear that bind 9 will (finally) fix it.

kre

---

From: Gunnar Lindberg <[email-masked]>
Date: Tue, 29 Jun 1999 09:46:09 +0200 (MET DST)

>From [email-masked]  Mon Jun 28 17:23:23 1999
>From: [email-masked]
>Message-Id: <[email-masked]>
>To: Gunnar Lindberg <[email-masked]>
>cc: [email-masked]
>Subject: Re: Primary also being secondary 
>In-reply-to: Your message of "Mon, 28 Jun 1999 15:11:57 +0200."
>Date: Tue, 29 Jun 1999 01:21:54 +1000

>	record types (NXT is a special case).  The child zone is always

Hm :-).

Besides: If I delegate a subdomain, one could think *I* am the one to
decide who it's delegated to, i.e. which NS:s should be trusted.

>	you can create the same error by switching the roles around.

Yes and no.

Yes, I can screw up the upper zone just like everybody else.

But, No, when I've screwed up and correct the error, I will increment
the version number and thus the secondary will eventuelly get correct
data. What happened here was that the upper zone's secondary had in-
correct data, stamped with THE SAME VERSION NUMBER as the updated,
correct, data and thus this error could have persited for ever.

This may be minor in real life, but I'm anyhow glad to hear than BIND9
will do it differently.

	Gunnar

---

From: [email-masked]
Date: Tue, 29 Jun 1999 18:35:21 +1000

> decide who it's delegated to, i.e. which NS:s should be trusted.

	No.  You delegate responsability to the person who's contact
	address is listed in the SOA.  It is his, not your,
	responsability to ensure nameservers are configured.
	Ensuring that the parent zone has the correct NS list by
	informing you when the NS list changes.  Ensure that you learn
	about changes to glue address records.

> correct, data and thus this error could have persited for ever.

	And if you were to reverse the roles the secondary for the
	child zone would get the bad data with THE SAME VERSION NUMBER
	and then be handing it out.

	Mark