Subject: Re: [Enum] How long will it take to update a NAPTR record?

From: "bill" <[email-masked]>
Date: Tue, 19 Mar 2002 08:06:46 -0800

> 
> This is straightforward on a UNIX system. Tools like at or cron 
> can be
> used to arrange for things to be done at a specific time. 

Thanks, Jim. May you give me more information about the tools you 
mentioned and I can study in depth. 

>For instance
> they could run scripts that call nsupdate to make a Dynamic Update
> request. The trick will be to ensure that the update gets propagated
> quickly to all the zone's name servers and that any stale data for the
> name that gets updated doesn't get cached for too long by other name
> servers.

I think for DNS itself Dynamic Update machnism can solve some problems 
of the real time updating requirement brought by telcom service. Patrik 
has give me data about how soon it will be. Can you give me some 
quantitified evidence how fast the DNS update can be?

Bill

CNNIC

2002/03/19

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Tue, 19 Mar 2002 08:38:29 -0800

>>>>> "bill" == bill  <[email-masked]> writes:

    bill> I think for DNS itself Dynamic Update machnism can solve
    bill> some problems of the real time updating requirement brought
    bill> by telcom service. Patrik has give me data about how soon it
    bill> will be. Can you give me some quantitified evidence how fast
    bill> the DNS update can be?

I don't have any numbers and I'm not aware of any benchmarking that's
been done in this area. You could maybe adapt the Dynamic DNS stuff
from the BIND9 test suite to get some rough benchmarks. I'd expect a
decent name server to handle at least tens of dynamic update requests
per second, possibly much more than that. It'll depend on things like
how the requests are authenticated, how the zone is represented in
stable storage, the OS and hardware platform, etc. If Secure Dynamic
Update is used, throughput will obviously be lower because the server
will need to compute signatures and juggle NXT records.

Even so, it's not just the throughput of DDNS requests that need to be
considered. Propagation of the updates via AXFR or IXFR to the zone's
slave servers will have to be taken into account too. This is probably
more of a limiting factor on the throughput of dynamic updates.

For ENUM I don't think there are any serious performance constraints
here provided the server and zone setups are sensibly engineered. ie
Updating 1 RR should not cause everything in a 2Gb zone file to be
re-signed or mean the whole zone gets sent to its slaves with AXFR.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 19 Mar 2002 11:22:29 -0600

> more of a limiting factor on the throughput of dynamic updates.

As each number most certainly will be it's own zone (where the NAPTR's are)
this is not a problem. You have a problem if you have large amount of
updates to the _same_ zone.

  paf

---

From: Jim Reid <[email-masked]>
Date: Tue, 19 Mar 2002 10:59:30 -0800

>>>>> "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= <ISO-8859-1> writes:

    >> Even so, it's not just the throughput of DDNS requests that
    >> need to be considered. Propagation of the updates via AXFR or
    >> IXFR to the zone's slave servers will have to be taken into
    >> account too. This is probably more of a limiting factor on the
    >> throughput of dynamic updates.

    paf> As each number most certainly will be it's own zone (where
    paf> the NAPTR's are) this is not a problem. 

I'm not sure I agree with you, though I accept that in principle
dynamic updates to small zones should propagate quickly to the zone's
slave servers. A server's ability to propagate new copies of the zone
can be orthogonal to the rate at which it can dynamically update the
zone: commit the update to stable storage and bump up the SOA serial
number, send out NOTIFYs and then hope the slaves respond quickly
enough with an IXFR or AXFR that doesn't run forever. There's not much
point in some master server processing a dynamic update in say 10ms if
it takes days for the slave servers to converge on the new zone
data. [I exaggerate for effect.]

I have heard of slave servers that have been unable to converge on new
zone data, usually because they have too many zones (100K+) and get
swamped with NOTIFYs or refresh queries or inbound zone transfers.

    paf> You have a problem if you have large amount of updates to the
    paf> _same_ zone. 

Oh yeah -- too true.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 19 Mar 2002 13:28:16 -0600

--On 2002-03-19 10.59 -0800 Jim Reid <[email-masked]> wrote:

> slave servers.

We agree Jim. My point was that if you have a large number of records, you
will also have a large number of updates to a zone. This is based on the
fact that I think that each record will be updated say 1 time / week. If
each record is updated once a week, if you have one record in your zone,
that leads to one change a week. If you have 600k records, that means one
update a second.

I rather have a server which have one update a week than once a second.

Just think about the serial number, and how often the authoritative servers
are in sync.

   paf