Subject: Re: update timing errors

From: [email-masked]
Date: Mon, 24 Feb 2003 08:28:07 +1100

> [email-masked] writes:
> > If you never update the child then it is an *administrative* error.
> 
> Changing the serial number too early is also an administrative error.
> Here's a summary of our three examples of administrative errors:
> 
>    1. Failing to update the parent serial number after updating the glue
>       in all the child servers. As you keep pointing out, this error can
>       cause problems with BIND 8: the data will be inconsistent until
>       the serial number is updated.
> 
>    2. Failing to update the parent serial number after updating the glue
>       in the parent master. This error can cause problems with BIND 9
>       (and BIND 8, of course): the data will be inconsistent until the
>       serial number is updated.
> 
>    3. Failing to update the data in the child master. This error can
>       cause problems with BIND 9 (and BIND 8, of course): the data will
>       be inconsistent until the child data is updated (and the serial
>       numbers handled properly).
> 
> In every case, the administrator is violating RFC 1034 (as you have
> admitted), and is creating a configuration that does not work properly
> with most DNS software deployed in the real world.
> 
> You persist in drawing a completely unjustified line between the first
> error and the other two errors. You claim that allowable administrative
> action is defined by BIND 9---never mind what RFC 1034 says, and never
> mind the rest of the installed base. You cycle endlessly between ``BIND
> 9 is doing the Right Thing'' and ``BIND 9 handles that situation'' and
> ``that situation is not actually an error,'' attempting to defend each
> part of the BIND 9 religion by showing how it fits with the other parts.
> The circularity is pathetic.
> 
> In situations where there's a difference between the software and the
> spec---for example, actions that are prohibited by RFC 1034 even though
> they work in the real world, or vice versa---one can reasonably discuss
> whether the actions should be considered errors. But the above actions
> do _not_ work and are _not_ allowed by the spec. If you want to support
> them in BIND 9, fine, but you have no basis for demanding that the rest
> of us support them too.

	Changing the content of SECONDARY zones is outside of the
	actions specified by RFC 1034.  In fact RFC 1034 demands a
	"accurate" copy.  You can't have a "accurate" copy if it
	has been changed.

	There are no timing issues if you have a "accurate" copy.

	There is no such thing as changing the serial "too early".

	It is the errors in BIND 4, BIND 8 and tinydns that introduce
	timing constraints that are not part of RFC 1034 and only
	affect servers that are serving both parent and child zones.

	We have heard from at least three other independent developers
	that they preserve / preserved the copy of the child zone
	based on RFC 1034 requirement.

	Maintaining consistancy between parent and child zones is
	a administrative responsability.  Even with automated
	assistance the changes are required to be applied to the
	PRIMARY not to the SECONDARY.  BIND 4, BIND 8 and tinydns
	violate the maintance model as a result of applying changes
	in the incorrect place directly leading to the situation where
	all the PRIMARY copies of the zones have the correct information
	but some of the SECONDARY "copies" don't.

	There is no technical reason not to preserve the contents of
	the SECONDARY copies of the zone unaltered.  There are no
	negative effects from doing this.  There definitely are negative
	effects caused by changing the contents of SECONDARY copies.

	All your complaints are based on your interpretation of RFC
	1034.  Your interpretation introduces timing issues which
	even your own software cannot meet without violating the
	requirement to change the serial number when you change the
	zone contents.

	In addition to the pure AXFR issues.  IXFR depends upon the
	contents of the zone not being changed unilaterally on the
	SECONDARY.  Failure to preserve the contents will result
	in deltas not applying that should.  This should result in
	fallback to AXFR to get a upto date copy of the zone.  This
	will result in a AXFR style IXFR to done stream servers.

	Mark

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

---

From: Paul Vixie <[email-masked]>
Date: Sun, 23 Feb 2003 23:01:53 +0000

ok mark, that's it.  no more replies are warranted.  if mr. bernstein
still misunderstands zone coherency, then someone who doesn't work for
ISC will have to take a turn trying to educate him.  we're done. --paul

ps. great answer btw.

re:

> X-Original-To: [email-masked]
> To: "D. J. Bernstein" <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked]
> From: [email-masked]
> Subject: Re: update timing errors 
> Date: Mon, 24 Feb 2003 08:28:07 +1100
> Sender: [email-masked]
> 
> 
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Feb 2003 00:18:09 -0000

[email-masked] writes:
> actions specified by RFC 1034.

Fact: Slaves _must_ discard records in some situations. A detailed
example appears in http://cr.yp.to/djbdns/axfr-notes.html#poison.
(There are many other counterexamples to your ``no reason'' claim.)

Fact: Slaves _do_ discard records in many situations. You claim that
this is ``wrong'' solely because it can break certain configurations.
You have admitted that RFC 1034 clearly prohibits those configurations.

> timing constraints that are not part of RFC 1034

Fact: As you have already admitted, RFC 1034 _does_ impose these timing
constraints. As you have already admitted, RFC 1034 prohibits even the
slightest configuration inconsistency. In previous messages, you were
complaining about how severe the RFC 1034 consistency requirement is!

Fact: As above, your sole basis for calling the widespread BIND-8-etc.
behavior an ``error'' is that it doesn't work with your broken
configurations. Your sole basis for claiming that the configurations
aren't broken is _some_ DNS servers support them.

Fact: These broken configurations are going to continue to fail for the
foreseeable future. (As http://cr.yp.to/surveys/dns1.html shows, BIND 8
is more widely used than BIND 9.) It is essential for interoperability
that these broken configurations continue to be prohibited. Demanding
support for them would impose costs on at least two independent
implementations, without providing any benefits for the users.

Fact: Making the configurations work is a simple matter of updating the
parent---most importantly, the parent serial number---after (or at the
same time as) all the child servers are updated. This rule is easy for
administrators to follow.

> All your complaints are based on your interpretation of RFC 1034.

Fact: There are no relevant disputes about the interpretation of RFC
1034. When I pointed to the sections of RFC 1034 that you are violating,
you admitted your violations.

> change the serial number when you change the zone contents

Fact: That's part of what RFC 1034 requires. However, that's not even
close to a complete description of an RFC-1034-compliant glue-update
procedure. More importantly, it's not a complete description of a
glue-update procedure that works in practice.

> IXFR depends upon

Fact: IXFR is an optional protocol extension. It is entirely IXFR's
responsibility to maintain compatibility with the preexisting,
unextended, protocol. It is not the responsibility of the installed base
to change for the sake of new protocol options.

Fact: When a protocol extension causes failures with most of the
software deployed on the Internet, you can't safely use the extension
without waiting for a massive upgrade. Users are much happier with an
extension that, at comparable cost, avoids the failures and provides
the same benefits immediately. I have explained to you how to do this
in the case of IXFR.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: [email-masked] (Andreas Gustafsson)
Date: Sun, 23 Feb 2003 18:39:10 -0800 (PST)

D. J. Bernstein writes:
> Fact: Slaves _must_ discard records in some situations.

This claim has no basis in the standards.

> A detailed example appears in http://cr.yp.to/djbdns/axfr-notes.html#poison.

This is an interesting example and worth discussing in its own right;
I have changed the subject line in the hope that this discussion can
be kept somewhat separate from the usual flamage.  Quoting your
example:

> Suppose that an ISP is simultaneously a third-party DNS server for
> .edu and a third-party DNS server for princeton.edu.
> 
> Suppose the ISP pulls the princeton.edu zone from a Princeton AXFR
> server, and receives the data
> 
>      haven.princeton.edu NS serv1.net.yale.edu
>      serv1.net.yale.edu A 128.112.128.15
> 
> from the AXFR server. The point of the following analysis is that the
> ISP must discard the yale.edu information.
> 
> An innocent user's cache has the legitimate record
> 
>      yale.edu NS serv1.net.yale.edu
> 
> saved. The user asks for the address of www.haven.princeton.edu. The
> cache contacts the root server, learns that the ISP is a .edu server,
> contacts the ISP, and receives the same information
> 
>      haven.princeton.edu NS serv1.net.yale.edu
>      serv1.net.yale.edu A 128.112.128.15
> 
> that the ISP obtained from the Princeton server. Because the ISP is a
> .edu server, the cache trusts and saves the serv1.net.yale.edu
> information. The user now asks for the address of www.yale.edu. The
> cache knows yale.edu NS serv1.net.yale.edu and serv1.net.yale.edu A
> 128.112.128.15, so it contacts 128.112.128.15 to obtain the address of
> www.yale.edu. In short, Princeton has been given control over the Yale
> web server.

I agree that this is a real problem that ought to be solved.  However,
there are several ways of solving it, and I do not think your solution
(making slaves discard certain records in zone transfers) is the best
solution.  For one thing, it does not solve the case where the ISP is
the *master* for the domains in case.

It is an unfortunate fact that the existing DNS standards do not
adequately address the issue of cache poisoning.  They do not even
address the simpler cases that can arise even when all domains are
hosted on distinct servers, much less the more subtle case you
describe above.  They do not even recommend, much less mandate, the
simple but effective resolver-side anti-spoofing measures that BIND 8,
BIND 9, and dnscache all currently employ and that you are taking for
granted in your example above when you say "because the ISP is a .edu
server, the cache trusts and saves the serv1.net.yale.edu information.

My own preference would be for solving this problem on the resolver
side, by using more discriminate anti-spoofing rules than the ones
BIND 8/9 and djbdns currently use.  Another possibility is to make the
servers refrain from giving out the glue in responses in situations
like the above even though it is stored and preserved for purposes of
outgoing zone transfers.  In any case, none of the possible solutions
are standardized at this time, and until they are, no one is required
to use any particular solution, and that includes your solution of
"discarding records".

> When I first mentioned this type of attack, the BIND 9 implementors
> claimed that it was safe for the ISP to provide the serv1.net.yale.edu
> information as glue for haven.princeton.edu.

There was a discussion where I said it was safe to provide cross-zone
glue, but in that discussion no mention was made of the server also
being authoritative for "edu", which makes a subtle but important
difference.
-- 
Andreas Gustafsson, [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Feb 2003 04:00:21 -0000

> This claim has no basis in the standards.

Anti-poisoning rules are required for security. I'm not going to bother
addressing the irrelevant question of whether the de-facto standards in
DNS security can be deduced from the de-jure standards.

You have some anti-poisoning rules in BIND 9 (and BIND 8). We all know
that they're necessary: some records have to be discarded. Consequently,
any claim such as ``all records must be preserved'' is obviously wrong.
When religious rhetoric crashes into security, we all know who wins.

Yes or no: Does the specific attack described on my web page work
against BIND 9? I'll give you three days to issue a security release
before I send a message to bugtraq. Or are you using the defense stated
on my web page, discarding records on the client side of an AXFR?

> where the ISP is the *master* for the domains

Different situation, but same solution: discard all records outside the
source's bailiwick. End of problem.

> more discriminate anti-spoofing rules

Namely? Exactly what would you suggest in place of the de-facto-standard
bailiwick rule? (You realize, of course, that deploying a new rule would
take time.)

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 24 Feb 2003 15:40:56 -0800 (PST)

D. J. Bernstein writes:
> against BIND 9?

It does not.  BIND 9 is currently incapable of storing out-of-domain
glue records (i.e., records whose owner name is not a subdomain of the
zone apex), whether it is acting as a primary or a secondary.
Therefore, it will discard such records whether they are loaded from a
master file or received as part of a zone transfer.  This might be
considered either a security feature or a bug depending on your point
of view.

> source's bailiwick. End of problem.

Yes, requiring all authoritative servers (masters and slaves) to
discard out-of-domain glue would solve the problem you described.  If
we do this, slaves to conformant masters will never actually discard
any records because anything that the slave would discard has already
been discarded by the master, and the integrity of the zone will be
preserved as required in axfr-clarify section 4.

> bailiwick rule?

What Masataka Ohta suggested in August 2001:

 Ohta> I have been suggesting that these records be put in a referral-local
 Ohta> cache content of which is not used for usual A query nor glue A of
 Ohta> other referral points.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 Feb 2003 00:50:42 -0000

A moment ago we were being told how vitally important it was for AXFR
clients to preserve all records received under all circumstances:

   * ``An ACURATE [sic] copy of the zone is ESSENTIAL'';
   * ``A modified zone is NOT a [sic] ACURATE [sic] copy. It's not
     even a copy. It is a derived work'';
   * ``IXFR depends upon the contents of the zone not being changed
     unilaterally on the SECONDARY'';
   * ``Bernstein still misunderstands zone coherency''; etc.

This rhetoric is supposed to convince you that the majority of AXFR
clients (BIND 8 et al.) are doing something wrong by discarding parent
glue records when they have the authoritative child records.

But now Gustafsson admits that the BIND 9 AXFR client doesn't follow
the ``zone coherency'' religion. It deliberately discards some kinds of
records! It isn't making a perfect copy of the zone! It's breaking IXFR!
Here's the quote: ``BIND 9 ... will discard [these] records whether they
are loaded from a master file or received as part of a zone transfer.''

To summarize: Not only is the BIND company (1) fraudulently labelling
its religion as a ``clarification'' and (2) fraudulently claiming
``consensus'' on the religion over the objections of several people,
but it is also (3) deliberately disobeying its own commandments.

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 24 Feb 2003 20:50:18 -0800 (PST)

> records! It isn't making a perfect copy of the zone! It's breaking IXFR!

BIND 9 is doing what you yourself said it "must" do.

This does not by itself break IXFR.  In theory, IXFR can break when
the zone transfer graph contains both servers that fully support
out-of-zone glue and servers that do not, but in practice no servers
support out-of-zone glue and the problem does not occur.  This is of
course another argument for completely outlawing out-of-zone glue in
both masters and slaves as you already suggested doing for security
reasons.  Mandating support for out-of-zone glue everywhere would also
work, but outlawing it does seem like the more realistic approach.

In practice, IXFR failures are likely to be caused by inconsistencies
in-domain glue, not out-of-domain glue, and the in-domain case is what
section 4 is primarily trying to address.
-- 
Andreas Gustafsson, [email-masked]

---

From: "Kandra Nygards" <[email-masked]>
Date: Tue, 25 Feb 2003 12:13:20 +0100 (CET)

> records! It isn't making a perfect copy of the zone! It's breaking
> IXFR! Here's the quote: ``BIND 9 ... will discard [these] records
> whether they are loaded from a master file or received as part of a
> zone transfer.''

Excellent point. You're perfectly right, of course.

According to my understanding of this argument, BIND9 (and tinydns etc)
must preserve any out-of-zone records it receives in an AXFR, for the
purposes of transfering a non-modified zone to other servers via AXFR.
It MAY, of course, discard such records when it loads its data from a
master file or outer source of master configuration, as well as discard
such records for non-AXFR responses to queries.

May I assume that you're supporting the AXFR-clarify draft as long as the
above clarification is made?

Best regards
Kandra Nygards

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 25 Feb 2003 18:52:43 +0100 (CET)

> purposes of transfering a non-modified zone to other servers via AXFR.

Yes, specifically (section 4, paragraph 4 of axfr-clarify-05):

   The slave MUST associate the RRs received in a zone transfer with the
   specific zone being transferred, and maintain that association for
   purposes of acting as a master in outgoing transfers.

> such records for non-AXFR responses to queries.

Yes, specifically section 4, paragraph 3:

   Therefore, in a zone transfer the master MUST send exactly those
   records that are associated with the zone, whether or not their owner
   names would be considered to be "in" the zone for purposes of
   resolution, and whether or not they would be eligible for use as glue
   in responses.

'Exactly' in this instance should imply that case is preserved, as per
1035 2.3.3 , although you'd only get into trouble with not doing this when
tossing IDN zones around.

> above clarification is made?

You seem to be 35 days early.

--==--
Bruce.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 Feb 2003 18:39:45 -0000

Kandra Nygards writes:
> May I assume that you're supporting the AXFR-clarify draft as long as
> the above clarification is made?

Of course not.

The existing draft is inconsistent with RFC 1034, inconsistent with most
of the installed base, and---as Gustafsson now admits---inconsistent
with BIND 9. Your additional ``clarification'' doesn't change this; it
simply highlights BIND 9's failure to follow the rules.

Furthermore, even if the wacko zone-coherency requirements are dropped,
axfr-clarify will still need to be fixed in several other ways.

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 25 Feb 2003 18:17:50 -0800 (PST)

> tossing IDN zones around.

RFC1035 section 2.3.3 says case should be preserved "when possible",
but also notes that there are cases where it is not possible.  It is
not always possible to preserve case in zone transfers because of
domain name compression in the transfer messages, and I did not mean
to imply that case would be preserved.

IDN must deal with case not being preserved, and as far as I know it
does.  So does IXFR.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 28 Feb 2003 16:06:35 -0800 (PST)

On the IETF list, Claus Färber wrote:
> I think the only requirement that's really essential is that the serial
> number changes whenever the data that would be returned by a zone
> transfer changes (even if that breaks database consistency for the SOA
> record's serial number).

It is also essential that two different authoritative servers that
show the same serial number actually serve the same data.

> One strategy to implement this would be to keep an exact copy of a zone
> obtained from other servers for outgoing transfers (so you'll always use
> the original serial number), which is the BIND 9 strategy.
> 
> Another strategy would be to just increment the serial number of a zone
> when it is actually changed by importing glue records from another zone.
> This would solve the synchronisation problem, too: If the parent zone is
> updated too early, the server might throw away the glue record. But it
> will update the parent zone and increase its the serial number when it
> gets an up-to-date copy of the child zone.

In principle, this approach could work on the primary master server
(at least assuming the zone serial number is being maintained by the
server rather than the administrator), but it won't work on a slave.

If a slave "imports" glue into a zone, it can't update the serial
number, and even if it could, that wouldn't make the zone contents
consistent with the master.

Followups to namedroppers, please.
-- 
Andreas Gustafsson, [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 1 Mar 2003 00:43:19 -0000

> show the same serial number actually serve the same data.

That's a wild exaggeration. For example, a pure slave can do anything it
wants with its serial numbers. In fact, unless one slave pulls the zone
from two different masters, serial-number coherency is irrelevant.