At 12:06 +0200 10/27/11, Havard Eidnes wrote:
Hi,
a.z. NS some.name.server.
sub.a.z. NS some.other.name.server.
My claim is that it is a "Registry Error" for the operator of the
registry for the 'z' domain to permit this to happen, as it
violates the basic idea of what a "delegation" means.
Depending on what you mean by "exposed..."
It's possible to see this in a zone transfer, possibly occurring as a
result of a dynamic update that added a.z's NS set after sub.a.z
existed. What I recall from discussions (meaning I don't know if
this is in a document) is that the dynamic update "occludes" (hides,
as in the sense that the moon occludes the sun in a solar eclipse)
the sub.a.z name. The rationale for this is as follows.
When getting the dynamic update adding a.z/IN/NS, you have a design
choice. You can refuse the update because there are names in the
zone below a.z. You can eliminate the now out-of-zone data because
the zone is not authoritative for it. Or you can occlude the data,
meaning hold it in the zone (AXFR) but not consult it when answering
a query.
The last approach is better than the first because a "bounce" is
avoided. The last approach is better than the second because the
user can "undo" the dynamic update add with a delete at a minimum of
effort to the name server. Mark Andrews noted that in his support
experience, users often make a mistake and want to undo it.
So this may not be a "registry error" but a way to maintain the
ability to undo an addition. Of course, it may be a "registry error"
but some name server implementations wouldn't let you load this zone
from a user file. (Slaves would load from their backup files on
restart; they would accept this in AXFR/IXFR.)
Back to "expose" - if some.name.server. and some.other.name.server
are the same process (even if the IP addresses are different for the
names, etc.) it might appear that both delegations are in effect.
There was once ip6.int which had all of it's delegations broken, but
all fragments were on the same set of servers anyway. The only way
to tell that the cut points were wrong was to get the AXFR and
inspect it because name servers always give you the "best" answer
they can as according to step 2 of the algorithm in RFC 1034, section
4.3.2. (All DNS geeks should have that section pinned to their wall
at home.)
But, yes, this is "broken" for some definition of broken. What
happens in the query processing would never reach the deeper
delegation IF you started in that zone. I'd test this by standing up
a series of name server processes each with just one zone. You can
have them on one OS but use multiple addresses (such as 127.0.0.2
127.0.0.3 and so on on the loopback interface with host routes), so
long as they are separate processes. With this you'll see what name
server implementations really do. It's the only way to isolate "step
2" referred to above.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
Vote for the word of the day:
"Papa"razzi - father that constantly takes photos of the baby
Corpureaucracy - The institution of corporate "red tape"
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
