X-RT-Original-Encoding: utf-8
X-RT-Interface: Web
Content-Disposition: inline
Content-Transfer-Encoding: binary
References: <RT-Ticket-45416@isc.org>
 <rt-4.2.8-23561-1497952340-1578.45416-7-0@isc.org>
 <rt-4.2.8-23561-1497953542-1789.45416-7-0@isc.org>
 <20170622202604.GA7148@jurassic>
 <rt-4.4.1-17109-1498163174-1274.45416-0-0@isc.org>
Message-ID: <rt-4.4.1-49360-1498565168-360.45416-0-0@isc.org>
In-Reply-To: <rt-4.4.1-17109-1498163174-1274.45416-0-0@isc.org>
X-Mailer: MIME-tools 5.508 (Entity 5.508)
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
RT-Send-CC:
Content-Length: 687

On Thu Jun 22 20:26:14 2017, muks wrote:
> RFC 2136 covers this:
> 
> 7.18. Previously existing names which are occluded by a new zone cut
> are still considered part of the parent zone, for the purposes of
> zone transfers, even though queries for such names will be referred
> to the new subzone's servers.  If a zone cut is removed, all parent
> zone names that were occluded by it will again become visible to
> queries.  (This is a clarification of [RFC1034].)
> 
> Occlusion is not an error. A similar situation can occur with DNAME
> too.
> 
> Mukund

Ah OK - in that case, I think there is nothing we can reasonable do here, unless we think it worthwhile to add a warning.

Cathy