Subject: Unfinished DNS UPDATE work...

From: Terry Lambert <[email-masked]>
Date: Mon, 01 May 2000 19:32:01 -0700

RFC 2136 says:

|   7.6. It is not possible to create a zone using this protocol,
|   since there is no provision for a slave server to be told who
|   its master servers are.  It is expected that this protocol
|   will be extended in the future to cover this case.  Therefore,
|   at this time, the addition of SOA RRs is unsupported.  For
|   similar reasons, deletion of SOA RRs is also unsupported.

It seems to me that it's about time to tackle this work;
is anyone else interested in this as well?

BTW: The rationale here seems a bit thin; there's no reason
that, for example, the master can't be updated to add or
delete an SOA.  The only loser on this is the slave.

Of course, if SOA updates to slaves resulted in the slave
doing a search-from-root to auto-detect the master, that
would work; alternately, a "push" relationship could be
established, where the master notifies the slave, and
because of this, the slave saves off the source of the
notification.  This would work for all slaves for which
there were NS records specified in the master.

Or something else could happen, and that would be like
a DNS update, too... the point is to start talking
about the problem.

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 02 May 2000 09:55:43 -0700

> delete an SOA.  The only loser on this is the slave.

we can't let zone owners commandeer other folks' slaves.  so the
thing we'd have to do is form a secure relationship between a master
and each slave.  the security of that relationship can be out of band,
or in-band, either of which is a far more difficult problem to solve
than "what update transactions would create a new zone?"

---

From: Edward Lewis <[email-masked]>
Date: Tue, 2 May 2000 15:42:17 -0400

While this sounds like an(other) interesting area to work on, IMHO, this
should wait until the current updates to DNS settle down.  (E.g., DNSSEC,
IPv6, EDNS0.)

At 12:55 PM -0400 5/2/00, Paul A Vixie wrote:
>than "what update transactions would create a new zone?"

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

"It takes years of training to know when to do nothing" - Dogbert

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

---

From: Terry Lambert <[email-masked]>
Date: Tue, 02 May 2000 13:14:20 -0700

Paul A Vixie wrote:
> we can't let zone owners commandeer other folks' slaves.
> so the thing we'd have to do is form a secure relationship
> between a master and each slave.  the security of that
> relationship can be out of band, or in-band, either of
> which is a far more difficult problem to solve than "what
> update transactions would create a new zone?"

Right now, my primary concern is the creation of new zones
on a large DNS, so as to minimize the downtime while the
thing is reloading.  If I can create a zone with DNSUPDAT,
then I can have zero downtime on the master, whereas right
now I have up to several minutes of downtime during the
reload during which the server is unresponsive to requests
(this is annoying because I have active checks for the
server being alive which result in people getting paged,
but that's my process definition problem to solve, and not
the group's problem; I'm more concerned with the downtime,
but that's probably because I'm not the one being paged).

The slave issues would, I think, be handled by whether or
not the DNSUPDAT was permitted for the master.  Clearly,
as you point out, a slave with a relationship with several
masters would have a problem with this.

I think this could be handled in a gross sense by using one
of the previously suggested techniques, and then permitting
the master to update or not based on syntactic sugar that
is associated with the credentials.  The default would be
the current "ignore the update request" behaviour we see
for both the master and the slaves.  This would presumably
go in as an option in the "options" section.

Is there a particular security reason that creation of zones
in a master server via DNSUPDAT should not be permitted?

All of the rationale appears to be aimed at the long standing
issue of how to inform a slave of its slave status in regard
to a newly defined zone in a master for which the slave is
supposed to zone transfer.  That is, the historical master/slave
relationship issues which arise when one wants to decouple a
master and a slave such that a slave is not necessarily a slave
for every zone for which the master is the master, and so on.

Thanks,
-- Terry Lambert

---

From: John Gilmore <[email-masked]>
Date: Tue, 02 May 2000 16:44:10 -0700

> than "what update transactions would create a new zone?"

A zone could be created by dynamic update on the master, including NS
records that refer to slaves.  If the master sends a notification to
the slaves, they can each make their own decision about whether to
begin serving the zone.  These can be relayed back to the originator
of the update, who could then modify the zone if desired.  

A config file for slave servers that lets the user say, e.g.:

	*  Become a slave for any zone served by ns.i-am-an-isp.com
	*  Become a slave for any zone under the mycompany.com domain
	*  Become a slave for any zone under 140.144.in-addr.arpa.
	*  Become a slave for ...
	*  Reject all other new-zone notifications

would provide easy to configure pre-authorization for a large fraction
of users.

	John

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 02 May 2000 16:23:42 -0400

> than "what update transactions would create a new zone?"

I'm not sure what you mean by "commandeer". Can a server not check
delegations and/or the zone SOA to verify that the entity which is
requesting a master-slave relationship isn't just some random pirate?

- Kevin

---

From: [email-masked]
Date: Wed, 03 May 2000 08:04:42 +0200

> thing is reloading.

Have you tried ndc reconfig, instead of ndc reload? The difference
can be dramatic if you have thousands of zones...

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Wed, 03 May 2000 15:37:03 +1000

Date:        Tue, 02 May 2000 13:14:20 -0700
    From:        Terry Lambert <[email-masked]>
    Message-ID:  <[email-masked]>

  | Right now, my primary concern is the creation of new zones
  | on a large DNS, so as to minimize the downtime while the
  | thing is reloading.

This looks like a request for the software you're running to have a
"create a zone" interface.   Aside from your software (apparently)
having DDNS which does much the same function (updates the server
dynamically), I don't see the relationship.

Would not just an administrative command to your server "create zone X
using the data in the new zone file x" be a more appropriate way to
solve the problem you're referring to?

And I know the problem well, it takes munnari over 15 minutes to become
responsive again if its nameserver has to restart, or do a large reload.

kre

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 03 May 2000 09:08:25 +0200

>would provide easy to configure pre-authorization for a large fraction

this seems to me an area where experimentation could be encouraged without
significant harm to the Internet.

that is:

- if someone comments out the lines in BIND that refuse to create a SOA
   record using DNSUPDATE, you have a working master, with no harm to the
   rest of the network
- if someone hacks a BIND (or something else) to do intelligent things
   when getting a NOTIFY for a zone that it is not currently a slave for,
   we have a working slave, with no harm to the rest of the network
- if someone writes up exactly what protocol changes needed to be made (if
   any), and what the operational problems were (including the case where
   the slave is misconfigured to not allow an authorized master to update,
   and how to detect that case at the master side), we have proof of
   running code (and perhaps reasons not to do it).

at the moment, it seems to me that a signed NOTIFY is required for this
to make sense, but don't know if NOTIFY contains the required information
or if it can be signed in the Right Way so that configuration is easy
at the slave side, or if the sig on the NS in the notified zone is the 
Right Thing to check instead.

(BTW, one of the NORID - .no naming authority - nameservers is secondary
for a couple of thousand zones. Such a scheme would greatly lessen the
administrative overhead of providing that service, but some kind of limit
would have to be in place - it probably could not handle being secondary 
for a million zones)

                               Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Terry Lambert <[email-masked]>
Date: Wed, 03 May 2000 10:11:23 -0700

Robert Elz wrote:
> This looks like a request for the software you're running
> to have a "create a zone" interface.   Aside from your
> software (apparently) having DDNS which does much the same
> function (updates the server dynamically), I don't see the
> relationship.

The RFC definiting DDNS explicitly calls out for future work
to define this capability.

> Would not just an administrative command to your server
> "create zone X using the data in the new zone file x" be
> a more appropriate way to solve the problem you're
> referring to?

The "administrative interface" I would have for this is:

	vi db/named.noc
	... add the new zone ...
	cvs ci db/named.noc
	kill -HUP `cat named.pid`

If I have to define a new interface to do this, it might
as well be in the context of the future work called out
in the DDNS RFC, and become standard, instead of being a
private interface I kludge for my own purposes.

> And I know the problem well, it takes munnari over 15
> minutes to become responsive again if its nameserver has
> to restart, or do a large reload.

Do you use a private interface for zone creation?

What software are you using?  Mine is ISC bind; as far
as I can tell, it has no such interface.

As I said: I would prefer that the interface be standard,
instead of being a figment of my imagination which my
firewall administration refuses to buy into.

Also as I said: I still don't see the rationale for
denying SOA creation via DDNS in masters.  I'd be happy
to group this corner case in with the slave update
problem and tackle it at the same time, if someone could
provide some real reason that permitting zone creation
in a master can cause problems.

I know that I can kludge this by making the software do
a periodic stat of the config files it has read, and do
an incremental reload, if the dates have changed.  But
one of my issues is that I am making heavy use of DDNS at
this point, so monotonically increasing serial numbers
become an issue.  That's an implementation detail that
belongs in DNSOPS, though, and is seperate from the DDNS
zone creation issue.

-- Terry Lambert

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 May 2000 09:18:43 -0000

> significant harm to the Internet.

There's already a protocol that's used at many sites instead of zone
transfers. Feature comparison:

                              AXFR + IETF experiments  This protocol
   -----------------------------------------------------------------
   Immediate replication      Yes                      Yes
   Error notification         No                       Yes
   Incremental transfers      Yes                      Yes
   Compressed transfers       No                       Yes
   Add zones automatically    No                       Yes
   Encryption                 No                       Yes
   Authentication             Yes                      Yes
   Usable for other services  No                       Yes

The protocol, in short, is to actively copy the service configuration
through rsync (http://rsync.samba.org) over ssh.

Replicating your DNS service through AXFR is like replicating your
organization's HTTP service through an uncompressed, unencrypted,
ad-hoc error-hiding pull protocol that demands separate configuration
for each new subdirectory that you want to replicate. Yes, it can be
done, but it's laughably crude.

---Dan

P.S. I agree that reload outages are an implementation problem, not a
protocol problem. If the server is tinydns, part of the DNScache package
(http://cr.yp.to/dnscache.html), then there are no outages.

---

From: Terry Lambert <[email-masked]>
Date: Thu, 04 May 2000 16:56:29 -0700

D. J. Bernstein wrote [ edited ]:
>                               AXFR + IETF experiments  Rsync + SSH
     ------------------------> depends on the experiment
>    Encryption                 No                       Yes
     ------------------------> depends on the transport
>    Usable for other services  No                       Yes

     Can create zones in master Yes                      No
     Handles master/slave SOAs  Yes                      No
     No reload/reconfig latency Yes                      No
     No new firewall holes      Yes                      No
     Commercializable license   Yes                      No

> P.S. I agree that reload outages are an implementation problem,
> not a protocol problem. If the server is tinydns, part of the
> DNScache package (http://cr.yp.to/dnscache.html), then there
> are no outages.

The problem with this is that it is a UDP-only server, and
zone creation requires local access to the machine, where
the zone is being created, instead of protocol access in the
context of DNS (e.g. ssh is not a sufficient soloution).

-- Terry Lambert

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 May 2000 07:33:19 -0000

There are two different administrative activities under discussion:
editing your DNS records, and replicating your DNS service.

I compared two different replication protocols: AXFR+NOTIFY+IXFR+TSIG
and rsync+ssh. One of the advantages of rsync+ssh is that it can easily
replicate the _entire_ service, solving the add-zones-to-the-slave
problem that Cricket mentioned.

When Terry talks about ``create zones in master'' he's obviously
thinking of editing, not replication. Of course, there are ssh-based
editing protocols too.

Terry Lambert writes:
> Commercializable license

I don't understand. You're complaining about the rsync and ssh protocols
because implementations are available for free?

> new firewall holes

So remote file editing is okay if it's done with experimental software
on port 53, but not if it's done with stable software on a dedicated
port that you can precisely control? This makes no sense.

As far as I'm concerned, cramming six separate protocols into port 53 is
a horrible idea. It defeats the demultiplexing provided by UDP and TCP
implementations, so it adds extra work for people who want to handle the
protocols in separate programs. Putting the protocols on separate ports
encourages modularity and encourages competition.

> reload/reconfig latency

My tinydns-data program compiles a 30-megabyte database in 10 seconds on
a typical workstation. During those 10 seconds, queries are answered
from the old database. What exactly are you worried about?

> it is a UDP-only server

You can provide TCP service if you want to; it's simply not the default.
RTFM: http://cr.yp.to/dnscache/faq/tinydns.html#tcp

---Dan

---

From: Terry Lambert <[email-masked]>
Date: Fri, 05 May 2000 11:33:50 -0700

D. J. Bernstein wrote:
> 
> There are two different administrative activities under
> discussion: editing your DNS records, and replicating
> your DNS service.
> 
> I compared two different replication protocols:
> AXFR+NOTIFY+IXFR+TSIG and rsync+ssh. One of the advantages
> of rsync+ssh is that it can easily replicate the _entire_
> service, solving the add-zones-to-the-slave problem that
> Cricket mentioned.

I have a problem with replicating the data verbatim.  In
particular, I have a serious issue with the fact that this
would mean that my slaves would really be masters in their
own right.

Any replication has to be hierarchical, as the DNS is
hierarchical.  People may not like this any more than
they like it in LDAP or NIS, but that's irrelevent.

You are implicitly advocating a use model which discards
the concept of slaves, and I am not willing to go that
far without a serious amount of justification.

When you can get the working group to withdraw the work
that you object to, then I will be willing to quit using
it.

> When Terry talks about ``create zones in master'' he's
> obviously thinking of editing, not replication.  Of
> course, there are ssh-based editing protocols too.

I am thinking about all of the tasks I normally have to
do while running the server, and the fact that I can't
do them all over port 53 (yet).

> Terry Lambert writes:
> > Commercializable license
> 
> I don't understand. You're complaining about the rsync
> and ssh protocols because implementations are available
> for free?

No.  And I don't want a license merit discussion. I mean
I can't sell a product based on it and linked with code
which embodies my patented algorithm without tacitly giving
license to use my patented algorithm, for free, when anyone
demands my source code.

License merit is irrelevant.  My lawyers will simply not
let me do this, and any argument you put forth to me is
just so much wasted breath, because I am not my lawyers.

> > new firewall holes
> 
> So remote file editing is okay if it's done with
> experimental software on port 53,

Yes.

> but not if it's done with stable software on a dedicated

The protocol you advocate letting in permits shell access,
which is administratively prohibited.

> As far as I'm concerned, cramming six separate protocols
> into port 53 is a horrible idea.

I definitely agree.  Which is why I'm only talking about
DNS data manipulation, not modifying my crontab as a result
of port 53 traffic.

> Putting the protocols on separate ports encourages
> modularity and encourages competition.

Only among people who do not understand principles of
modular programming in the first place, such that they
create something which is not modular based on first
principles.

As a counter-example, there are many SNMP daemons that
allow registration of subtree handlers.  So do almost all
LDAP servers.  So do some DNS servers.  All UNIX file
systems.  I could go on; it's a common attribute of most
hierarchical databases, and those which do not include
the capability are generally considered deficient.

> > reload/reconfig latency
> 
> My tinydns-data program compiles a 30-megabyte database
> in 10 seconds on a typical workstation. During those 10
> seconds, queries are answered from the old database. What
> exactly are you worried about?

We were talking about your protocol, not your DNS
implementation.  I am worried about using a DNS from
someone other than you: one I will be permitted to
deploy.

> > it is a UDP-only server

[ ... suggestion to use a different glue program ... ]

This does not address the primary complaint:

| zone creation requires local access to the machine, where
| the zone is being created, instead of protocol access in the
| context of DNS (e.g. ssh is not a sufficient soloution).

-- Terry Lambert

---

From: "D. J. Bernstein" <[email-masked]>
Date: 6 May 2000 00:08:06 -0000

Terry Lambert writes:
> my slaves would really be masters

On the contrary. They're still slaves. DNS records are edited on the
master and then copied to the slaves. The only difference is that the
copying happens through a better protocol.

BIND incorrectly refers to these slaves as ``masters,'' because BIND
incorrectly assumes that all replication will take place through the
crude protocols built into BIND; but these mistakes don't change the
reality of what's happening.

> The protocol you advocate letting in permits shell access,

On the contrary. It's a general-purpose protocol, like TCP. Shell access
is merely one application. DNS replication is another application. DNS
editing is another application.

> ssh is not a sufficient soloution

You keep saying that these things can't be done, but they can be, and
they often are, because existing general-purpose tools do the job today,
while DNS-specific vaporware doesn't.

> LDAP servers.  So do some DNS servers.

I didn't say that demultiplexing couldn't be done in a DNS server. I
said that it adds unnecessary implementation costs for modular servers.
A competent protocol designer will use separate ports to take advantage
of the demultiplexing features that are already provided by UDP/IP and
TCP/IP stacks.

> We were talking about your protocol, not your DNS implementation.

You mentioned a BIND implementation flaw, namely failure to answer
queries while new data is being read. You mischaracterized this flaw as
a problem in replication protocols that use rsync+ssh. (When you hear
that BIND's IXFR implementation keeps crashing, do you conclude that
IXFR must be a bad protocol?)

I pointed out that these outages simply don't occur with tinydns-data.
This makes clear that your problems are with one implementation, not
with the protocol.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Sat, 06 May 2000 13:55:12 +1000

Date:        Fri, 05 May 2000 11:33:50 -0700
    From:        Terry Lambert <[email-masked]>
    Message-ID:  <[email-masked]>

  | Any replication has to be hierarchical, as the DNS is
  | hierarchical.  People may not like this any more than
  | they like it in LDAP or NIS, but that's irrelevent.

I don't generally agree with Dr Bernstein - about anything at all.
But in this instance, he's right - it doesn't matter in the least
how the DNS data is replicated, as long as it is accurately and
reliably replicated.  AXFR (or IXFR) is one way, ssh is another.
The root zones used to be (and for all I know, may still be)
replicated using FTP.

The only problem I have encountered with using other than *XFR
is that I have seen either implementations or operators (I haven't
worked out which yet) who seem to have misunderstood "replication" and
make subtle changes to the data in the secondary servers (in particular
having the SOA.MNAME reflect the name of the server, rather than
the data from the zone file).   But that's just a bug - correctly
operated servers that have been correctly implemented will work
however the master file is transferred from primary to secondary server.

kre

---

From: Randy Bush <[email-masked]>
Date: Sat, 06 May 2000 09:02:08 +0200

it was thought prudent for the protocol specification to provide a clear and
documented means to move zone files between he master/primary and slaves/
secondaries.  if one has other means to accomplish the same end, then cool.
but the other means must achieve the semantically identical results as
judged by the bits on the wire as far as clients (resolvers) and others can
tell.  i.e., when you're through being cute, the duck must still walk like a
duck.

randy

---

From: Paul A Vixie <[email-masked]>
Date: Sat, 06 May 2000 09:21:01 -0700

> tell.  i.e., when you're through being cute, the duck must still walk like a

right.  i've used nfs, rcp, rdist, rsync, uux, ftp, tftp and who knows what
else to move zone files when there were firewalls in the way i didn't control.
but none of those methods did what the zone transfer spec says, and by the
time i would get done trying to do serial number comparison including 32-bit
wrapping, refresh intervals, retry intervals, and expiration, it wasn't just
a little cron job running a shell script any more, and it ended up being easier
to have fixed the firewall.  same thing for using dig rather than named-xfer.

axfr's biggest problem was fixed by IXFR.  its second biggest problem could be
fixed with what BIND calls "ZXFR" which is just gzip on the transport session;
i never finished it and it's disabled by #ifdef's but you get the idea.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 May 2000 00:13:23 -0000

Paul A Vixie writes:
> serial number comparison including 32-bit wrapping,

The normal use of ssh for DNS replication doesn't rely on serial numbers
at all. The master immediately pushes new data to the slaves.

> refresh intervals, retry intervals, and expiration

One advantage of pushing data in the foreground through ssh is that you
receive immediate and reliable notification if anything goes wrong.

If you run out of disk space editing your web pages, would you like your
editor to try saving the file for the first time only after you log out?
Then have it destroy the old pages after retrying for weeks? Or would
you prefer to have it see the problem and tell you about it as soon as
you say ``save''?

I'm not saying that refresh-retry-expire is difficult to implement. I'm
saying that it's a poor substitute for what people actually want.

> axfr's biggest problem was fixed by IXFR.

The same problem was fixed much earlier by sysadmins using the standard
general-purpose ``diff'' and ``patch'' tools. Nowadays, with rsync, the
master doesn't even need to keep a log of changes.

Anyway, I can't agree that this is AXFR's biggest problem. The lack of
immediate failure notices, the lack of a mechanism to modify zone lists,
and the lack of security are much bigger problems for most sysadmins.

---Dan

---

From: Terry Lambert <[email-masked]>
Date: Mon, 08 May 2000 13:14:52 -0700

D. J. Bernstein wrote:
> On the contrary. They're still slaves. DNS records are edited
> on the master and then copied to the slaves. The only difference
> is that the copying happens through a better protocol.
> 
> BIND incorrectly refers to these slaves as ``masters,'' because
> BIND incorrectly assumes that all replication will take place
> through the crude protocols built into BIND; but these mistakes
> don't change the reality of what's happening.

In that case, my master is an SQL database from which
the DNS configuration data is derived.

I think that, semantic games aside, your method will
result in not having explicit configuration exposed to
call out the relationship between the servers.

It also means that your slaves will be clones of your
master, and you may not want that; in particular, if I
am going to have three machines at three colocation
facilities for high availability and robustness in the
face of the occasional fiber cut, then the load on each
of the machines is 2/3rds of my total zones, with each
zone served by two facilities.

Assymetry can be both intentional and useful.

> You keep saying that these things can't be done, but
> they can be, and they often are, because existing
> general-purpose tools do the job today, while DNS-specific
> vaporware doesn't.

I don't say that "it can't be done", I say "it would be
unwise to do it this way" and "use of ssh is administratively
prohibited".

> I didn't say that demultiplexing couldn't be done in a DNS
> server. I said that it adds unnecessary implementation
> costs for modular servers.  A competent protocol designer
> will use separate ports to take advantage of the
> demultiplexing features that are already provided by UDP/IP
> and TCP/IP stacks.

I have figured out why this bothers me so much.  It is the
same argument one would use to justify using ssh to deliver
email, rather than overloading the SMTP port by adding more
commands that the command interpreter then has to demux.

It's the job of DNS to deal with DNS data, just as it is the
job of SMTP to transport email.

> > implementation.
> You mentioned a BIND implementation flaw, namely failure
> to answer queries while new data is being read. You
> mischaracterized this flaw as a problem in replication
> protocols that use rsync+ssh. (When you hear that BIND's
> IXFR implementation keeps crashing, do you conclude that
> I pointed out that these outages simply don't occur with
> tinydns-data. This makes clear that your problems are with
> one implementation, not with the protocol.

I think the flaw lies not in reading new data causing the
server to be unresponsive, but the fact that the new data
is actualized by being read, instead of having some other
protocol-based method of communicating it to the server.

If you use a protocol to communicate the new data, rather
than hacking files and clubbing the server over the head,
then there is no unresponsiveness problem.

In other words, this is a protocol problem, not an
implementation problem.

Yes, it's possible to replicate data with some external
mechanism that will be non-interoperable between all of
the DNS servers on the planet because everyone has their
own favorite Rube-Goldberg one-off set of scripts.  But it
it not wise to do this.  It is better to define a protocol
that everyone who wishes to claim compliance with the RFCs
will have to implement.

I think it's ridiculous to put this protocol on a new port
for no apparent technical reason, givem that DNS servers
must already demux based on command code, and adding another
command code doesn't increase the mux complexity one whit,
but perhaps you can get the working group to buy off on the
idea (I doubt it; they probably have their own firewall
gestappo to contend with when it comes to opening yet more
ports).

-- Terry Lambert

---

From: Robert Elz <[email-masked]>
Date: Tue, 09 May 2000 04:51:54 +1000

Date:        8 May 2000 00:13:23 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Paul A Vixie writes:
  | > serial number comparison including 32-bit wrapping,
  | 
  | The normal use of ssh for DNS replication doesn't rely on serial numbers
  | at all. The master immediately pushes new data to the slaves.

That's broken.  If the secondary has a higher serial number than the
master, it must not update to the master's copy.  That allows data to
be preserved when the master recovers from a backup, and ends up with an
older zone copy.  Before dynamic update that might not have been all that
important, as lost updates would often just be done again at the master
(though I generally preferred to AXFR the zone back from the secondary),
but with dynamic update, if the master loses updates that have been made,
and secondaries then blindly follow, there's a totally unnecessary data loss.

Not only that, but it is entirely reasonable for a cache to determine the
serial number of a zone, and internally refresh all RRs it has from that
zone by just verifying that the serial number has not increased at an
authoritative server (essentially pretending it had just done queries
on all the RRs and had the same data returned, but with new TTLs).
If the serial number protocols aren't followed correctly, all that breaks.

  | One advantage of pushing data in the foreground through ssh is that you
  | receive immediate and reliable notification if anything goes wrong.

That's an implementation nit.   It is entirely possible to use ssh in
a way that you don't get that notification.  It is also entirely possible
to use the AXFR protocols and provide all the notification that you
could want (either with the secondary providing the notification of
a failure, or with the primary notifying cases where the zone has not
been compleetly fetched, and most likely with both - the primary logs
work when the secondary ihas simply forgotten the zone, including when it
has crashed, and the secondary notification working when the transfer is
attempted, but for some reason does not succeed properly).

  | I'm not saying that refresh-retry-expire is difficult to implement. I'm
  | saying that it's a poor substitute for what people actually want.

It is an essential part of the protocol.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 9 May 2000 03:28:28 -0000

[ this is the last message on this subject i plan to approve on
  namedroppers.  folk, please take it to dnsop or elsewhere. -- rabdy ]

Robert Elz writes:
> when the master recovers from a backup, and ends up with an older zone

One of the virtues of immediate replication is that, if one machine
dies, the sysadmin has up-to-date copies of the data on other machines.

In particular, if the master dies, the sysadmin can set up one of the
other machines as a master, or copy the up-to-date information to a new
master, so your ``totally unnecessary data loss'' simply doesn't occur.

Furthermore, if the sysadmin _does_ decide that he wants to move the
master back to the data he had before, proper replication means that the
slaves will do the same thing. Slaves cause an incredible amount of
damage when they fail to copy data that they don't like.

> It is also entirely possible to use the AXFR protocols and provide all
> the notification that you could want 

When a sysadmin uses rsync+ssh with tinydns, he can type

   ./add-mx lion.heaven.af.mil 1.2.3.5
   make

and reliably see any relevant error messages before the next prompt.
Normally the next prompt shows up very quickly with no error message;
this guarantees that the new data is available from the master and from
all the slaves.

The IETF DNS protocols don't support these features. AXFR-based
replication is slow, even with NOTIFY; see RFC 1996, section 4.3. The
master isn't told when a transfer succeeds; it has to poll for new data,
wasting even more time. Most importantly, there's no way for the master
to find out what went wrong if a transfer fails.

---Dan

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 09 May 2000 15:35:25 -0400

>   namedroppers.  folk, please take it to dnsop or elsewhere. -- rabdy ]

Whoa, wait just a minute there! Could we at least call for a rough
concensus on whether the ban on SOA addition/deletion should be excised in
2136bis? If nothing else in this thread, *that* is strictly a protocol
issue.

- Kevin