Subject: [dnsext] open issues on SHADOW

From: Paul Vixie <[email-masked]>
Date: Wed, 14 Apr 2010 19:31:00 +0000

in INTERNET-DRAFT <draft-vixie-dnsext-dnsshadow-00.txt>, i wrote:

> 4. Open Issues
> 
>    4.1. Using a different default origin and then not touching fully-
>    qualified names is weak.  It plays especially poorly with fully
>    dynamic zone content or database back ends.  We either need to tail-
>    replace the Amber apex with each Shadow apex, or we need to add new
>    signalling somehow.
> 
>    4.2. Not allowing updates on shadows is weak.  We should probably
>    just outlaw the use of Shadow names within zone content, and do the
>    substitution of Shadow apex by Amber apex.  Note that this gets messy
>    if the update came with its own DNSSEC metadata for the new or
>    modified RRsets.
> 
>    4.3. Doing full Shadow regeneration after each UPDATE is weak.  We
>    need to figure out some way to, um, shadow the updates.  This gets
>    messy if DNSSEC is involved and if the signer is external to the
>    primary master server (like if there are offline keys).
> 
>    4.4. The Security Considerations section is empty, which seems wrong.

let's take these one at a time.

4.1: as andreas pointed out, the problem identified in 4.1 produces an
unfortunate dependency on "master file format", and it's generally known
that a lot of zones are stored in database form, where there is not nec'ily
an opportunity to fully qualify names at time of zone loading (since there
is no loading.)  i've been trying to think of a "new signalling" mechanism
that would allow an Amber zone to contain names in RDATA that are sometimes
tail-replaced with the Shadow zone (so, NS.VIX.COM may become NS.VIXIE.COM)
but are sometimes not (so, sometimes an NS.VIX.COM remains NS.VIX.COM even
in the Shadow zone.)  it's noteworthy that the signalling that would control
this does not appear on the wire -- Shadow zones are generated on the primary
master server that the contents of transfers and queries are only of the
generated content.  as such, i think that any "database backend" nameserver
implementation can simply invent its own signalling for this case, and that
in the specification for SHADOW we can talk only about master file format
since that's what RFC 1035 specifies.  along those lines, i think that we
can extend master file format to say that an extra dot on a name makes it
fully qualified and also immune to Shadow zone transformation.  so in my
above example, "NS.VIX.COM." in an Amber zone master file would become
"NS.VIX.COM." in the Amber zone but "NS.VIXIE.COM." in the shadow zone,
whereas "NS.VIX.COM.." in the would become "NS.VIX.COM." in both the Amber
and Shadow zones.  objections and dunce caps welcome.

4.2: upon reflection i am inclined to just remove 4.2 and have it be that
updates really have to take place on Amber zones, never Shadow zones.  ideas
on how to express substitutable vs. nonsubstitutable tail-domain's inside an
UPDATE, which means a wire-visible protocol difference, would be interesting.
however, i don't see this problem as worthy of the complexity required by
any imaginable solution.  objections to dismissing the concern and removing
4.2 should be accompanied by simple ideas of how to implement UPDATE on a
Shadow zone.

4.3: upon reflection, the document overspecifies by saying "regenerate all
Shadows on every UPDATE to the Amber zone."  what the document should say is
that the externally visible effect must be the same as if such regeneration
had been done.  implementors are free to either burn a lot of resources doing
it the hard way, or do UPDATE propagation from an Amber zone to its Shadows
in some way that respects the signalling indicated in my "4.1" comments above.
any objections to removing 4.3 and changing the text to indicate the desired
wire-visible result rather than mandating the activities that produce that
result, should be accompanied by better motivation than i gave in "4.3" above.

4.4: the only security consideration that comes to mind is to remind folks
that they have to utterly and completely trust their secondary name server
operators, but that seems like spoon-fed pap.  everybody should already know
this.  what else can somebody think of, as a serious security concern about
SHADOW?

---

From: Jim Reid <[email-masked]>
Date: Wed, 14 Apr 2010 20:50:39 +0100

On 14 Apr 2010, at 20:31, Paul Vixie wrote:

> what else can somebody think of, as a serious security concern about  
> SHADOW?

DoS attacks on the slave? You rightly mentioned master servers  
trusting their slave operators. Though I'm not if this has ever been  
written down somewhere. But what about slaves trusting the master?  
Suppose an evil master server provisions a bazillion shadow zones to  
take out some slave. I'm thinking here of cases where the victim is  
hosting other, more important zones as well as the evil master's zone  
and its shadows. Perhaps there should be an opcode for signalling  
"this is too many shadow zones" or something like that?

---

From: Douglas Otis <[email-masked]>
Date: Thu, 15 Apr 2010 12:10:35 -0700

On 4/14/10 4:54 PM, Paul Vixie wrote:
>> Date: Wed, 14 Apr 2010 15:16:01 -0700
>> From: Douglas Otis<[email-masked]>
>>
>> Just as there is meta information placed in the Amber zones to enumerate
>> Shadow zones, there could be meta information placed in Shadows to
>> confirm expected receipt of the Amber zone.  Perhaps the Shadow meta
>> information could include a time frame where at least a null transfer
>> must occur or an error would be reported.
>>      
> this amounts to a maximum time limit enforced in the secondary as to how
> much time can elapse between a NOTIFY for the Amber and the last NOTIFY
> for a Shadow, and i think this should be a server level configuration
> item since the secondary server operator is the one who will get the
> error notifications.
>    

The set of Shadow zones should be fairly constant, where administrative 
saving occurs when content of Amber zones change.

Currently, this scheme has an open definition with respect to update 
rates and access allowance delays.  A simple interval statement could 
help suppress errors generated by the respective Amber or Shadow 
servers, since configurations that relate to update rates and access 
control delays are not likely visible between servers.   There is also 
the possible side effect of making the Shadow recognizable with the 
presences of a vector to the Amber zone containing an error hold-off 
interval.  The idea is to make it easier to manage by affording a way to 
suppress errors.

-Doug