Subject: [dnsext] Solution Statement

From: Brian Dickson <[email-masked]>
Date: Thu, 2 Sep 2010 17:00:10 -0300

This is an informal write-up of a combination of ideas, which *may* form the
basis for one possible solution, for the not-yet-quite-specified problem
statement (i.e. "What is 'the same', and what requirements are there for
'the same' in DNS?").

This may be useful nonetheless, notwithstanding the absence of a
well-defined problem.

In other words, it may yield something the WG decides is useful enough to
explore further and possibly adopt as a WG item.

Once it has had sufficient feedback and once enough interest is expressed, I
am willing to write it up more formally, i.e. as an ID.

(I've tried to put some structure to it, but it can probably use some
clean-up and re-working, so apologies in advance.)

Background (AKA "stuff we already know")

A zone is a contiguous portion of the DNS namespace. It includes the DNS
namespace which has a common suffix, but excludes any portions of the
namespace delegated "below" it to another zone or zones (at least in terms
of "authoritative data").
A zone cut is the place at which a zone is delegated. The owner name (FQDN)
exists in both the parent zone and child zone. The parent side is the
delegation itself, and with a few DNSSEC-specific exceptions, RDATA on the
parent side of a zone cut is non-authoritative.

Statements of "the same" (for the purposes of this document alone)

Two zones are "insecurely the same" if the following hold:
- every owner name in each zone has a corresponding owner name in the other
zone
- a corresponding name differs only in the suffix portion, where the suffix
is the owner name of the zone itself
- every non-DNSSEC RRset at each corresponding owner name in both zones is
bitwise identical
- the scope of "the same" is limited to the zone itself, and specifically
excludes every child zone
- the zone cut to each child zone is identical, i.e. the delegation RRSET
RDATA is to the same name, with the same glue data

Two zones are "securely the same" if the following hold:
- the two zones are "insecurely the same"
- each zone is secure, from the perspective of DNSSEC (however that is
achieved, and whatever that means)

It thus holds that given zone "A", whose master file is "master-file-A", can
be made into another zone "B", where zones "A" and "B" are "insecurely the
same",  by copying the master file to "master-file-B", and transforming
"master-file-B", by substituting the owner-name for each node of the zone,
by replacing the suffix for "A" with the suffix for "B".

It should be noted that child "C.A", a zone underneath "A", is separate and
distinct from child "C.B", a zone underneath "B".
If "C.A" exists, by making zone "B" be "insecurely the same" as "A", we
assert the existence of, but do not specify the content of, "C.B". (If we do
not provision something for "C.B", we would have a lame delegation.)

Note Well: We have the ability to decide, at any point in time, to make
"C.B" be "the same" as "C.A", or, to make "C.B" be completely dissimilar to
"C.A".

It is in this way that duplicating zone content (on an authority server) and
transmogrifying it, differs from "mirroring" zones via client-implemented
mechanisms (such as DNAME).

Duplicating a zone limits the scope of identical content to the zone itself.

Client-side directives (DNAME, BNAME, xNAME) necessarily require the
identical content to be the zone and ALL ITS DESCENDANTS.

(We can call this distinction, "splitting heirs".)

Note well - if "A" is a SECURE zone (i.e. a DNSSEC signed zone which
includes all the  NSEC or NSEC3, RRSIG, and DNSKEY records, and delegation
via signed DS from a secure parent zone), and we make "B" "insecurely the
same" as "A", that "B" would be an otherwise identical zone whose security
status would be INSECURE.

So, when we say "A" and "B" are "insecurely the same", we do not make any
assertions about the security status of "A" and "B" individually, only that
it is not (or not necessarily) the case that both "A" and "B" are both
secure.

We should note at this point, that the proposed "SHADOW" zone is an example
of producing such identical zones, in the context of insecure zones.

The "SHADOW" proposal incorporates additional steps to make secure zones be
"the same".

Ways To Secure "insecurely the same" Zones

Let us first consider what would happen if we blindly performed the same
changes in making "B" "insecurely the same" as "A", when "A" was actually a
secure zone. This means, we apply the same transformations to DNSSEC RR
types as well, and we are evaluating the problems with the new zone "B" with
respect to the DNSSEC validation rules.

- All of the RRSIG records in "B" would now have a "signer" value of "A"
- All of the signatures would be based on owner names under "A", not under
"B"
- We would need to create a DS record for "B" in the parent zone for "B",
using "B" as the owner name for the one or more DNSKEY records
- The apex RRSIG for the DNSKEY RRSET would be signed by the wrong name ("A"
instead of "B")

This suggests two possible approaches to turning "insecure B" into "secure
B" (where "B" continues to be "insecurely the same" as "A"):
- generate an entirely new set of RRSIGs with signer of "B", and owner names
subordinate to "B" instead of "A" (i.e., SHADOW)
- find some way to securely "signal" that for signature validation, it is
okay to use "A" instead of "B", for both the owner name suffix, and the
signer name, on all RRSIGs within the zone "B"
- (for both of the above, we presume that we will be creating the proper DS
record, and adding an apex RRSIG on the DNSKEY, with a signer of "B", as
these are preconditions to achieving a status of "secure")

There are numerous examples of "signature delegation" in the real world.
Corporations have "signing officers", who are obviously distinct entities
from the corporation, but whose signature is considered authoritative for
the corporation.
In PKI, a CA "signs" a certificate, which is then conveyed a trust status.
And in DNS, the secure delegation process itself, via DS and DNSKEY, permits
the chaining of trust across delegation boundaries.

So, in order to securely signal an alternate "signer" and thus an alternate
"name" for a secure zone which is already considered "insecurely the same",
and which will now be "securely the same", we would need:
- the name of the alternate signer
- signed by the owner name of the zone (and whose signature is validated via
existing DNSSEC means)
- on a record meant only for this purpose (*)

This RRset would properly need to exist at the apex of the zone.
Ideally, it would exist in all copies of the zone (i.e. in "A" as well as
"B") so that the other DNSSEC records, specifically NSEC/NSEC3, would be
"correct" and consistent.
It would list at a minimum, all the permitted signers; it might inclusively
list all the names by which the zone is known.
The record would need to be signed by the "authoritative" name (i.e. "B", if
"B" wants to delegate the signing authority to "A").
The zone's DNSKEY RRSET would need to be signed by "B" in the copy under "B"
as well, so that the complete validation back to a trust anchor is possible.

We can call this RR type "AKA" for now, generically. The actual RR type is
To Be Determined. However, we can potentially consider a suitable
placeholder for now, which is not processed in DNS RR handling, but which
has RDATA type of "name", and whose use is generally limited to a few
special zones only, and thus may be feasible for this new use case: the PTR
type.

In attempting to validate RRsets in zone "B", the *content* of the data on
the wire, for RRSIGs on D0=1 queries, will be somewhat unexpected, unless
the validator is modified:
- the RRSIG *may* be signed by a name other than an ancestor of the
owner-name
- validate using any matching signer, where the signer name is a member of
the AKA RRSET, after the AKA RRSET is validated per standard RRSIG rules
- the validation only needs to use the RDATA and RRSIG found at the ORIGINAL
query owner-name - no need to look up the RDATA and RRSIG at the alternate
name
- the validation procedure validates the RDATA+RRSIG, using a temporary
owner-name (where the apex owner-name is substituted with the signer-name,
i.e. suffix.signer instead of suffix.owner)

For a validator which has not been updated, the zone "B" would be "insecure"
(since the signer is not an ancestor of the owner, for any RRSIG on any
RRset in zone "B").

Other than the "AKA" record (and possibly not even that, if "PTR" is used
for the AKA), no new RR types are needed.

Excluding validation, zones processed in this manner are "the same", i.e.
"insecurely the same". No changes are needed to stub clients, recursive
resolvers, or authority servers, to achieve this. Only the processing of
zone data is needed, and then only minimally.

Optimizations are achievable by modifying authority server software, so that
the "transmogrify" is handled via the "hard linking" of data structure
elements. E.g. if the internal data structures are suitably built, having
"A" and "B" point to the same memory structure permits the zones "A" and "B"
to be literally identical, and has the side effect of reducing the memory
requirements.

Examples of how this can be used follow...

Example 1 - leaf zones, no children, all identical (trivial case)

zone files foo.example.com and bar.example.com are identical, except for
substituting owner name suffix foo.example.com with bar.example.com.
foo.example.com has AKA record:
foo.example.com PTR foo.example.com

bar.example.com has AKA record:
bar.example.com PTR foo.example.com

Both files have additional RRSIG records for DNSKEY and PTR records at the
zone apex, signed by "bar.example.com".

DNSSEC-unaware resolvers will behave the same for any x.bar.example.com as
for x.foo.example.com (return the same result).
AKA-unaware, DNSSEC-aware validators will return insecure for any
x.bar.example.com, but otherwise identical data, to the secure result for
x.foo.example.com.
AKA-aware, DNSSEC-aware validators will validate x.bar.example.com using the
name x.foo.example.com and signer foo.example.com, and return the same
result and security result as x.foo.example.com.

Example 2 - leaf zones with different (trivial) children (children with same
names have content which differs)

zones foo.example.com and bar.example.com are "securely the same".
child zones "mail.foo.example.com" and "mail.bar.example.com" are different.
child zone "mail.foo.example.com" has an apex MX record of "
foo-mail.example.com.external.mail.provider.example.com".
child zone "mail.bar.example.com" has an apex MX record of "
smtp.bar.example.com".
(Both child zones are served by the same nameserver(s).)

Example 3 - leaf zones of IDN variants under IDN-variant TLDs

The TLD IDN variants are tld1 and tld2.
The IDN variant names are idn1 and idn2.
Thus, all of these are names for the same zone: idn1.tld1, idn2.tld1,
idn1.tld2, idn2.tld2.
In the TLD zones, all four are delegated to the same nameserver(s). Each has
a unique DS record, which differs only in the owner of the DNSKEY.
On the authority servers(s), all four are "securely the same": idn1.tld1,
idn2.tld1, idn1.tld2, idn2.tld2.
Each contains the apex AKA record:
(my apex name)  PTR idn1.tld1.
All RRSIGs are signed by idn1.tld1.
Each zone file has an apex DNSKEY RRset signed using the corresponding name.
Each zone file has an apex AKA (PTR) RRset signed using the corresponding
name.
NB - there is no problem with having a common zone file with all four RRSIGs
on the DNSKEY and AKA(PTR) RRsets - the extra RRSIGs don't match during
validation, and are effectively ignored.

The same result as Example 1 is observed:
The same RDATA is found at each relative name.
An AKA-unaware validator will show idn1.tld1 as secure and the other 3
variants as insecure.
An AKA-aware validator will show all four as secure.

Example 4 - IDN TLD

The TLD has IDN variants tld1 and tld2.
We consider the delegation(s) to IDN variants (which are meant to be "the
same") idn1 and idn2.

At the apex of the TLD, we have the AKA record:
(this_tld) PTR tld1
This AKA record is signed by both "tld1" and "tld2", i.e. there are two
RRSIGs for this RRset.

At the apex of the TLD, we have one or more DNSKEYs.
The DNSKEY RRsets are signed by both "tld1" and "tld2", i.e. there are two
RRSIGs for this RRset.

The TLD zone file is otherwise signed by only "tld1".

The resulting signed zone file is loaded with apex owner "tld1", and with
apex owner "tld2" (after being transmogrified).

The apex DNSKEY RRset is signed by both tld1 and tld2.
The DS record for tld1 is inserted into the root zone at label "tld1.". This
DS record uses "tld1" in the hash calculation.
The DS record for tld2 is inserted into the root zone at label "tld2.". This
DS record uses "tld2" in the hash calculation.

Now we consider the DNSSEC validation of DS records on what should be secure
delegations to the four IDN variants idn1.tld1, idn2.tld1, idn1.tld2, and
idn2.tld2.
For DNSSEC-unaware, the delegations are all fine, and all go to the
appropriate destination nameservers.
For AKA-unaware, DNSSEC-aware validators, idn1.tld1 and idn2.tld1 validate
correctly. idn1.tld2 and idn2.tld2 do not, and thus are insecure
delegations.
For AKA-aware validators, all four are validated correctly.

The question of whether the zones themselves are secure, then turns on the
issue of the child side of the delegations.
If the child side is implemented on an AKA-type set of zones, then idn2.tld1
would only be secure to an AKA-aware validator, and would be insecure to an
AKA-unaware validator.
In all cases, idn1.tld1 would be secure, and the other three would validate
as secure if and only if the validator were AKA-aware.

NB - the IDN TLD is in a position to not only authenticate DS records prior
to insertion, but to ensure that "same" IDN DS records have the "same"
DNSKEY key-id values.
I.e. the IDN TLD could restrict "same" names' delegations to those using the
"same" DNSKEYs, and could further validate the presence of "AKA" RRs at the
delegated zones' apexes (apii? )
On the other hand, TLDs who want the "same"-ness of registrants' zones to be
"opt-in", as it were, are free to do nothing other than point NS/DS records
at appropriate nameservers.

Apex owners always have the ability to implement "the same", on whatever
sets of zones they want.

Example 5 - leaf zones of both IDN TLD and other TLD(s)

This is the same as Example 3, except we add additional names by which the
zone is known.
The apex DNSKEY is signed using the additional names.
The apex AKA RRset (PTR RRset) is signed using the additional names.
The DS records for the additional names are produced and transmitted to the
appropriate parent zones for signing and inclusion.

The primary name always validates as secure.
The additional names only validate as secure if the validator is AKA-aware.

Example 6 - AKA-aware validator

The validator can take advantage of the AKA validation, and return cached
validations based on the validated signer name and previously validated
results (keyed on the temporary owner name rather than the real owner name).
This reduces both the memory usage, and CPU load, resulting from IDN
validation, if the "securely the same" zone uses AKA signing rather than
SHADOW-style re-signing of zone data.

Example 7 - Mix and Match

This example has "same" zones E and F, "same" sub-zones of those A and B,
and child zones of those "C", and grand-children "G".
So, "E" is "the same" as "F".
Zones "A.E", "A.F", "B.E", and "B.F" are "the same".
The Mix and Match comes in at the child zone "C".
We want some, but not all, instances of "C" to be "the same".
So, we set up "C.A.E", "C.B.E", and "C.B.F" to be "the same", but we do
*not* make "C.A.F" be "the same", but instead have something different for
that zone.
And, we can then have "G", which is a child of both "same" and "not the
same" zones, where all instances of "G" are the same (!!).
We would delegate all of G.C.A.E, G.C.A.F, G.C.B.E, and G.C.B.F to the same
nameserver(s), and on those nameservers, set up G accordingly.
G would have an AKA (PTR) RRset at its apex, pointing to its "primary"
(signer) name, e.g. G.C.A.E.
G would be signed accordingly, and the appropriate DS records and DNSKEY
RRsigs installed.
So, w.C.A.F could be different from w.C.B.E, but x.G.C.A.F would always be
the same as x.G.C.B.E...

All of this is done using the appropriate AKA (PTR) records and signatures
in the respective zones.
And, in all cases, security-unaware resolvers get correct results, and
AKA-unaware validators get insecure-but-correct results.

This is just an observation, that it is possible to have "the same" with
"exceptions", with arbitrary levels at which exceptions can be created.
I.e. this provides sufficient mechanisms for expressing completely arbitrary
DAGs in DNS (directed acyclic graphs), with DNSSEC security intact.

(end of write-up.)

Comments and questions are welcome.

And, for those that are interested, I have a working set of code patches to
BIND9, implementing this new validator logic, which works, passes the
regression tests, but needs a bit more polishing. It currently relies on the
necessary records being in-cache instead of fetching them if they are
missing, but does do all of the validation logic on those records.

I've checked on what validators are out there, and the vast majority are
either open-source, or associated with the vendor of an actual service (e.g.
nominum), so I am optimistic regarding the ability to deploy AKA validation
logic if it gets support from the WG. More on the current state of
validators deployed (from Day In The Life) is expected soon.

Brian Dickson

---

From: Alex Bligh <[email-masked]>
Date: Fri, 03 Sep 2010 16:18:51 +0100

Brian,

--On 2 September 2010 17:00:10 -0300 Brian Dickson 
<[email-masked]> wrote:

> This is an informal write-up of a combination of ideas, which *may* form
> the basis for one possible solution, for the not-yet-quite-specified
> problem statement (i.e. "What is 'the same', and what requirements are
> there for 'the same' in DNS?").

I think this is useful.

> Two zones are "insecurely the same" if the following hold:
...
> RDATA is to the same name, with the same glue data

But possibly different DNSSEC data.

> achieved, and whatever that means)

Do we not need to say something about each child zone having
the same security status in both zones? IE in example.com
and example.org, if foo.example.com is securely delegated
but foo.example.org is not securely delegated, then they
are not securely the same.

> It thus holds that given zone "A", whose master file is "master-file-A",
> can be made into another zone "B", where zones "A" and "B" are
> "insecurely the same",  by copying the master file to "master-file-B",
> and transforming "master-file-B", by substituting the owner-name for each
> node of the zone, by replacing the suffix for "A" with the suffix for "B".

And they will end up at least insecurely the same. However, won't
they need to be re-signed?

> It should be noted that child "C.A", a zone underneath "A", is separate
> and distinct from child "C.B", a zone underneath "B".
> assert the existence of, but do not specify the content of, "C.B". (If we
> do not provision something for "C.B", we would have a lame delegation.)
>
> "C.B" be "the same" as "C.A", or, to make "C.B" be completely dissimilar
> to "C.A".

Jiankang Yao said the his criterion was for a guarantee of recursive
sameness. Whether or not one thinks that is operationally helpful, it
would also be useful to define recursive sameness. Straw man:

"Two zones are recursively the same (either securely or insecurely) if
both zone is the same (securely or insecurely as the case may be)
and each child in one zone is recursively the same (securely or insecurely
as the case may be) as the corresponding child in the the other zone."

> identical content to be the zone and ALL ITS DESCENDANTS.

This is true of all suggestions so far, but I am not convinced
it is "necessarily" true. Firstly client side directives could
theoretically specify exceptions to sameness. Secondly, though
it might be a crazy thing to do, I am not sure sameness need
extend below the zone cut. The client side directive could just
be an indirection for that zone, and though children would need
to share nameservers, those nameservers need not respond with the
same data for elements in the child zone, as they receive a fully
qualified QNAME.

> (We can call this distinction, "splitting heirs".)

:-)

> includes all the  NSEC or NSEC3, RRSIG, and DNSKEY records, and
> delegation via signed DS from a secure parent zone), and we make "B"
> "insecurely the same" as "A", that "B" would be an otherwise identical
> zone whose security status would be INSECURE.

I think that was my point about re-signing B.

> Ways To Secure "insecurely the same" Zones

I need a wet towel on my forehead for this bit.

General comment: you started off by developing some language about
different types of solution. It would be useful if we had words
for which side of the zone-cut a client side directive that
made two zones identical lay.

-- 
Alex Bligh

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Sep 2010 09:40:50 +0200

On Fri, Sep 03, 2010 at 04:18:51PM +0100,
 Alex Bligh <[email-masked]> wrote 
 a message of 97 lines which said:

> sameness. Whether or not one thinks that is operationally helpful,
> it would also be useful to define recursive sameness. Straw man:
>
> "Two zones are recursively the same (either securely or insecurely)
> if both zone is the same (securely or insecurely as the case may be)
> and each child in one zone is recursively the same (securely or
> insecurely as the case may be) as the corresponding child in the the
> other zone."

The very definition of "zone" exclude the children. Why not using the
normal DNS terminology? "Two domains are the same is each child is the
same as...". A "recursive zone" is simply a domain.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 06 Sep 2010 11:13:17 +0100

> same as...". A "recursive zone" is simply a domain.

Mainly because I wanted to characterise some solutions as providing
the property of recursive sameness, and some not. But if you want
call it domain sameness vs. zone sameness that's fine.

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Sep 2010 14:23:33 +0000

> Date: Mon, 06 Sep 2010 11:13:17 +0100
> From: Alex Bligh <[email-masked]>
> 

i can live with that distinction, but it will be important to define
it every time it's used, since those words may not convey enough meaning
to a non-technologist or to a non-DNS technologist.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Sep 2010 08:41:08 +1000

> to a non-technologist or to a non-DNS technologist.

I tend to use "name space".  We want the two name spaces to be the same.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian Dickson <[email-masked]>
Date: Mon, 6 Sep 2010 20:24:36 -0300

I think that, regardless of the specific term for the boundaries, the issue
is whether the sameness exists in all descendants of a given name (i.e.
namespace), or whether the sameness observes the same boundaries as a
"zone", i.e. an administrative portion of the namespace.

I also think that, to be useful, we need a solution set (which could consist
of one or more additional "tools" in the DNS toolkit (on the authority
server side of the fence), and/or rules in the functioning of the DNS
system), which provides the following characteristics:
- sameness is possible
- sameness *may* be (relatively easily) accomplished via "the same, with a
small number of exceptions"
- it is not strictly necessary to choose one's poison, i.e. that all the
benefits are available under all circumstances
-- the last because registrants don't get to choose their circumstances; if
they want DNSSEC and happen to live in a portion of the IDN world that
requires more than 2 of everything (worst case being Greek "tonos"?), they
shouldn't have to pay an inordinately high cost to achieve that, relative to
the non-IDN world
- the benefits being seen only when the *client* sees the properly resolved,
and when requested, DNSSEC-validated results, universally -> as few moving
parts touched as possible, with as short a "tail" to deployment as possible

It may be necessary to look at all the elements already deployed, and see
if/how they can be incorporated into possible solutions, to meet all of
these goals.
If we eliminate any of these goals, we should think carefully about whether
that is necessary, and whether it is justified.
I am in favor of clean and elegant solutions, but not at the expense of
working and deployed systems.
(I wasn't around for IPv6 standards development until the very end, and
regret that. But we should learn from the mistakes of others.)

One thing that I noticed when looking through the code in one implementation
of a resolver - there is some potential for use of '*' (wildcard) that might
bear fruit, especially in the "same but with exceptions" notion.

What I think is missing, is the concept of "enumerated" as a variation on
"wildcard".
It would basically list, at a wildcard node, what permitted labels can match
the wildcard, for matching descendants of the wildcard.

So, you would have a zone example.com, which wants to have some "same" sets
of descendants foo1.example.com, foo2,example.com, foo3.example.com, etc.,
and throw in a few exceptions.

The zone would look like:
example.com SOA ...
example.com NS ...
example.com TXT "Other apex stuff here too..."
*.example.com ENUM foo1 ; wildcard '*' only matches against the ENUM RRset
*.example.com ENUM foo2
*.example.com ENUM foo3
www.*.example.com A w.x.y.z ; These resolve the same, but only for
www.foo1.example.com, www.foo2.example.com, and www.foo3.example.com
pop.*.example.com A w2.x2.y2.z2 ; common stuff here
lots.of.sub.*.example.com $RRTYPE $RDATA ; generic stuff in a domain and its
descendants, with variants, all resolving identically
smtp.foo1.example.com MX mail1.foo1.example.com
mail1.foo1.example.com A w1.x1.y1.z1 ; specific RR and RDATA per instance
smtp.foo2.example.com MX third.party.mail.example.com
smtp.foo3.example.com MX other.mailer.foo1.example.com

This may be easier to deploy than the changes to DNSSEC validation, and be
backwards compatible.
At worst, the '*' gives additional answers that would otherwise return
NXDOMAIN or NODATA.

Brian

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 7 Sep 2010 09:44:26 +0200

On Tue, Sep 07, 2010 at 08:41:08AM +1000,
 Mark Andrews <[email-masked]> wrote 

> I tend to use "name space".  We want the two name spaces to be the same.

-1 for the term "name space". A name space is a set of names that are
legal according to some format and logically separated from other name
spaces. It is not a subset of the domain name tree.

-1 for the "we want". No, there is no consensus about that (having a
consistent user experience between two domains may very well *require*
distinct names, such as my example "subtree entirely in traditional
sinographs" vs. "sub tree entirely in simplified sinographs").

---

From: Alex Bligh <[email-masked]>
Date: Tue, 07 Sep 2010 09:08:49 +0100

> sinographs" vs. "sub tree entirely in simplified sinographs").

This is interesting (and sorry I missed this the first time). You are
saying there is a potential use case where
 A1.B1
is equivalent to
 A2.B2
but A1.B2 and A2.B1 do not exist. And the "." may be a zone cut
(e.g. registry/registrant zone cut).

-- 
Alex Bligh

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 7 Sep 2010 13:57:04 +0200

On Tue, Sep 07, 2010 at 09:08:49AM +0100,
 Alex Bligh <[email-masked]> wrote 
 a message of 20 lines which said:

> This is interesting (and sorry I missed this the first time). 

<[email-masked]>

http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg02510.html

> You are
> but A1.B2 and A2.B1 do not exist. 

Exactly.