Subject: Re: dynamic update zone

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 12 Sep 2002 11:10:04 -0400

> 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).

Is there any change in desired client retry behavior for REFUSED vs
your proposed FROZEN?  I'm thinking mostly of the embedded/automatic
case here..

						- Bill

--
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: Paul Vixie <[email-masked]>
Date: Mon, 16 Sep 2002 14:20:52 +0000

> >it's starting to seem to me that answers containing NXT should include an
> >SOA in the authority section.  (even though that means nonauthoritative
> >servers will have to cache them, which today is illegal.)  when new secure
> >(verified) data arrives with a later SOA.SERIAL, all the older cached data
> >for that zone becomes invalid.
> 
> NXT's are already supposed to only be signed by the zone key.  Isn't 
> that sufficient to identify the authority - or is there something 
> else needed out of the SOA RR RDATA?

if there's enough info in the signature to be able to tell what other cached
data you should preexpire, then no.  however, i don't think that's the case;
all you can know, afaik, is that the records you're holding were signed less
recently than the records you're now receiving.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 16 Sep 2002 10:33:20 -0400

At 4:04PM +0200 9/16/02, Roy Arends wrote:
>The signer of the zone has give proof that there exist no signed material
>in an interval.

The problem is that, when considering wildcards, "interval" is not 
singular but plural.  E.g., there must be proof that there exists no 
signed material in each interval that a name might fit.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Derek Atkins <[email-masked]>
Date: 16 Sep 2002 10:48:13 -0400

> signed material in each interval that a name might fit.

No, it's singular because the wildcard is applied to each request
individually.  So you need to show proof-of-nonexistence in the
query-interval on each query.  This is a seperable problem, as queries
are independent.

-derek

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 16 Sep 2002 11:18:40 -0400

>query-interval on each query.  This is a seperable problem, as queries

When you follow the wildcard algorithm, you need to search through 
different intervals.  First the explicit one followed by all 
intervals that might hold a wildcard.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Derek Atkins <[email-masked]>
Date: 16 Sep 2002 11:38:25 -0400

Edward Lewis <[email-masked]> writes:

> different intervals.  First the explicit one followed by all intervals
> that might hold a wildcard.

Ahh, I see -- to collect multiple NXT records in the case of a
multi-level zone.  I keep on assuming zones with single levels.
My appologies.

-derek

---

From: Paul Vixie <[email-masked]>
Date: Mon, 16 Sep 2002 17:19:01 +0000

> The problem is that, when considering wildcards, ...

...DNSSEC ought not be used.

C'mon, folks.  We're already seven years into this.  Let's cut the things
that don't work and run with what's left.  I posted my analysis of various
uses for wildcards and showed why, imho, none of them intersect with a strong
need for DNSSEC.  I'm here today renewing my proposal:

	Signed zones shall not include RR's with wildcard names.

---

From: Mark Kosters <[email-masked]>
Date: Mon, 16 Sep 2002 14:10:02 -0400

> 	Signed zones shall not include RR's with wildcard names.

I agree with this. I hear what Olafur is saying about supporting wildcards
but that can be done by synthesizing the response based off a wildcard 
defined in a configuration file. 

Mark

-- 

Mark Kosters          [email-masked]       Verisign Applied Research

---

From: David Conrad <[email-masked]>
Date: Mon, 16 Sep 2002 11:34:05 -0700

This will, I'm told by folks who run large zones (other than .COM), will
result in DNSSEC not being deployed in those zones.  Doesn't seem to be an
optimal approach if we want DNSSEC deployed.

Rgds,
-drc

---

From: Randy Bush <[email-masked]>
Date: Tue, 17 Sep 2002 11:12:36 +0300

> Signed zones shall not include RR's with wildcard names.

<since we seem to be in repeat mode>

unfortunately this won't fly.  enum alone has a serious need
for it.

randy

---

From: Paul Vixie <[email-masked]>
Date: Wed, 18 Sep 2002 14:28:09 +0000

> ...  The question is:
> 
>       Do other (not com.) large zone registrars feel that opt-in is
>       necessary?  I'm assuming that there are zones other than com. with
>       over a million subdomains.

i don't have such a domain.  however, i think opt-in is architecturally
right -- something that should have been in the protocol from the get-go.
as such, i would use opt-in on all of my zones.  delegations to unsigned
subzones should not, in my view, require NXT RR's, because the name is
not really in the parent, it's the apex of some other zone.  if opt-in is
available, it's my hope that the "." zone will use it.

> I'd really like to see a working prototype of an opt-in server - so 
> we can play.

likewise, hoping for same, soon.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 18 Sep 2002 23:25:21 +0000

> The issue is that in 2136 "NOTAUTH" seems to mean not authoritative 
> and in 2854 "NOTAUTH" seems to mean not authenticated.

2845 is tsig.  what's 2854?

the problem isn't inconsistency.  any message type has its own uses
for the various fixed header fields including RCODE.  that's why EDNS
adds more bits to RCODE without saying what they mean -- because EDNS
is not opcode-specific other than where it explicitly says so, like
the fact that OPT applies to opcode "query".

2845 can be viewed as wrong since it overloads an rcode pattern that
means something else to a specific opcode, 2136 "update" in this case.