Subject: [dnsext] Short introduction to zone cuts?

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Mar 2012 10:47:33 -0700

Over on the dns-operations list, the issue of zone cuts has come up, and even normally-careful people have gotten it wrong. Is there a readable introduction to zone cuts and how they affect zone operators? If not, someone should really consider writing a two-page informational RFC on the subject and have it reviewed here (even if it is after this WG shuts down) before publication. I suspect that such an RFC will be more valuable to the Internet than many of the ones we have done here.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Sat, 17 Mar 2012 10:36:18 +1100

In message <[email-masked]>, Paul Hoffman writes
:
> Over on the dns-operations list, the issue of zone cuts has come up, and even
>  normally-careful people have gotten it wrong. Is there a readable introducti
> on to zone cuts and how they affect zone operators? If not, someone should re
> ally consider writing a two-page informational RFC on the subject and have it
>  reviewed here (even if it is after this WG shuts down) before publication. I
>  suspect that such an RFC will be more valuable to the Internet than many of 
> the ones we have done here.
> 
> --Paul Hoffman

RFC 1034 say all you need to say for zone operators about NS record.
Nameserver developer need to know more.

Section 4.2.2. "Administrative considerations" covers just about
all that one needs to know in particular "As the last installation
step, the delegation NS RRs and glue RRs necessary to make the
delegation effective should be added to the parent zone.  The
administrators of both zones should insure that the NS and glue RRs
which mark both sides of the cut are consistent and remain so."
This apply to both registries and registrars as the are the
administators of the relevent zones.

Failure to follow that advice causes most of the operational problems
we see in the DNS.

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

---

From: Ray Bellis <[email-masked]>
Date: Sat, 17 Mar 2012 13:31:40 +0000

> RFC 1034 say all you need to say for zone operators about NS record.

IMHO, there's more to it than that.

For example, if you have this in a parent zone:

1.1.1.1.5.5.5.3.0.2.1.e164.arpa. IN NS ns1.example.com

and this in the child zone:

$ORIGIN 5.5.5.3.0.2.1.e164.arpa.
@          SOA ...
@          NS ns1.example.com
0.0.0.0    NAPTR ...
1.0.0.0    NAPTR ...

it currently works - the parent zone points to the right server, but the parent and child disagree on where the zone cut is.

However with DNSSEC that is no longer possible.  There's nowhere to put the DS record.

For various historic reasons, the UK public ENUM tree has per-number NS records as shown above.  To make the parent and child consistent (without changing the parent) the child server would need to have a separate zone file _per number_.

Ray

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 17 Mar 2012 07:41:08 -0700

> RFC 1034 say all you need to say for zone operators about NS record.

As we have seen, the text in RFC 1034 has not been sufficient to prevent errors. A clearly-written document might help prevent errors. Some of us would prefer to prevent errors rather than just criticize the people who cannot read the source documents as well as you can.

> Nameserver developer need to know more.

And, as such, would be valuable to document in an informational RFC, given that we see errors in that all the time. The two sets of information are quite related.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Sun, 18 Mar 2012 10:37:14 +1100

In message <[email-masked]>, Paul Hoffman writes
:
> As we have seen, the text in RFC 1034 has not been sufficient to prevent erro
> rs. A clearly-written document might help prevent errors. Some of us would pr
> efer to prevent errors rather than just criticize the people who cannot read 
> the source documents as well as you can.

Please go survey those that have made errors and ask them if there
are supposed to be matching NS records in the parent and child
zones.  I know that ISC's error a couple of weeks back were not due
to lack of knowledge.

There are lots of documents on the net on how to delegate a zone.
Of those I've checked they all say to add matching NS records to
the parent zone.  One more won't help.  People either don't read,
make a mistake, or deliberately choose to do the wrong thing.

> And, as such, would be valuable to document in an informational RFC, given th
> at we see errors in that all the time. The two sets of information are quite 
> related.

We already have documents that tell implementors what to do.  
 
> --Paul Hoffman
> 
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Doug Barton <[email-masked]>
Date: Sat, 17 Mar 2012 18:36:41 -0700

> it currently works - the parent zone points to the right server, but the parent and child disagree on where the zone cut is.

I'm not sure what you mean by "works" here. If you mean that anyone
using ns1.example.com directly will see those records, then yes, it
works -- for those users. But assuming that ns1.example.com is not
included in the NS set of the parent zone, no one else will see the 2
NAPTR records you listed above. So in that sense it doesn't work ... at
least, it doesn't work the way that the administrator of ns1.example.com
wants it to.

Doug

-- 
    If you're never wrong, you're not trying hard enough

---

From: Ray Bellis <[email-masked]>
Date: Mon, 19 Mar 2012 14:58:19 +0000

On 18 Mar 2012, at 01:36, Doug Barton wrote:

> I'm not sure what you mean by "works" here.

I mean the NAPTR records correctly resolve.

> If you mean that anyone

No, in this case "ns1.example.com" _is_ found via the parent zone, but the delegation is four nodes further down the DNS tree than the child's SOA / NS records would indicate.

Ray

---

From: Doug Barton <[email-masked]>
Date: Mon, 19 Mar 2012 15:48:07 -0700

On 3/19/2012 7:58 AM, Ray Bellis wrote:
>> If you mean that anyone using ns1.example.com directly will see
>> those records, then yes, it works -- for those users. But assuming
>> that ns1.example.com is not included in the NS set of the parent
>> zone, no one else will see the 2 NAPTR records you listed above. So
>> in that sense it doesn't work ... at least, it doesn't work the way
>> that the administrator of ns1.example.com wants it to.
> 
> No, in this case "ns1.example.com" _is_ found via the parent zone,
> but the delegation is four nodes further down the DNS tree than the
> child's SOA / NS records would indicate.

Right, and that's the devious subtlety of your message. :)  No one would
ever query ns1.example.com iteratively for the sample records in the
zone you posted because they would have no way of knowing that
ns1.example.com thought it was authoritative for those records.

Clients querying it directly would get an answer (think in-house
resolvers with various in-house zones slaved to it) but no one else would.

Doug

---

From: Mark Andrews <[email-masked]>
Date: Tue, 20 Mar 2012 10:13:00 +1100

In message <[email-masked]>, Ray Bellis wr
ites:
> it currently works - the parent zone points to the right server, but the pa=
> rent and child disagree on where the zone cut is.
> 
> However with DNSSEC that is no longer possible.  There's nowhere to put the=
>  DS record.
> 
> For various historic reasons, the UK public ENUM tree has per-number NS rec=
> ords as shown above.  To make the parent and child consistent (without chan=
> ging the parent) the child server would need to have a separate zone file _=
> per number_.

No.  It needs the data to be available.  With traditional servers
this has required a zone file.  But even with named this could come
from a single database that defines the zones and their content using
DLZ.

dbjdns does this with a single flat file.

Mark

---

From: Ray Bellis <[email-masked]>
Date: Tue, 20 Mar 2012 09:31:29 +0000

> ns1.example.com thought it was authoritative for those records.

Sure they would!

You can try it:

% dig +short @8.8.8.8 1.1.2.2.3.3.5.6.8.1.4.4.e164.arpa. NAPTR
100 20 "u" "E2U+pstn:tel" "!^(.*)$!tel:\\1!" .
100 10 "u" "E2U+sip" "!^\\+441865332(.*)$!sip:\\[email-masked]!" .

> resolvers with various in-house zones slaved to it) but no one else would.

Yes, they would.

The recursive server without an entry in cache ends up at the NS for 4.4.e164.arpa, at which point we send a referral _for the whole domain name_ pointing at ns1.example.com.

The query arrives there, and is duly answered.  Sans DNSSEC, the mismatch in the zone cut between parent and child is never noticed.

Ray

---

From: Tony Finch <[email-masked]>
Date: Tue, 20 Mar 2012 11:45:02 +0000

> 100 10 "u" "E2U+sip" "!^\\+441865332(.*)$!sip:\\[email-masked]!" .

However BIND gets upset by negative responses (noerror/nodata) because the
authority section of replies is wrong.

$ dig a 1.1.2.2.3.3.5.6.8.1.4.4.e164.arpa.
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42870
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

$ dig a 1.1.2.2.3.3.5.6.8.1.4.4.e164.arpa. @nom-ns1.nominet.org.uk.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7348
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

20-Mar-2012 11:33:57.577 resolver: notice:
	DNS format error from 2a01:40:1001:37::2#53
	resolving 1.1.2.2.3.3.5.6.8.1.4.4.e164.arpa/A
	for client 127.0.0.1#53299: invalid response
20-Mar-2012 11:33:57.577 lame-servers: info:
	error (FORMERR) resolving
	'1.1.2.2.3.3.5.6.8.1.4.4.e164.arpa/A/IN':
	2a01:40:1001:37::2#53

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
East Sole, Lundy, Fastnet, Irish Sea: Southwesterly 4 or 5, occasionally 6 in
Irish Sea. Slight or moderate, occasionally rough in Fastnet. Mainly fair.
Good.

---

From: Doug Barton <[email-masked]>
Date: Tue, 20 Mar 2012 22:48:46 -0700

>> ns1.example.com thought it was authoritative for those records.

In your original post you posited something like this, if I understood
you correctly:

Parent:

$ORIGIN 4.3.2.1.foo.
8.7.6.5		NS	ns1.example.com.

ns1.example.com (child):

$ORIGIN 4.3.2.1.foo.
0.0.0.0		A	blah.example.com.
1.1.1.1		A	baz.example.com.

Under that scenario clients in the cloud would never query
ns1.example.com for 0.0.0.0.4.3.2.1.foo or 1.1.1.1.4.3.2.1.foo because
they'd have no delegation to it.

If I misunderstood, sorry for the noise.

Doug