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: Dean Anderson <[email-masked]>
Date: Tue, 18 Feb 2003 18:46:19 -0500 (EST)

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.

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.

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: "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: Kandra Nygårds <[email-masked]>
Date: Wed, 19 Feb 2003 08:13:35 +0100

From: "D. J. Bernstein" <[email-masked]>

> parent zone is supposed to match the data in the child zone.

Excellent point. Now for a real-world example: Many ccTLDs (and RIRs, such
as RIPE) require automated or manual checks before a delegation [change] is
approved by the TLD Registry. Prior to requesting a change of delegation,
the zone administrator changes the zone data. This of course violates RFC
1034, specifically sections 4.2.1 and 4.2.2.

Please tell me, how is one to accomplish this without breaking RFC1034
sections 4.2.1 and 4.2.2?

Or perhaps there are places where some (temporary) RFC1034 breakage is not
only warranted but to be expected from time to time?

> up the configuration in the first place.

If it prevents me from breaking my zones without breaking anything else,
that's a good thing. Unfortunately, it also changes the content of the
zones, which does break something else. This is an interoperability issue,
and a potentially problematic one.

> difficult to understand that it's your fault for violating RFC 1034?

The reason for violating RFC1034 could be as simple as propragation delay.
If timing issues interfere with routine zone updates, it's an implementation
bug. The reason could also be a temporary intentional change. If your
software breaks intentional changes, it's an implementation bug.

Face it, you do not live in a perfect world, where you (as a single
administrator) can control everything. Delays - human or machine - in
propragating information is a reality. If your software can't cope with
that, it's an implementation bug. And, it's no good to claim that it
wouldn't have broken if everyone had just used YOUR software. If it breaks,
it's a bug.

> based on AXFR. See http://cr.yp.to/djbdns/tcp.html#intro-axfr.

...and, if your software can't interoperate with other software properly,
it's an [   insert here   ] bug?

Best regards,
Kandra Nygards