Subject: Re: in support of axfr-clarify

From: Dean Anderson <[email-masked]>
Date: Sun, 8 Dec 2002 12:42:40 -0500 (EST)

Indeed, you are correct. It is very childish to abuse someone attempting
to discuss real issues.  Can we please stop abusing and maligning Dan
Bernstein?

By contrast, Dan seems to have valid points, while you don't.

		--Dean

On Sat, 7 Dec 2002, Danny Mayer wrote:

> Someone who constantly heaps abuse on people even when they're
> attempting to discuss issues for which this mailing list is designed
> shouldn't expect sympathy from anyone. It's very childish.
>
> Can we please get back to discussing issues?
>
> Danny
>
> At 11:34 AM 12/7/02, Dean Anderson wrote:
> >None of this is accurate.
> >
> >He may be yelling, but it is a result of sustained abuse over a long, long
> >period of time. Frankly, I wouldn't be nearly as patient.
> >
> >                 --Dean
> >
> >On Fri, 6 Dec 2002, Danny Mayer wrote:
> >
> > > At 01:58 PM 12/6/02, Dean Anderson wrote:
> > > >Bernsteins reaction is a natural response to harrassment, and deceptive
> > > >labeling regarding axfr-clarify.
> > > >
> > > >                 --Dean
> > >
> > > Yes, the natural response of a child who resorts to threads, abuse,
> > > harrassment,
> > > yells and screams to get their way, rather than a reasoned response.
> > All this
> > > from a professor.
> > >
> > > Danny
> > >
> > >
> >
> >
> >
> >--
> >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/>
>
>
> --
> 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/>
>

--
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: Danny Mayer <[email-masked]>
Date: Mon, 09 Dec 2002 00:08:25 -0500

>By contrast, Dan seems to have valid points, while you don't.

You're confusing me with someone else.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Mon, 09 Dec 2002 00:20:16 -0500

I'd like to bring this back on track here.

I'd like to look at what rsync (as recommended by the DJBDNS company)
does and what axfr-clarify says to do.

Let us say we have two servers A and B that are authorative for a zone.
The contents of the zone reside in a file named Z on server A and in a file
named Z' on server B.

An admin adds records to file Z on server A and reloads the server. rsync
notices the change to the file and transfers the delta to server B and merges
the changes into file Z'. If I understand correctly rsync, the contents of 
file Z'
is now identical to that of Z. Server B is now reloaded and can respond to
queries on the new records.

Isn't this exactly what axfr-clarify is trying to accomplish, i.e. the records
in the zone should be transferred unchanged from server A to server B
irrespective of other information that the server may have regarding some
of the records? Why should AXFR be different in this respect from rsync?

Danny

---

From: Bruce Campbell <[email-masked]>
Date: Mon, 9 Dec 2002 11:29:44 +0100 (CET)

> queries on the new records.

Yes.

> Isn't this exactly what axfr-clarify is trying to accomplish, i.e. the records

Nearly.

> of the records? Why should AXFR be different in this respect from rsync?

The main difference between AXFR and rsync-over-ssh is that the latter
produces an exact copy of a given _file_.  The former SHOULD produce a
functionally-identical copy of a given _zone_.

( I say 'SHOULD' because a number of implementations do not produce
  functionally-identical copies, due to confusion about the existing
  definition of AXFR, as has been noted previously. )

This means, since there is no set standard for an actual zone file, that
you can only (reliably) do rsync-over-ssh if you have identical server
software on both servers.

If you have two servers using different zone file formats, that understand
AXFR, you should be able to get working transfers of zones, without having
to mess around with post-converting the zone file from one format to
another, to say nothing of a separate process to detect changes and
trigger a zone or server reload.

Hence, I support the general need for a clarification of AXFR so that
various nameserver implementations can reliably act as both primary or
secondary depending on local configuration.

--==--
Bruce.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 09 Dec 2002 07:21:01 -0500

>software on both servers.

Thank you. I should have said functionally identical. An AXFR transfer
has no defined order in the records transferred except that the first and
last records be the SOA and identical and of course any comments that
may have been in the original source file do not get transferred.

>trigger a zone or server reload.

Yes, the storage of the data can be in any format, including a database.

Danny

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 09 Dec 2002 21:52:33 +0100

> secondary depending on local configuration.

I also would like to support the clarification of AXFR. The interoperable
method becomes increasingly important as different implementations take new
data storage and backend paradigms in use.[0]

As a side note: While some zones have passed the size where AFXR ceases to
be a practically feasible synchronisation method, these are in absolute
minority -- I believe they can be counted on ones fingers today. 

Those reluctant or unable to promote or use AXFR might want to document
their ideas in another draft, perhaps to DNSOP, as this is strictly a
management issue, not a protocol one. 

- -- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

[0] Out of the 4 or so implementations I've toyed with the last year, only
    one (BIND family) uses the classic file -- the others have switched to 
    databases, most often dbm hashes.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Dec 2002 08:05:01 -0000

Danny Mayer writes:
> Isn't this exactly what axfr-clarify is trying to accomplish

No.

My recommended use of rsync is to replicate complete _servers_. This has
a simple meaning: the servers respond identically to every query.

What you're trying to do is replicate separate _zones_. This is a much
more complicated concept. Contrary to your previous claims, it does
_not_ mean that the servers respond identically to every query in the
zone; I explained in a previous message why that can't be true.

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

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 10 Dec 2002 11:01:05 +0100

> a simple meaning: the servers respond identically to every query.

A cool concept. And a fringe case at best. I am hard pressed to find this
situation in large and/or widespread management domains -- most servers are
by intention or legacy somewhat unique. This also is an operational issue. 

> zone; I explained in a previous message why that can't be true.

So why are you attacking the AXFR concept by proposing something completely
different, that does not fill the same need?

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 10 Dec 2002 15:12:26 +0100 (CET)

> software on both servers.

Hrm.  There is a set standard for zone (MASTER) files in RFC1035 section 5
which I had forgotten about (and keen-eyed Bush immediately noted).  The
above paragraph thus should read:

	This means that you can only (reliably) do rsync-over-ssh if you
	have a common zone file format on both servers (eg the 'MASTER'
	zone format as per RFC1035 5.1).

--==--
Bruce.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Dec 2002 21:26:40 -0000

> A cool concept. And a fringe case at best.

In fact, even though BIND makes it unnecessarily difficult to set up,
this is an extremely popular configuration. AXFR today has two main uses:

   (1) as a clumsy mechanism of replicating servers and
   (2) as a clumsy mechanism of editing zone files remotely.

Except at companies that sell third-party DNS service, there's very
little demand for any type of replication other than server replication.
Yes, we can all point to examples such as arpa-vs.-root-servers.net, but
those examples are the fringe case.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Dec 2002 23:16:25 -0000

When normal people replicate servers, they use the same software
everywhere. For example, a normal person setting up replicated HTTP
service uses the same HTTP software on both computers. Similarly, a
normal person setting up replicated DNS service uses the same DNS
software on both computers.

There are certainly advantages to simple, stable configuration-file
formats that can be read by many programs, but these advantages are
practically irrelevant to server replication, and they're often
outweighed by the benefits of better formats.

Bruce Campbell writes:
> There is a set standard for zone (MASTER) files in RFC1035 section 5

Sorry to bother you with the facts, but the BIND company keeps changing
their zone-file format. You're kidding yourself if you think that the
format is stable. Furthermore, zone files are only part of the BIND
configuration; the named.conf format is even less stable.

---

From: Derek Atkins <[email-masked]>
Date: 10 Dec 2002 18:25:54 -0500

Dan,

Now I KNOW you're on crack.  EVERY single DNS server that I've set up
has used AXFR to do zone syncs.  The reason: each server hosts a
different set of zones.  My primary and secondary servers are not
mirrors of each other.  They are not administrated by the same set of
people.  Indeed, the BCP REQUIRES that DNS servers be
network-distributed to protect against single-point-of-failures.

Setting up axfr is simple.  I list my secondaries, and they just say
"master <my-ip-adderess>".  There.  Done.  End of configuration.  How
could setting up a secondary be any easier than that?

I would say that there is a LOT of demand for AXFR.  Everyone out
there than runs their own domain and actually follows the BCP needs
AXFR.  I'm certainly not willing to give my secondaries remote-access
(even for rsync) to my server.  Nor do I think the primaries for the
zones for which I secondary would give me similar access.

Dan, it's been a long time since our PGP V. X.509 discussions on the
bus from Morristown to Picataway (I presume you still remember that
conversation?  I certainly do!).  What I learned from that is the
notion that there are necessarily multiple ways of doing something and
not everyone agrees on the "right way".  So you need to come up with
some basic, minimal, in-band means to do what you want to do, and if
people want to do something different, out of band, you need to allow
them to do so.  In this case, you need to standardize the AXFR (the
simple in-band solution) but allow people to use the out-of-band
(rsync) method if they so choose.

However, since it is out-of-band, that implies it is out-of-scope and
therefore should be taken elsewhere.

Have a nice day,

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Dec 2002 00:59:14 -0000

> could setting up a secondary be any easier than that?

What do you do when you change named.conf---for example, to add a zone?
You have to copy the changes to the secondary. With server replication,
this is handled automatically.

> each server hosts a different set of zones.  My primary and secondary
> servers are not mirrors of each other.  They are not administrated by
> the same set of people.

That configuration is much less popular than you appear to realize. See
http://cr.yp.to/djbdns/third-party.html for further comments.

> out-of-band (rsync)

Your notion of ``out-of-band'' is religious nonsense. Does it frighten
you that the FTP protocol uses more than one port?

---

From: Derek Atkins <[email-masked]>
Date: 10 Dec 2002 20:38:34 -0500

> this is handled automatically.

If I am the primary, I email it to the maintainer of the secondardies
and say "add this section to named.conf".  If I'm the secondary, then
the admin of the primary usually contacts me with similar information.
The configuration of the zones themselves are nearly static; changing
the IP addresses of primary and secondary servers is rare -- certainly
much more rare than changing the zone data.

The point is that each DNS server is autonomous.  There is no
requirement that NS1.FOO.EXAMPLE. and NS5.BAR.EXAMPLE., which both
happen to be authoritative for the QUUX.EXAMPLE zone, be mirrors of
each other.

> you that the FTP protocol uses more than one port?

Religious nonsense, eh?  Dan, are you trying to be intentionally
belligerent or are you just unaware of how your tone comes across in
email?  I don't recall you being this quick to judge, nor do I
remember you trying to be mean or hostile, but then again I was much
younger then.  If your tone is accidental, may I suggest you "tone
down" your messages in the future?  Personally, I'm trying to have a
peaceful conversation here, and honestly I'm not sure how to interpret
your message.  Regardless, I do have to wonder how is it nonsense to
call "use protocol Y to communicate data for protocol X" out-of-band,
when protocol-X has its own way of communicating that very same data?

As for FTP, does it frighten me in what way?  The FTP spec clearly has
the PORT command documented.  It is part of the FTP protocol
specification.  I think it was a poor design choice, but then again I
wasn't there at the time it was created (and besides, that was not the
question).  No, the FTP PORT callback channel is not "out of band",
because it is just a second connection that remains part of the ftp
protocol.

No, out of band is when some protocol says to "run this _OTHER_
protocol to copy data from A to B".  Note that in this case (for DNS
zone files) I can use email, ssh, ftp, http, or even the US Postal
Service and OCR to transmit zone data.  Indeed, there are LOTS of
"out-of-band" means to transfer the data.  There are, however, two
"in-band" methods defined by the DNS specification, called AXFR and
IXFR.  Let's not confuse apples with kumquats here.  :-)

-derek

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Dec 2002 02:08:09 -0000

Derek Atkins writes:
> Religious nonsense, eh?

Yes. Instead of rationally evaluating the costs and benefits of two
different protocol extension mechanisms, you declare that one mechanism
(new query types) is ``part of the protocol,'' while the other one (new
ports) is ``out of band'' and therefore not subject to discussion here.
That's religious nonsense.

> happen to be authoritative for the QUUX.EXAMPLE zone, be mirrors of

I didn't say that server replication was required. I said that it's
popular.

---

From: Derek Atkins <[email-masked]>
Date: 10 Dec 2002 21:22:56 -0500

> ports) is ``out of band'' and therefore not subject to discussion here.

Could you answer me how AXFR can be considered a "new query type" or
even a "protcol extension"?  It seems to be defined as far back as
RFC-883, which, if memory serves, is the original DNS definition....
Therefore, it would seem to imply that it is a core DNS element,
having been there from the beginning.  If people have found problems
with the AXFR then that would certainly be within scope of this list.

> That's religious nonsense.

Well, I'm very sorry you feel that way.  This _IS_ the namedroppers
list after all, for discussion of the DNS protocol (of which AXFR is
clearly part).  I am certainly open to the concept of using alternate
methods (outside the DNS protocol) to transmit DNS information, but it
is quite frankly out of scope for the DNS protocol discussion list.

Such discussion _may_ be appropriate for a DNS operations mailing
list, but last I checked this was not such a list.

-derek

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Dec 2002 03:45:18 -0000

Derek Atkins writes:
> even a "protcol extension"?

You said ``AXFR and IXFR.'' If you're going to start drawing some
religious line between protocol options defined many years ago and
protocol options defined more recently, you'll have to put IXFR on the
same side of the line as rsync.

> I am certainly open to the concept of using alternate methods
> (outside the DNS protocol) to transmit DNS information, but it is
> quite frankly out of scope for the DNS protocol discussion list.

What exactly do you mean by ``the DNS protocol''? 

Please try to avoid knee-jerk religious answers. For example, if you
define ``the DNS protocol'' as ``whatever runs on port 53,'' then you're
making the absurd claim that it's ``out of scope'' to discuss Larson's
proposal to put DNSSEC on another port.

---

From: Derek Atkins <[email-masked]>
Date: 10 Dec 2002 23:44:49 -0500

> same side of the line as rsync.

No, because IXFR works within the DNS framework and rsync does not.
It's sort of like comparing DNSSec and PGP.  They are completely
separate ideas, even if they can solve the same sorts of problems.

-derek

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Dec 2002 05:17:09 -0000

Derek Atkins writes:
> IXFR works within the DNS framework and rsync does not.

More religious nonsense. You still haven't defined ``the DNS protocol'';
if I ask you to define ``the DNS framework,'' are you going to dodge
that too, and start babbling about ``the DNS approach''?

> separate ideas, even if they can solve the same sorts of problems.

In fact, there would be quite a few advantages to using PGP signatures
inside DNS: software is already widely available for key generation,
signature generation, and signature verification. Are your religious
views blinding you to this possibility?

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 11 Dec 2002 10:33:49 +0100

> that too, and start babbling about ``the DNS approach''?

Please, Dan. 

The point we (at least I am) are trying to make is that "Hey, it is fine to
use whatever [server|zone] replication mechanism, but we believe that only
AXFR and other methods that use DNS messages like IXFR are on-topic for
this forum." It is not a judgement -- I for one am using ftp for one of the
zones I slave -- but more of a stay-on-topic requirement. 

The dnsop wg has a mailing list, which probably is the better IETF forum
for this, but I do believe that the topic of "how to replicate DNS data out
of band" is best at home in a systems administration forum, of which there
are a multitude. 

IF you believe that AXFR is so broken that it needs to be replaced with
something completely different, then find out a method, write a draft and
make it so good that we all see that this is the future. THAT would be
on-topic. 

Regards,

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 11 Dec 2002 12:05:22 -0500

>this is handled automatically.
Well, perhaps this is as good a time as any to raise the fact that I've 
been working on an "auto-slaving" mechanism. The basic idea is that upon 
receipt of a signed NOTIFY from a particular entity, a slave can, if 
configured to do so, automatically configure itself as a slave for the 
zone being NOTIFY'ed. I've already started implementing this in the BIND 
9 codebase, but the general concept is not implementation-specific and 
could conceivably be supported by any implementation that handles signed 
NOTIFYs.

I bring this up not only to provide a middle-ground alternative between 
the two extremes presented thusfar, i.e. manually set up AXFR/IXFR 
slaves versus handling everything automatically through server 
replication, but also to elicit opinions as to whether this (perhaps 
unforeseen) use of NOTIFY requires any protocol standards action (Jim 
Reid has already weighed in with his opinion that it *does* require 
protocol standards action, but I disagree).

Other opinions?

                                    - Kevin

P.S. Mark (Andrews), have you seen my BIND 9 patch for this?

---

From: Doug Barton <[email-masked]>
Date: Wed, 11 Dec 2002 23:13:01 -0800 (PST)

> those examples are the fringe case.

I have to disagree. I am the DNS administrator for a fairly large
enterprise, and I'm also responsible for the name servers used in our DNS
reselling program. I have roughly 200 name servers, in dozens of
geographic locations all over the world, some authoritative, most
resolvers. I have several different masters, each with a unique subset of
zones it's responsible for. Each of the slaves sucks down some zones from
the various masters, but no single server gets all the zones from any of
the masters.

In short, while there are subsets of slaves that all have the same
configurations, there isn't anyplace in my company where the concept of
"server replication" would apply. AXFR is crucial to the success of my
configuration(s). Note, I haven't even touched on the issue of sharing
information with third parties, whether I'm slaving from them, or they are
slaving from me (I have some of each).

Now you can argue whether or not I'm a "typical" user, or whether all the
gymnastics are actually needed. (In fact, the current configuration is
both simpler and more reliable than when I took over, but I digress.)
However, AXFR definitely provides me the flexibility I need to deal with
my situation (as I perceive it).

-- 
   "We have known freedom's price. We have shown freedom's power.
      And in this great conflict, ...  we will see freedom's victory."
	- George W. Bush, President of the United States
          State of the Union, January 28, 2002

         Do YOU Yahoo!?