Subject: [DNSOP] Sanity check

From: Havard Eidnes <[email-masked]>
Date: Thu, 27 Oct 2011 12:06:25 +0200 (CEST)

Hi,

I wonder if I could please have someone say whether they agree
with me on this one:

I've come across a configuration "in the wild" where a given zone
'z' contains both

a.z.	 NS	some.name.server.

*and*

sub.a.z. NS	some.other.name.server.

and where the owner of 'a.z' could not understand why they have
trouble controlling the data registered at the 'sub.a.z' name.

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.

Implementations appear to be slightly inconsistent in whether
they expose or hide the sub.a.z. "delegation", a sample shows:

NSD 3.2.8	exposes
BIND 9.7.0-P2	hides
BIND 9.7.3-P1	hides
BIND 9.8.0-P4	exposes
ironDNS 1.0.1	exposes

I'm a little surprised that BIND apparently has regressed on
this...

"The actual names have been withheld to protect the guilty."

Regards,

- Håvard

---

From: Joao Damas <[email-masked]>
Date: Thu, 27 Oct 2011 12:12:16 +0200

> sub.a.z. NS	some.other.name.server.

are some.name.server and some.other.name.server really different servers? Different instances of name server software(not only different IP addresses)?

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 27 Oct 2011 12:23:36 +0200 (CEST)

> are some.name.server and some.other.name.server really
> different servers? Different instances of name server
> software(not only different IP addresses)?

That should not matter, IMO -- I consider it to be a Registry
Error irrespective.

However, let's say that they are completely separate, i.e. under
different administrative control -- that appears to be the actual
case in the example I'm looking at.

Regards,

- Håvard

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 Oct 2011 11:24:31 +0100

On 27 Oct 2011, at 11:12, Joao Damas wrote:

> are some.name.server and some.other.name.server really different  
> servers? Different instances of name server software(not only  
> different IP addresses)?

Why would the NS records' RDATA matter to the z zone Joao? The NS  
records have owner names living under two discrete but nested zone  
cuts. I don't understand how the z zone would (need to) care about  
hostnames in the server or name.server zone. Or if they even resolve.

---

From: Joao Damas <[email-masked]>
Date: Thu, 27 Oct 2011 12:27:12 +0200

On 27 Oct 2011, at 12:24, Jim Reid wrote:

> Why would the NS records' RDATA matter to the z zone Joao? The NS records have owner names living under two discrete but nested zone cuts. I don't understand how the z zone would (need to) care about hostnames in the server or name.server zone. Or if they even resolve.

because some implementation merge info if it is available, if they host the databases for both zones, which leads to different observed behaviours in responses.

Having said that, the registry for z. should not be delegating both a.z. and sub.a.z. (but it may happen in private DNS where z. is a small local "TLD" not part of the Internet's DNS).

Joao

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 Oct 2011 11:45:09 +0100

On 27 Oct 2011, at 11:27, Joao Damas wrote:

> because some implementation merge info if it is available, if they  
> host the databases for both zones, which leads to different observed  
> behaviours in responses.

Ah yes. I thought those sorts of quirks were limited to registry  
implementations and their database schemas. Perhaps DNS  
implementations show similar sort of behaviour whenever they use a  
database as their back-end.

---

From: Chris Thompson <[email-masked]>
Date: 27 Oct 2011 14:48:08 +0100

>I'm a little surprised that BIND apparently has regressed on

I tried this setup with BIND 9.8.1 and it seems to me that it
hides the inner "delegation" perfectly well, i.e. looking up
anything in sub.a.z gives a referral for a.z only.

Did 9.8.0-P4 really do something different? Or have I not
understood what you mean by "hides" vs. "exposes"?

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 Oct 2011 10:11:06 -0400

>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"

---

From: "John Levine" <[email-masked]>
Date: 27 Oct 2011 14:25:07 -0000

>sub.a.z. NS	some.other.name.server.

You're right, it's a mistake, but it is not my impression that
registries make many semantic checks on the DNS records that their
clients ask them to publish, since the range of errors is endless.

So the response to a.z is "don't do that."

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 Oct 2011 21:03:37 +0000

On Thursday, October 27, 2011 10:06:25 Havard Eidnes wrote:
> ...
> ...

i'm +1 with this interpretation. not just because implementations do not all 
do the same thing in the presence of this data pattern, but because in recent 
decades we've adopted a "mount point semantics" view of dns delegations. this 
should be written down somewhere, because the rfc 1034 rules about "scan down 
the tree looking for a delegation" logic does not mesh well with the "closest 
enclosure" logic that most implementations actually follow.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Oct 2011 08:46:30 +1100

> enclosure" logic that most implementations actually follow.

RFC 1034 does mount point to find the zone (step 2) and scan down
within the zone to find the delegation within the zone (step 3).
It's when you try to merge multiple zones into one database and
just scan down that you get problems (BIND 4 and BIND 8 did this
and mangled the zone content in the process).

RFC 1034, Section 4.3.2. Algorithm

   2. Search the available zones for the zone which is the nearest
      ancestor to QNAME.  If such a zone is found, go to step 3,
      otherwise step 4.

   3. Start matching down, label by label, in the zone.  The
      matching process can terminate several ways:

The DNS has always had the concept of occulted data.  Glue is
occulted data and is only returned in referrals.  You can't look
for glue directly and it is visible in axfr.

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