Subject: Re: dynamic update zone

From: "Scott Rose" <[email-masked]>
Date: Thu, 12 Sep 2002 15:23:38 -0400

----- Original Message -----
From: "Edward Lewis" <[email-masked]>

> There is one implementation of dynamic update (snapshot of a future
> BIND) that allows a dynamically updated zone to be frozen - temporary
> suspension of dynamicity to allow of manual changes to a zone.  It's
> a cool feature...
>
> When a zone is frozen, the returned status code is REFUSED, as per
> section 2.2 of RFC 2136.  The implementation is faithful to this, but
> I wonder if defining a different status code such as "FROZEN" or
> "NOTDYN" is better.
>
> The rationale for this is that might be good to tell the updater that
> the refusal is temporary as opposed to a violation of policy.  There
> has been talk of using dynamic update in situations where direct
> communications between the updater and the admin may be difficult
> (which is why dynamic updates are in use).
> --

My guess is that updaters would know what the policy is, so when the got a
REFUSED back, they know it is frozen, since they should be able to update
the zone normally.

But I can see the proposed RCODE if the process is automated (DHCP/DNS
interaction).  But there should be some sort of client retry rule of thumb
to prevent server pounding as hundreds of new hosts try to update the IETF
reverse DNS server with their name and newly allocated IP address (for
example).   In this case - is it necessarily bad that the client may never
decide to try again and send another update request?

Scott

--
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: Edward Lewis <[email-masked]>
Date: Fri, 13 Sep 2002 09:40:35 +0300

>REFUSED back, they know it is frozen, since they should be able to update

I'm not so sure that is true even when the client is human (run).  If 
the client is a regsitrar and the server is being run by a registry, 
the coupling of updater to admin may be very loose - esp. 
organization-wise.

>decide to try again and send another update request?

The problem is whether the client has the information to make the 
decision.  E.g., a person may try an update and see a failure. 
Depending on a lot of factors, the person might be correct to retry 
in an hour or might be correct to not try that query again.  One 
factor just might be whether the person is told that "your key might 
be authorized to make this change, but I'm not listening now" or 
"your key is not authorized to make that change."  (Just an example 
scenario.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 13 Sep 2002 08:15:47 -0400

----- Original Message -----
> "your key is not authorized to make that change."  (Just an example

Okay - that example clears things up for me.  My only worry is poorly
written implementations that interpret this new "FROZEN" or whatever,
response and keep hammering away at the server until they get a more
positive response.  Of course this can happen already when REFUSED is
returned...

If I'm thinking correctly about this, the new interpretation of the rcodes
would be:
refused - means that the server will never accept an update from the sender
until some misconfiguration is correct, or policy stuff.

frozen(whatever) - means that the sender could normally make the update, but
the server has been frozen by an admin for some time period.  Try again
later and it might suceed.

correct?

Scott

---

From: Rob Austein <[email-masked]>
Date: Fri, 13 Sep 2002 14:37:31 -0400

I completely agree that we need some RCODE that we agree to interpret
as "permanently refused" where "permanently" may or may not mean
"forever" but definitely does mean "do not retry!".  I have no real
problem with concluding that the existing REFUSED RCODE should be
interpreted that way, assuming that (a) nobody knows of an existing
implementation that this would break and (b) this gets written up.

While I see some potential value in some kind of "refused temporarily"
RCODE per Ed's scenario, I am leery of heading down that path unless
we can provide some guidance on a sane retry strategy.  The catch is
that it's hard to picture a strategy that would be right for all
circumstances, at best one could invent one that might be harmless.

There is of course the alternative of adding a new field to the OPT
psuedo-RR that would specify a minimum interval after which it would
be ok for the client to retry.  If we took that approach, REFUSED
without that field present would mean "permanently refused", while
presence of that field would mean "refused for now, but if you try
again in N seconds you wouldn't be pestering me and it might work".

---

From: Robert Elz <[email-masked]>
Date: Sun, 15 Sep 2002 13:20:00 +0700

Date:        Fri, 13 Sep 2002 14:37:31 -0400
    From:        Rob Austein <[email-masked]>
    Message-ID:  <[email-masked]>

  | There is of course the alternative of adding a new field to the OPT
  | psuedo-RR that would specify a minimum interval after which it would
  | be ok for the client to retry.

This is an excellent idea - except that we should generalize it.

That is, what we want here, is for the client to cache the REFUSED for
some period of time, and then try again.

This is exactly what we want when we send other errors - even NXDOMAIN,
we want the client to cache the value for some time, and then it can try
again.

Currently, we're using the SOA record, for that purpose, but that's truly
sub-optimal, and totally inapplicable for anything other than NXDOMAIN.

So, yes, please let's add a "error cache TTL" field, define 0 as "not
specified here, do what you would have otherwise done" (for backward
compatibility), "-1" (or ~0 if you prefer) as "don't cache this, try again
next time you need to know", and any other value as the TTL that the client
can use to cache this particular error, before trying again.

I don't think we need "permanent" - any long value is going to exceed the
client's patience anyway (clients all set upper bounds on any such information
in any case, and discard it, no-one believes in permanent errors).

For NXDOMAIN, the SOA record will keep being added, as the authority for
the denial, and old clients can keep on using it as the source of the
cache TTL (with the same kind of sanity upper bound as currently used).

But with this, there'd be an explicit TTL on all errors (it should most
likely include "no error no data" as well).

To allow this to need fewer bits, it could be defined as being in multiple
second units.   I think a range of up to 1 day is enough, caching errors
longer than that is unlikely to be useful (or believed).   That's 86400
seconds.   Make the field count in 2 second units, and a 16 bit field would
be enough for this. (2^16 * 2 = 128K - a day and a half approx).

kre

---

From: Rob Austein <[email-masked]>
Date: Sun, 15 Sep 2002 10:14:27 -0400

I think we need to distinguish between server errors and data errors.
RCODE=3 is a property of the zone, RCODE=5 is a server error.

Server errors seem a good match for an OPT psuedo-RR extension, but I
don't think an OPT extension is suitable for errors that reflect
properties of the zone.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 15 Sep 2002 14:04:11 -0500

> can use to cache this particular error, before trying again.

Yeah this would be useful supplemental information. A few comments.

One other benefit to the use of such a field is that it makes per-server
tracking more feasible. The requester will know that the server supports
the reporting feature but not the requested extension (or the operation),
which is more granular information than can be obtained without the field.

However, it would still be inadequate for corner cases. Each extension
would still have to define their own fallback processing and recovery
mechanisms, and (more importantly) the specific errors which trigger the
different fallback strategies necessary for the extension at hand. This
means some kind of default error-cache document would still need to be
provided which defined default conditions and which delegated the
interpretation and recovery actions to each extension.

Also, not all extensions and errors will be related to EDNS extensions
(DDNS errors, for example). Also, the presence of this information may
have the potential to trigger subsequent errors during requester
processing. For these reasons, the generalized caching document would need
to treat any EDNS-specific error-TTL field as supplemental, not as core.

Also, there are some obscure errors which can show up in weird situations
which would not be served by this field. Some servers silently discard
errors rather than reporting them, for example. While this can be argued
as correct or incorrect forever, it is an example of an error which may
need to be trapped and cached by some extension, but with no information
being made available to the requester.

For all of these reasons, it would be useful as supplemental information
but it would not BY ITSELF be sufficient.

As to Robert's suggested values above, I would think that omitting the
field would be sufficient for "use the default interpretation" while 0
would be appropriate for "don't cache this error" This is especially true
since there are several potential scenarios where the data will be
ommitted anyway (included unextended servers, obviously).

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Edward Lewis <[email-masked]>
Date: Sat, 14 Sep 2002 07:14:49 -0400

>later and it might suceed.

That sounds like what I had in mind.

For a manual (interactive) client, I think that the difference 
between the two would be to print "permanent error" for a REFUSED, 
and "temporary error" for a FROZEN (or SUSPENDED).  For an automated 
client, I probably wouldn't recommend different treatments - so as to 
prevent overly persistent broken implementations.  (Perhaps the log 
message is different in the two cases, as suggested for the manual 
client.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Robert Elz <[email-masked]>
Date: Tue, 17 Sep 2002 17:19:18 +0700

Date:        Sun, 15 Sep 2002 10:14:27 -0400
    From:        Rob Austein <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think we need to distinguish between server errors and data errors.
  | RCODE=3 is a property of the zone, RCODE=5 is a server error.

I think that's too fine a hair to cut.  Certainly if you get a 3
from any server, you should get it from all, hence there's no
point trying a different server, whereas that isn't true of 2, 4, or 5.

But I'm not sure that really matters.  The client (resolver) already
needs to know to treat the different errors differently, adding an
explicit TTL to the error response doesn't really change the nature
of anything.

It may seem that using the OPT RR, which at first glance, carries only
server specific information to carry information which is a property of
the zone instead would not be a good fit.   Except that it is already
specified to be able to carry information that is the property of the
zone - the extra bits of the error number (rcode) can be used to convey
either kind of error (as defined in the future).  So might the flag bits.

OPT is best thought of as just a part of the DNS header - and just as
the DNS header RCODE can carry server specific, and zone specific, error
codes, there's no reason why a error-ttl field in the OPT RR shouldn't
be able to hold either server specific, or zone specific, ttls.

kre