Subject: Re: axfr-clarify's fraudulent claims of consensus

From: [email-masked]
Date: Tue, 18 Feb 2003 13:27:28 +1100

> On Sat, Feb 15, 2003 at 05:10:46PM +1100, [email-masked] wrote:
> > 	Your software (and BIND 8) causes operational problems by not
> > 	preserving zone contents.
> [...]
> > 	Senario 1.
> 
> In order to understand your claim about the operational problems while
> using djbdns, could you tell us how Scenario 1 is accomplished with
> tinydns/axfrdns? Could you give us a URL pointing at a webpage that
> contains the output of your experiments?
> 
> > 	You update example.com adjusting
> > 	its serial.  
> 
> In particular, could you tell us what is the relevance of the serial
> number to tinydns's update procedures?
> 
> 
> > 	Senario 2.
> 
> [...]
> 
> > 	This is a common implemention error caused by trying to
> > 	stuff all zones into a common database.  BIND 4 got it
> > 	wrong.  BIND 8 got it wrong.
> > 
> > 	You want us all to keep repeating this mistake.
> 
> But I thought djbdns did _not_ get it wrong.  Or if you think it did,
> could you show us the experiment that verifies the claim, that is, it
> accomplishes Scenario 2 with tinydns/axfrdns servers?
> 
> Mate
> 
> Mate Wierdl | Dept. of Math. Sciences | University of Memphis  
> 
> --
> 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/>

	It's easy enough to demonstate.  The master server is 10.53.0.2.
	10.53.0.1 is dbj's software.   I used the FreeBSD port system to
	install it.

djbdns-1.05_2       A collection of secure and reliable DNS tools

tcpclient 10.53.0.2 53 axfr-get child.example.net zone.child.example.net zone.child.example.net.tmp
tcpclient 10.53.0.2 53 axfr-get example.net zone.example.net zone.example.net.tmp
sort -u zone.* > data
make

	You will note that it actually *merges* the records.
	ns2.child.example.net doesn't exist due to a typo in
	child.example.net.  I was taking Dan's word that it
	took the child data.

	Merges are just as bad as taking data just from the child
	zone.  In both cases slaves off 10.53.0.1 will be left with
	data that was not in the original master files.

	I presume for a real world server that you would need to
	call tcpclient periodically and remake data if the zone
	files have changed.   It looks like they axfr-get is
	designed to be called independently of the database make.

	I suspect no-one would run tinydns in the senarios described.
	It's designed for a collection of servers that all serve a
	identical set of zones from a single master.  Trying to use
	it in any other configuration is just cumbersome.  There
	really is no incoming zone maintanence.  You have to roll
	your own from what I can see.  axfr-get will check the
	serial but that is far short of full zone maintenance.
	axfr-get get need to be called with the right periodicity.

	Mark

; <<>> DiG 9.3.0s20021115 <<>> axfr child.example.net @10.53.0.2
;; global options:  printcmd
child.example.net.	10	IN	SOA	. . 1 3600 1200 360000 10
child.example.net.	10	IN	NS	ns1.child.example.net.
child.example.net.	10	IN	NS	ns2.child.example.net.
ns1.child.example.net.	10	IN	A	10.53.0.1
ns1.child.example.net.	10	IN	A	10.53.0.2
child.example.net.	10	IN	SOA	. . 1 3600 1200 360000 10
;; Query time: 43 msec
;; SERVER: 10.53.0.2#53(10.53.0.2)
;; WHEN: Tue Feb 18 11:50:46 2003
;; XFR size: 7 records (messages 1)

; <<>> DiG 9.3.0s20021115 <<>> axfr child.example.net @10.53.0.1
;; global options:  printcmd
child.example.net.	10	IN	SOA	. . 1 3600 1200 360000 10
child.example.net.	10	IN	NS	ns1.child.example.net.
child.example.net.	10	IN	NS	ns2.child.example.net.
ns1.child.example.net.	10	IN	A	10.53.0.1
ns1.child.example.net.	10	IN	A	10.53.0.2
ns2.child.example.net.	10	IN	A	10.53.0.2
child.example.net.	10	IN	SOA	. . 1 3600 1200 360000 10
;; Query time: 5 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Feb 18 11:51:02 2003
;; XFR size: 8 records (messages 7)

; <<>> DiG 9.3.0s20021115 <<>> axfr example.net @10.53.0.2
;; global options:  printcmd
example.net.		10	IN	SOA	. . 1 3600 1200 360000 10
example.net.		10	IN	NS	ns1.example.net.
example.net.		10	IN	NS	ns2.example.net.
child.example.net.	10	IN	NS	ns1.child.example.net.
child.example.net.	10	IN	NS	ns2.child.example.net.
ns1.child.example.net.	10	IN	A	10.53.0.1
ns2.child.example.net.	10	IN	A	10.53.0.2
ns1.example.net.	10	IN	A	10.53.0.1
ns2.example.net.	10	IN	A	10.53.0.2
example.net.		10	IN	SOA	. . 1 3600 1200 360000 10
;; Query time: 3 msec
;; SERVER: 10.53.0.2#53(10.53.0.2)
;; WHEN: Tue Feb 18 11:52:04 2003
;; XFR size: 11 records (messages 1)

; <<>> DiG 9.3.0s20021115 <<>> axfr example.net @10.53.0.1
;; global options:  printcmd
example.net.		10	IN	SOA	. . 1 3600 1200 360000 10
child.example.net.	10	IN	NS	ns1.child.example.net.
child.example.net.	10	IN	NS	ns2.child.example.net.
example.net.		10	IN	NS	ns1.example.net.
example.net.		10	IN	NS	ns2.example.net.
ns1.child.example.net.	10	IN	A	10.53.0.1
ns1.child.example.net.	10	IN	A	10.53.0.2
ns1.example.net.	10	IN	A	10.53.0.1
ns2.child.example.net.	10	IN	A	10.53.0.2
ns2.example.net.	10	IN	A	10.53.0.2
example.net.		10	IN	SOA	. . 1 3600 1200 360000 10
;; Query time: 5 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Feb 18 11:51:30 2003
;; XFR size: 12 records (messages 11)

; <<>> DiG 9.3.0s20021115 <<>> ns child.example.net @10.53.0.1
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56624
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;child.example.net.		IN	NS

;; ANSWER SECTION:
child.example.net.	10	IN	NS	ns1.child.example.net.
child.example.net.	10	IN	NS	ns2.child.example.net.

;; ADDITIONAL SECTION:
ns1.child.example.net.	10	IN	A	10.53.0.1
ns1.child.example.net.	10	IN	A	10.53.0.2
ns2.child.example.net.	10	IN	A	10.53.0.2

;; Query time: 1 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Feb 18 12:11:45 2003
;; MSG SIZE  rcvd: 119

; <<>> DiG 9.3.0s20021115 <<>> ns child.example.net @10.53.0.2
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12751
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;child.example.net.		IN	NS

;; ANSWER SECTION:
child.example.net.	10	IN	NS	ns2.child.example.net.
child.example.net.	10	IN	NS	ns1.child.example.net.

;; ADDITIONAL SECTION:
ns1.child.example.net.	10	IN	A	10.53.0.1
ns1.child.example.net.	10	IN	A	10.53.0.2

;; Query time: 1 msec
;; SERVER: 10.53.0.2#53(10.53.0.2)
;; WHEN: Tue Feb 18 12:12:02 2003
;; MSG SIZE  rcvd: 103

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

---

From: [email-masked]
Date: Wed, 19 Feb 2003 11:54:30 +1100

> Good. You found a bug in an implementation. I thought such things were
> off-topic for this list.  This bug doesn't mean that AXFR is broken.
> Bind 8 did not have this bug, yet it has the common understanding of AXFR.
> 
> Let me summarize the discussion:
> 
> Everyone agrees that AXFR specification in RFC 1034 is ambiguous.
> 
> Some people, many associated with Bind 9 development, assert that it is
> necessary to change AXFR to support IXFR.  This assertion has been refuted
> on the grounds that incremental database update does not depend on AXFR,
> since incremental database update does not depend on the underlying wire
> protocol used to create the remote database which is to be modified by
> IXFR. Conceivably, it is unnecessary to use AXFR at all, yet one could
> still use IXFR, so, AXFR is independent of IXFR.

	Nobody is saying that preserving zone content is a *wire*
	issue.  It is a server behaviour issue.

> Some people, many associated with Bind 9 development, assert that AXFR as
> commonly implemented by many implementors over many years, is broken, and
> can't transfer domains correctly.  This claim has been refuted by
> demonstration by interoperability between Bind 8 and other nameserver
> implementations over the years, and 77% of the internet that currently
> does not use Bind 9, yet still does AXFR.

	All this shows is that these nameservers are not used in
	situations where the breakage is demonstrated or the
	administators have learn to work around the breakage or
	choose to live with it or are unaware of it.

> There being no other arguments raised for the Bind 9 AXFR
> clarify/modification proposal, it seems that this proposal is gratuitous
> and unnecessary, and should be rejected.
>
> However, we still have the issue of AXFR ambiguity to deal with, and we
> still need to clarify those ambiguities.  I would therefore like to
> organize a small group of people using implementations other than Bind 9,
> which we declare to be broken, to document the common implementation
> assumptions made, and submit that as a clarification to RFC 1034
> 
> To prevent confusion between the two proposals, I would like to rename the
> first proposal "Bind 9 AXFR Modification", and the second proposal "AXFR
> Clarification". The term "axfr-clarify" will not be used.
> 
> 		--Dean

---

From: [email-masked]
Date: Wed, 19 Feb 2003 14:42:22 +1100

> On Wed, 19 Feb 2003 [email-masked] wrote:
> 
> Zone definition and content is not an AXFR issue.  Server administrators
> provide the definition of zone boundaries. (RFC 1034 Section 2.3 and
> elsewhere)  AXFR merely gives the contents of the zone as has been defined
> according to the boundaries and content specified by the administrator.

	Well BIND 9 does this.  CISCO's server does this according
	to John.  BIND 8 doesn't always.  BIND 4 doesn't always.
	DJBDNS doesn't always.  This is independent of the method
	used to transfer the zone to these servers or enter the
	zone contents on these servers.

> The contents could be given to the secondary by FTP or other method.  If
> you mean to change the definition of zone contents, then I would say this
> proposal is hugely mis-labeled.

	It's not changing the definition.  It is preserving the
	definition.

	It's not mis-labeled.  It is stating the implict assumption
	that AXFR transfers what is entered as the zones contents.
	Nothing more, nothing less.

> All the IXFR server needs to do is determine (by some implementation
> dependent, administrator maintained method) what has changed between one
> zone version and another. How it does this is nobody's business but the
> administrator and the implementor. There are infinite possibilities, here.
> One could, for example, store differences in a series of files. The
> administrator could even make the differnce files by hand--this is an
> _implementation detail_. The IXFR server just sends a series or sequences
> consisting of a list of deleted RRs and a list of added RRs to an IXFR
> client. There is nothing more to it. (notwithstanding the optional
> condensation.)

	All of which is irrelevent to this issue.

> The IXFR client must simply make the changes (again, by some
> implementation dependent, administrator maintained method) to the zone by
> deleting RRs and adding RR's in each sequence. The original version of the
> zone might have been obtained by FTP (or quantum interference, or the
> psychic network) for all we know.

	Well the problem is that you have to get the *original* version,
	not a corrupted version.  AXFR implementations are not returning
	the data originally entered.
 
> This isn't rocket science, and doesn't require any AXFR changes. Nor does
> it require that the zone boundaries be defined only in some certain way,
> beyond the definition of zone boundaries given by the system
> administrator.

	It does however require that for a given serial number that all
	sources of the zone have supplied identical contents.  You should
	be able to apply a IXFR delta to a copy derived from any source
	and have it apply without error.
 
> "administrators have learn[ed] to work around [it,...] live with it [,] or
> are unaware of it".  Agreed.  Having done so, we don't want to stir the
> pot.

	LOL.
 
> Essentially, you are putting more (unnecessary) constraints on
> implementations, and thus on the administrators, who are supposed to be
> pretty free to define the zone boundaries.  Of course, the specifics of an
> implementation puts some constraints on the adminstrator, but the
> administrator can choose a different implementation more to her liking.

	The constaint was already there and it is necessary for reliable
	operation of the DNS.
 
> These unnecessary constraints are a "bad thing".
>
> I presume agreement on the name change?

	No.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Feb 2003 06:30:22 -0000

> ; <<>> DiG 9.3.0s20021115 <<>> axfr child.example.net @10.53.0.2
  [ claims that ns2.child.example.net doesn't exist, as compared to: ]
> ns2.child.example.net.	10	IN	A	10.53.0.2

Once again: That configuration violates RFC 1034. Specifically, sections
4.2.1 and 4.2.2 of RFC 1034 make crystal clear that the ns2 glue in the
parent zone is supposed to match the data in the child zone.

My software enforces the RFC 1034 requirement in this situation. If it
had been running on 10.53.0.2 then you wouldn't have been able to screw
up the configuration in the first place.

What you're complaining about is my software's perfectly straightforward
enforcement of the RFC 1034 requirement on the client side after you set
up an RFC-1034-violating configuration with your server. Is it really so
difficult to understand that it's your fault for violating RFC 1034?

  [ complaining about zone transfers in tinydns ]
> You have to roll your own from what I can see.

No, you don't. Have you ever heard of ``third parties''? How about
``interchangeable parts''? Monolithic design is good for a company
trying to achieve lock-in, but modular design leads to faster evolution
and, in the end, better software for the users.

If you're trying to say that I haven't bothered to write up the existing
AXFR tools on my web pages, you're right. These tools have an extremely
limited audience; I have better things to do. The vast majority of users
are much happier with rsync+ssh than they would ever be with anything
based on AXFR. See http://cr.yp.to/djbdns/tcp.html#intro-axfr.

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

---

From: [email-masked]
Date: Thu, 20 Feb 2003 10:56:45 +1100

> THAT's what I have been saying. You were the one who said we needed to do
> this to support IXFR. I've been saying that claim was wrong. Thanks for
> FINALLY coming round to that.
> 
> They sure have been.

	Not always.
 
> None of this is relevant. All that is necessary is to delete the RRs, and
> insert the RRs in the sequence.
> 
> If the zones are inconsistent through administrative mistake, then it
> won't matter what the IXFR does.

	Who said anything administrative mistakes?  The content is being
	unilaterally changed by the servers.
 
> Strange, that was my reaction, too. I'm just trying to be polite.  77%
> work just fine. We don't want to break 77% of the servers out there.

	You really think that it will break those servers?  LOL.
 
> No, you ware not being honest about the contents of the Draft. See my last
> message to Andreas.

	The abstract say:

				    This memo clarifies, updates, and
   adds missing detail to the original AXFR protocol specification in
   RFC1034.

	I fail to see how the contents can be deemed misleading when
	it states up front what it does.  Woops we missed warning you
	up front that it contains a warning.
 
> > > > > To prevent confusion between the two proposals, I would like to renam
> e th
> > > e
> Then the entire draft should be rejected since it is misleading.  Please
> resubmit a proposal that isn't misleading the community about its purpose,
> impact, and contents.
> 
> 		--Dean

---

From: [email-masked]
Date: Fri, 21 Feb 2003 09:33:24 +1100

> > > > > deleting RRs and adding RR's in each sequence. The original version o
> f th
> > > e
> You haven't shown any proof of that.  The "proof" you showed, was the
> result of a misconfiguration.

	No.  It is the result of operational reality.  Whenever you
	have a parent and child zones under different administrative
	controls it is impossible to change both zones simultaniously.
	It is also impossible using AXFR or any other mechanism
	which transfers *individual* zones to transfer them to a
	secondary and guarantee that they will arrive simultaniously.

	Having parent and child zone under different administrative control
	is the norm not the execption.

> It is reasonable and necessary to merge in glue. When you misconfigure the
> glue, strange things may happen. That is all that you have shown.  I'm
> sure that many software programs will exhibit even stranger behavior, and
> may even fail to operate as a result of misconfiguration.

	No.  It is neither reasonable nor necessary.  Any temporary
	inconsistancies will be corrected when all the zone transfers
	complete.  By changing the zones contents you create
	situations where these temporary inconsistancies won't be
	corrected.  When handing out non axfr/ixfr responses you
	use the best source of data you have.

	Nothing in RFC 1033 / 1034 / 1035 says that a server is permitted
	to alter the content of a zone.  The responability for maintaining
	consistancy between zones is a administrative function.
 
> They will not be compliant, and thus will need to be changed. Thus, they
> would be broken by definition of not being compliant.

	So.  Just because they will not be compliant doesn't mean
	that that they need to be replaced immediately.  That
	non-compliance doesn't hurt most of them.  For those where
	it does have a negative impact it will mean that they should
	be able to request a fix from their vendor.

> Your failure to comprehend the consequences of the changes does not lessen
> the effect.  We now agree that these changes aren't necessary to support
> IXFR. You were part of the bad engineering that led to the unnecessary
> creation of these changes in Bind 9.  You were also part of the bad
> decision making that led to the distribution of these changes to Bind 9
> users prior to standardization, and quite possibly you were part of the
> bad decision making that resulted in publishing a book on the subject,
> prior to acceptance of your modifications to standards. In short, you have
> shown bad judgement.

	I never said that they we not necessary for IXFR.  I said that
	that your descripition of how to generate the differences was
	irrelevent to this discussion.

	It was bad engineering to merge the data sets together in the
	first place.  It was not required by RFC 1033/ 1034 / 1035.
	It had negative consequences.  It was good engineering to
	correct this.  It was also good engineering to report a
	common error to the community so that other vendors could
	fix their mistakes.
 
	Good engineers learn from their mistakes and try hard not
	to repeat them.  They also learn from the mistakes of others.
	That's why bridge designs are wind tunnel tested these days.

> Trying to "belittle" the effects with the "LOL", as opposed to offering
> anything substantive, simply suggests that you have no appreciation of the
> seriousness of the changes.  Perhaps you should take this more seriously.

	I'm quite aware of what the change requires.  I'm also aware
	that most of the nameserver are used in situations where
	the zone contents is already preserved because they are not
	serving zones with parent / child relationships.

	Anyone saying that all the nameservers need to be replaced
	immediately is spreading FUD.  LOL the the correct reponse
	to FUD.
 
	Using a server that perserves zone contents under all
	conditions doesn't break anything.

> > > > > pretty free to define the zone boundaries.  Of course, the specifics 
> of a
> > > n
> I've no doubt that you fail to see it. We seem to be focusing a lot on
> your failures. I have to question whether someone who went to MIT could
> really fail so often. Perhaps it has changes since I was there. Or perhaps
> you aren't really taking this very seriously. Let me explain it:
> 
> 1) It doesn't say that it adds a completely new, incompatible zone
> transfer protocol.  New protocols should be made through a different
> process, which includes experimentation. I'm not against experimenting
> with a new protocol. Indeed, I think this idea has some merit. However, it
> can't be "end-run standardized" by a "clarification". There is a process.

	It isn't new.  All it is saying is that the contents tramitted
	out MUST be that transmitted in.  This occurs most of the time
	already.  Note BIND is not the only implementation that does
	this.  We have already had reports of 3 other implementations
	doing this.  Even the implementations that don't guarentee the
	contents do this most of the time.  It has no negative effects.

> 2) It doesn't say that it changes AXFR with respect to SIG

	It doesn't change anything wrt to SIG.  Go read RFC 2535 which
	also says that SIG records in the answer section are part of the
	zone contents and don't need special processing.
 
> 3) It doesn't say that it changes the status of other RFC's (RFC 2845, and
> possibly others.) without going through the appropriate standards process.

	It doen't change the status of RFC 2845.
 
> 4) It doesn't say that it changes the definition of zone data to be
> public. Zone data is absolutely not "public by definition". It could very
> well be useful to tag certain RRs as non-public, and exclude them from
> zone transfers to public servers. This "clarification" precludes that.
> This is really 2 changes.

	Nowhere in RFC 1033 / 1034 / 1035 does it say that zone transfers
	are restricted to secondaries.  Nowhere in RFC 1033 / 1034 / 1035
	does it say that you should restrict zone tranfers.
 
	There is a REFUSED rcode so the possibility of refusing a zone
	transfer is allowed for but the conditions underwhich this will
	be done are not specified.  This draft does not change this.

> 5) It doesn't say that it changes the security constraints on a zone
> transfer to be limited to deny or accept only.

	Effective it does.  If you transmit the zone then you MUST
	transmit its full contents unmodified (accept).  It also
	says that you are allowed to refuse zone transfers (deny).

> The list is longer, but that should be enough.

---

From: [email-masked]
Date: Fri, 21 Feb 2003 14:57:53 +1100

> On Fri, 21 Feb 2003 [email-masked] wrote:
> 
> Actually, a parent always has some control over the child. It exercises
> this control through the glue records.  When the glue records are in the
> child zone, they need to be merged.

	Which is it.  Does the parent control the contents of its zone
	or does the child?

> If a zone transfer happens while they
> are inconsistent, it is possible for some strange results to happen.
> Ordinarilly, zone transfers don't happen when they are inconsistent, since
> the inconsistency is usually short.

	It doesn't matter if they normally happen while they are
	consistant.  You have to get correct behaviour while they
	are inconsistant.  Changing zone content on SECONDARY servers
	is not correct behaviour.
 
> Any zone transfers made during the inconsistent window are corrected so
> long as the child zone is updated with correct information after the
> parent is updated.

	This is a incorrect statement.
 
> Frequently the parent and child zone are under different administrative
> control, and are frequently on different servers. In such a case, the
> contents of the parent zone aren't merged with the child in the child's
> server, and no evidence of the inconsistency is seen through zone
> transfers. However, the inconsistency still exists and may still be
> visible by resolvers and nameservers that lookup the glue records.

	Nobody is claiming that inconsistancies don't occur all the
	time.  What we are claiming is that those inconsistancies
	need to be preserved in SECONDARY servers for the correct
	operation of the DNS.  That they can only be corrected by
	modifying the PRIMARY source of the zones.
 
> You have obtained no benefits by these constraints.

	There are clear benefits in preserving zone contents on
	SECONDARY servers.
 
> It is necessary, since the parent has glue records in the child zone.
> The parent therefore has (always) a part of the child zone. If that server
> also loads the child zone (or perhaps generates part of it dynamically),
> it quite reasonable to merge the records as though the zone includes
> multiple files, which in theory, it does.

	No it isn't.  Changes need to come from the PRIMARY source not
	from intermediate sources.
 
> The child zone contents will only be correct when the administrators of
> both zones agree on the contents of the glue records, and update their
> parts of the child zone accordingly. It will not be correct until then,
> regardless of how many zone transfers take place.

	Which is what I've been saying all along.  It doesn't require
	a server to "correct" the content at a intermediate point.  Such
	"corrections" actually cause problems.
 
> This is a loaded statement. The part of the server NOT involved in
> responding to queries and zone transfers is part of the administrative
> function. So, as part of that administrative function, it has to be able
> to modify the RR and zones accordingly.  Your proposed changes exclude a
> huge part of the potential for intelligence in name servers. And do so
> with no benefits.

	The benefits are correct operation of the DNS regardless of the
	propogation timings involved.  If servers don't modify slave zone
	content then which the master servers are brought into sync all
	the servers will be brought into sync.

	This is not guarenteed if the zone content is modified by a
	secondary server.
 
> You seem to make a case that in general, non-compliance doesn't hurt
> anything. This is false, for both technical and commercial reasons.
> Technically, it hurts interoperability, which has some many obvious harms
> I won't go into them. Commercially, implementations make and advertise
> compatibility and standards compliance claims. This retroactively makes
> those claims false, which harms the business and reputation of those other
> vendors.

	They will be harmed much more if they don't correct a common
	error now that it has been pointed out.

	The claims were made in good faith and will be accepted as
	such.
	
> 77% will need a fix from the vendor, if we were to accept these changes.
> 
> The vendor that made false claims of compatibility and standards
> compliance is Bind 9. It should suffer the commercial damage to its
> business and reputation, as a result.

	BIND 9 conforms to RFC 1034.  Nothing in RFC 1034 says to
	merge zone content.  If fact 1034 says that this a administrative
	responsability.
 
> Ok, you are half way there. They are irrelevant because IXFR is
> irrelevant. These changes are not necessary to IXFR, as I explained that
> IXFR can work with the current AXFR, or even without AXFR.

	IXFR cannot work through SECONDARY servers that change zone
	content regardless of whether the content was learnt via
	AXFR or IXFR.

> Actually, since the parent has the glue in the child zone, it has part of
> the child zone as well as the master zone.  Merging them together is not
> prohibited, and in the case where child and parent have the same
> adminstrator, as might be the case where most of the child is simply
> automatically generated by the nameserver, can make things much easier.
> 
> Your constraints preclude this unnecessarilly.

	The constraint in on the SECONDARY server.
 
> Since I can think of cases where it is useful to merge records together,
> it is bad engineering to remove that flexibility and obtain no benefits in
> return.
> 
> Apparently, you aren't even aware that your changes will make all non-bind
> 9 servers non-compliant.  Had you been aware of that, it seems you would
> have brought this proposal forward something like 3 years ago, before
> releasing Bind 9, and before publishing a book on the subject.

	Well you obviously have not been reading.  ISC is not the
	only vendor to come to the same conclusion about preserving
	zone content.  I suspect that they are just bored with
	arguing with you and Dan.
 
> Making 77% of the servers non-compliant is a fact of your proposed
> changes.  It is another fact, as explained, that non-compliant servers
> will need to be replaced.  Will they suddenly stop working? It depends on
> whether other implementations want to implement a "backwards
> compatibility" mode. If they don't implement this mode, then the answer is
> yes, they will stop working as soon as these updates are deployed by other
> vendors. Of course, this is a bad result.

	Well they havn't stopped working in the last two years that
	this code has been out there.  Nothing in this drafts stops
	a server implementing it taking to any other server.

	There is one backwards compatiblity switch which is only
	requires if you decide to send multiple records in a single
	messages.  A server is not required to send multiple records
	in a single message.

> Your constraints break useful services, and offer no value in return.

	What's useful about modifing the contents of a slave zone?  All
	I can see is harm.
 
> No, Section 3.1 is a whole new derivative of AXFR. That is new.

	Actually it's always been allowed by RFC 1034.  Just because
	it wasn't implement initially doesn't mean that it was not
	allowed.
 
> Oh. Then section 3.3 can be deleted in entirety without objection.
> 
> The IEFT index indicates that RFC 2845 is "Proposed Standard", with no
> applicability statement that I could find.  This changes it to
> "RECOMMENDED" requirement level.  I think an applicability statement is
> premature until RFC 2845 is moved along, and then by the appropriate
> standards body decision-making process. It is inappropriate to hide
> something like this deep in an irrelevant "clarification".
>
> I don't think you understood my statement. I'm talking about the
> definition of zone data. Nowhere does 1034 etc say that zone data is
> public.  It may well have been thought to be public, originally, but since
> I can easily see a useful purpose in withholding some private RRs, there
> isn't any reason to preclude that behavior.

	Does this address your concerns?

   "The zone transfer protocol allows read-only access to the complete
   zone data.  When the data being served to the public it is
   generally acceptable to allow unrestricted access to it via AXFR.
   Sites that wish to avoid disclosing their full zone data MAY
   restrict zone transfer access to authorized slaves."

	If you have part of a zone to which you would normally
	return REFUSED to I suggest that you also return REFUSED
	to AXFR.

	If you want to be able to return partial zones then I suggest
	that a new TYPE be defined so that receipients can know
	that the results will be incomplete.

> Your constraints harm a useful purpose, and provide no benefits.
> Your modifications put additional and unnecessary restrictions on a zone
> transfer. Again, these restrictions have no useful purpose.

> This was addressed in the previous comments.
> 
>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Feb 2003 06:37:25 -0000

[email-masked] writes:
> Whenever you have a parent and child zones under different administrative

False.

Set the clocks correctly, and schedule the change on all the servers for
a particular time, using (for example) the tinydns timestamp feature
described in http://cr.yp.to/djbdns/tinydns-data.html. When that time
rolls around, all the servers will change their data simultaneously, as
RFC 1034 requires.

Yes, this is difficult to achieve with BIND, AXFR, etc. But it's easy to
achieve with better software, better replication protocols, etc. You're
making a fool of yourself when you call it ``impossible.''

---

From: [email-masked]
Date: Fri, 21 Feb 2003 18:23:53 +1100

> You seem not to understand the subtlety of the issue. The parent (like
> real parents) ultimately controls the child, but the child (like real
> children) has limited autonomy.

It is a subtle issue.  You can only apply changes to the PRIMARY source
of the data.  Applying changes at any other point has the potential to
cause servers to serve incorrect content.
 
> Sure it is. Unless you can arrange to conduct both updates simultaneosly.
> While it would be possible to coordinate such changes on the phone,
> relativity could come into play someday.  It has nothing to do with zone
> transfers. Its part of the state of the system. Zone transfers is only one
> way to learn about the state of the system.

Changing the content of zones in SECONDARY servers prevents other SECONARY
servers using the first SECONDARY server learning the correct state of the
system.
 
> Could you elaborate?

	Server A master to parent.
	Server B master to child.
	Server C slave to parent and child.
	Server D slave to parent using C as master.

	All servers with NS RRset N of child zone.

	Server B updates NS RRset to N'.
	Server A updates NS RRset to N'.
	Server C transfers parent from A.
	Server D transfers parent zone from C.
	Server C transfers child zone from B.

	End state with modification (BIND 8/tinydns).
	Server A N', Server B N', Server C N', Server D N.

	End state without modificatin (BIND 9).
	Server A N', Server B N', Server C N', Server D N'.

	You will notice that the last transfer above was the transfer of
	the child zone.
 
	Now lets update the child last.

	Server A updates NS RRset to N'.
	Server B updates NS RRset to N'.
	Server C transfers parent from A.
	Server D transfers parent zone from C.
	Server C transfers child zone from B.
	
	End state with modification (BIND 8/tinydns).
	Server A N', Server B N', Server C N', Server D N.

	End state without modificatin (BIND 9).
	Server A N', Server B N', Server C N', Server D N'.
	
	You will notice that the last transfer above was the transfer of
	the child zone.

	Lets wait for the parent zone to propogate to all servers
	before updating the child zone.

	Server A updates NS RRset to N'.
	Server C transfers parent from A.
	Server D transfers parent zone from C.
	Server B updates NS RRset to N'.
	Server C transfers child zone from B.

	End state with modification (BIND 8/tinydns).
	Server A N', Server B N', Server C N', Server D N.

	End state without modificatin (BIND 9).
	Server A N', Server B N', Server C N', Server D N'.

	Now if you force everyone to wait until the child zone
	has progated.

	Server B updates NS RRset to N'.
	Server C transfers child zone from B.
	Server A updates NS RRset to N'.
	Server C transfers parent from A.
	Server D transfers parent zone from C.
	
	End state with modification (BIND 8/tinydns).
	Server A N', Server B N', Server C N', Server D N'.

	End state without modificatin (BIND 9).
	Server A N', Server B N', Server C N', Server D N'.

	You will notice that in all examples BIND 9 ends in the correct
	state.  The same cannot be said for BIND 8 or tinydns.

	Modification of SECONDARY zone content is NOT required or desirable
	for the correct operation of the DNS.

> ???  I can't parse this with respect to your previous statements. Could
> you rephrase it?

	You make changes at the PRIMARY server for the zone.
	You do not make changes to zones anywhere else.

> During the period in which the zone is inconsistent, there is no guarantee
> the zone will work.  Depending on the nature of the change, wrong
> information may be given in queries as well. Suppose the parent is
> removing control from the child, and has updated the glue to remove
> referals to the child nameservers. For some time (the TTL, at least), the
> original child servers will be queried.

	What does this have to do with this draft?
 
> On the other hand, the child zone may not even exist yet on the childs
> nameservers.  Referals to the zone fail.

	What does that have to do with this draft?
 
> To make a concrete example, Osama registers alquaeda.com, and begins
> coordinating his evil deeds. The registrar delegates the alquaeda.com as a
> child of .com. Eventually, the government intervenes, and .com replaces
> Osamas nameserver glue with new glue pointing to government servers. For a
> time, this zone will be inconsistent. Note that in this case, the zone
> transfers will not indicate the inconsistency.  However, for a short time,
> Osama will be able to put up a message warning his followers not to go to
> the government run site. This can't be avoided, no matter what gyrations
> you put AXFR through.

	What has this got to do with this draft?
 
> It makes no difference that the inconsistency _could_, _in_some_cases_, be
> seen at the secondaries.

	It does make a difference as demonstated above.
 
> Such as?
> Your term "preserving zone contents" is misleading. The zone contents are
> not corrupted. The glue is inconsistent.  What is the benefit of
> preventing any trace of inconsistency in the secondary?

	It may be inconsistant but which version is correct?  The copy
	in the child may be out of date.
 
> It has nothing to do with IXFR. It has nothing to do with anything.

	IXFR still requires the content to only be changed in response
	to IXFR deltas.
 
> The intermediate sources aren't making changes. They are, at worst,
> propogating old information mixed with new information. However, this is
> visible in other ways besides zone transfers.

	You are changing the contents if you mix data from different zones.
 
> Good. Then you agree that Bind 8 behavior is correct.

	BIND 8 "corrects" data at intermediate points.  BIND 9 doesn't.
	BIND 8's behaviour is wrong.
 
> We already have correct operation of DNS. The zone contents are
> inconsistent until both adminstrators come to agreement. The child zone
> should be updated last. After the child zone is brought into agreement
> with the parent glue, zone transfers will be made which are correct. Only
> then will zone transfers will be correct.  Zone transfers made while the
> administrators are not in agreement will not be correct, even if there is
> no apparent evidence in the zone data from the child (such as a mixture of
> new and old glue) they are still incorrect. NS Queries against the parent
> and child servers will return different results.

	What have you been smoking?
 
> > > > > > > Strange, that was my reaction, too. I'm just trying to be polite.
>   77
> > > %
> Except, there are no errors, beyond a window of inconsistency that cannot
> be avoided, and in fact, that window isn't fixed. Nor do you fix the
> "error". They are _still_ inconsistent for a period. And the child will
> _still_ have to be updated last.

	You obviously don't understand the problem
 
> I'm not convinced.  If they were, we would have argued this before Bind 9
> was released, and before a book was sent out. Probably about 3 years ago.
> Someone knew years ago when they wrote the "backward compatibility" mode,
> that they had a protocol issue that would have to come before
> namedroppers.  That they delayed for so long doesn't indicate good faith
> to me.

	We having been saying for years before BIND 9 was released that
	that BIND 8 had this wrong.  BIND 9 conforms to RFC 1034.

	Axfr-clarify arose because it was pointed out that IXFR depended
	upon the definition of AXFR and that AXFR was not well specified.

> It does right now, due to a knowingly reckless exploitation of ambiguity
> in the AXFR. Once AXFR is clarified, Bind 9 will have to use its 'backward
> compatibility' mode to be compliant.

	What "reckless" exploitation? 
 
> It is "knowingly reckless" because the Bind 9 implementers _KNEW_ they
> needed to provide a "backward compatibility". That means they knew what
> they were doing was incompatible with any (all actually) reasonable
> interpretation (however ambiguous) of 1034.

	The only thing that requires a backward compatability switch
	is sending multiple records in a message.

	BIND 4 accepted these back in 1996.  Other vendors started
	accepting these back in 1996.  BIND 8 has always accepted
	them and could be configured to send them.  BIND 9 defaults
	to sending them and can be configured not to.

	At the same time as this was happening other vendors also
	started sending them.  We all knew that there was interoprability
	issues that were a result of oversites in the implementation.
	One vendor even made use of the fact that named (and I
	presume other servers) didn't barf on a oversized query to
	signal to it servers that they could send a multi-record
	respones.
 
> > > > > Your failure to comprehend the consequences of the changes does not l
> esse
> > > n
> > > > > prior to acceptance of your modifications to standards. In short, you
>  hav
> > > e
> > > > > shown bad judgement.
> > > >
> Sure it can.  It doesn't need AXFR at all.  And the secondary's aren't
> making arbitrary changes at all.

	If servers wern't making arbitary changes we would not be having
	this discussion.

> So? It is still unnecesary.

	Next you will tell me that the grass is blue and the sky is green.

	If you can't see the need for the constraint stop blocking those
	that do.

> > > > > anything substantive, simply suggests that you have no appreciation o
> f th
> > > e
> I think they just haven't really read the proposal's, and have taken some
> misleading assurances at face value.
> 
> Uhh, wrong. The drafts make the current AXFR non-compliant. There is
> nothing that would require a server to implement the old AXFR and provide
> a "backwards compatibility" mode such as Bind 9 has.

	So you want

   "Slaves MUST accept messages containing any number of answer RRs.  For
   compatibility with old slaves, masters that support sending multiple
   answers per message SHOULD be configurable to revert to the
   historical mode of one answer per message, and the configuration
   SHOULD be settable on a per-slave basis."

	replaced with

   "Slaves MUST accept messages containing any number of answer RRs.  For
   compatibility with old slaves, masters that support sending multiple
   answers per message MUST be configurable to revert to the
   historical mode of one answer per message, and the configuration
   SHOULD be settable on a per-slave basis."

> So servers running today, won't be able to talk to strictly compliant
> servers that don't have a backwards compatibility mode.

> But is allowed to, and a server that can't receive such messages won't be
> able to get the zone.
> 
> > > > > with a new protocol. Indeed, I think this idea has some merit. Howeve
> r, i
> > > t
> Uhh, wrong, except in an unreasonably broad technical exception due to the
> vagueness of 1034.

	Multiple records in the answer section have always been part
	of the standard.
 
> No. Because it might be reasonable not to give complete zone data.
> 
> So far as the secondary is concerned, the zone is complete.  If you do
> this, you don't want to tell people that you have some data that isn't
> public.  Nor would you ever need to.

	Well if you don't want to tell them that you have private
	part then you won't be answering with REFUSED. You effectively
	have two zones that just have a lot in common.  Treat them
	as such.

	Mark

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Feb 2003 09:25:36 +0100 (CET)

> releasing Bind 9, and before publishing a book on the subject.

A data point.

http://www.ietf.org/proceedings/00jul/I-D/dnsext-axfr-clarify-00.txt
INTERNET-DRAFT                                      Andreas Gustafsson
draft-ietf-dnsext-axfr-clarify-00.txt                     Nominum Inc.
                                                            March 2000
Seems to be 3 years ago.

  Erik

---

From: [email-masked]
Date: Fri, 21 Feb 2003 19:28:06 +1100

> rolls around, all the servers will change their data simultaneously, as

	So now you want to extend the protocol so that each record has
	an inception time and a expiration time.  We could create a
	new transfer protocol to do this and treat this data as meta
	data.

	However you would still have the problem of the meta data
	being inconsitant.  You would still need to ensure that it
	is transmitted in the right order or that servers didn't
	modify it while it was being transmitted or that you ban
	any server but the master server sending copies of the zone.

	The problems are inherent with having different source maintaining
	copies of the same data.
	
	Mark

---

From: David Conrad <[email-masked]>
Date: Fri, 21 Feb 2003 06:58:42 -0800

I remember when people thought OSI protocols took too long to 
standardize... :-)

Rgds,
-drc

On Friday, February 21, 2003, at 12:25  AM, Erik Nordmark wrote:

> _______________________________________________
> This message was passed through [email-masked], 
> which is a sublist of [email-masked]. Not all messages are passed. 
> Decisions on what to pass are made solely by Raffaele D'Albenzio.
>

---

From: Matt Crawford <[email-masked]>
Date: Fri, 21 Feb 2003 11:31:48 -0600

> rolls around, all the servers will change their data simultaneously, 

My friend Dr. Einstein would like a word with you about your casual
misuse of the word "simultaneously."

__________________________________________________________________
Matt Crawford             [email-masked]                Fermilab

---

From: Matt Crawford <[email-masked]>
Date: Fri, 21 Feb 2003 12:09:08 -0600

> I remember when people thought OSI protocols took too long to 

"$X is a slow-moving parody of itself." -- Peter Honeyman

In the original, $X was bound to "USENET", not "IETF".

---

From: Dean Anderson <[email-masked]>
Date: Tue, 18 Feb 2003 20:58:55 -0500 (EST)

--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 18 Feb 2003 18:46:19 -0500 (EST)

--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 19 Feb 2003 16:32:01 -0500 (EST)

They sure have been.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 20 Feb 2003 11:32:38 -0500 (EST)

---

From: Dean Anderson <[email-masked]>
Date: Thu, 20 Feb 2003 21:07:49 -0500 (EST)

child zone, they need to be merged. If a zone transfer happens while they

---

From: Dean Anderson <[email-masked]>
Date: Fri, 21 Feb 2003 14:06:41 -0500 (EST)

> rolls around, all the servers will change their data simultaneously, as

Clever.

> making a fool of yourself when you call it ``impossible.''

This could be done with a slight change to AXFR. Lets include it in the
MAXFR proposal (the axfr mods, taken out of the "clarification".

---

From: Dean Anderson <[email-masked]>
Date: Fri, 21 Feb 2003 14:20:57 -0500 (EST)

Interesting. So, they knew that standardization was necessary, the
proposed a standard, the standard wasn't accepted, so they distributed
code to users anyway, and wrote a book anyway.

I find that even more worthy of criticism.

Did they think they would force this through later? Never mind, it doesn't
matter what they thought.

As this "clarify" seems to have been dead for years, we should get on with
the business of clarifying AXFR as it was commonly interpreted. And lets
get on with the MAXFR proposal.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 21 Feb 2003 00:25:56 -0500 (EST)

Could you elaborate?

Such as?