Subject: [DNSOP] Delegation into the interior of a zone?

From: "John Levine" <[email-masked]>
Date: 27 Dec 2018 14:26:38 -0500

Over in bind-users somone suggested a CIDR rDNS kludge in which you
delegate a bunch of names out of a rDNS zone to a second server,
and the second server answers them all from one zone, like this

$ORIGIN 1.1.1.in-addr.arpa.
@ SOA blah

10 NS otherserver
11 NS otherserver
12 NS otherserver

and on the other server

$ORIGIN 1.1.1.in-addr.arpa.
@ SOA blah

10 PTR foo
11 PTR bar
12 PTR baz

That is, the two zones have the same apex, and NS records point into
the interior of the second zone, not at the apex.  That works in BIND,
of course, but it seems wrong.  I am having trouble tracking down the
specification of why it is wrong.

Any sugestions?  It would fail with DNSSEC since there's no DNSKEY
to match the delegation DS, but how wrong was it before that?

Signed,
Confused

---

From: Erik Kline <[email-masked]>
Date: Thu, 27 Dec 2018 11:32:53 -0800

> to match the delegation DS, but how wrong was it before that?

So, the NS listed in some zone above would be "wrong", i.e. the glue
records point to namservers hosting a zone with these different
nameservers?  Seems like a resolver being pedantic about glue records might
be nonplussed.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 Dec 2018 11:59:46 -0800

> $ORIGIN 1.1.1.in-addr.arpa.

in RFC 2317 we do this with CNAME not NS. did the proponent explain why 
CNAME wasn't suitable for her purposes?

> specification of why it is wrong.

if the old domain-obscenity-checker (DoC) which came out with the 
domain-information-groper (DiG) back in the 1980's says it's wrong, then 
it's wrong. if the specifications don't cover this case, they are 
incomplete. or at least, that's how i do things.

> to match the delegation DS, but how wrong was it before that?

first i'd have to know what problem caused by CNAME in the outer zone 
they think they are solving using NS.

-- 
P Vixie

---

From: "John R Levine" <[email-masked]>
Date: 27 Dec 2018 15:29:08 -0500

> in RFC 2317 we do this with CNAME not NS. did the proponent explain why CNAME 
> wasn't suitable for her purposes?

He thinks $GENERATE confuses people.

Don't shoot, I'm just the messenger.

R's,
John

---

From: Grant Taylor <[email-masked]>
Date: Thu, 27 Dec 2018 17:27:00 -0700

> He thinks $GENERATE confuses people.

No, $GENERATE is not why he, *I*, prefer to use NS over CNAME delegation.

I listed out multiple (2 ~ 3) manually as an example instead of using 
$GENERATE purely to simplify the example.  I've run across many people 
that don't know what $GENERATE is, particularly if their experience 
comes from somewhere other than BIND.

So, I simply list out the discrete lines that $GENERATE would produce. 
I think it removes a variable from an equation and simplifies things.

The use of $GENERATE or not is independent of CNAME vs NS delegation.

Besides, $GENERATE happily works with CNAME as well as it does NS records.

$GENERATE 1-4 $ CNAME $.bob.example.net.
$GENERATE 5-8 $ NS ns1.example.com.

Both work perfectly fine.  named-compilezone produces the expected lines.

1.localhost.  604800  IN  CNAME  1.bob.example.net.
2.localhost.  604800  IN  CNAME  2.bob.example.net.
3.localhost.  604800  IN  CNAME  3.bob.example.net.
4.localhost.  604800  IN  CNAME  4.bob.example.net.
5.localhost.  604800  IN  NS     ns1.example.com.
6.localhost.  604800  IN  NS     ns1.example.com.
7.localhost.  604800  IN  NS     ns1.example.com.
8.localhost.  604800  IN  NS     ns1.example.com.

Which of the two methods above is easier (or poses fewer questions) to 
understand by someone who's not familiar with BIND, much less $GENERATE?

> Don't shoot, I'm just the messenger.

I can shoot the messenger with a Nerf gun for reporting the wrong 
message.  Or are we playing a game of telephone?

-- 
Grant. . . .
unix || die

---

From: Grant Taylor <[email-masked]>
Date: Thu, 27 Dec 2018 18:05:11 -0700

> CNAME wasn't suitable for her purposes?

Vaguely.

I personally find CNAMEs to sub-domains to be sub optimal for various 
reasons.

I have coached MANY (too many?) people through RFC 2317 over the last 18 
years.  Almost all of them have run into the following issues:

1)  RFC 2317 is in some ways too vague.  I say this because the people 
wanting to do classless in-addr.arpa delegation tend to be new, to at 
least 2317, if not DNS in general and don't understand how it works.  As 
such, RFC 2317 not specifying some details (probably done on purpose to 
be flexible) tended to make things more difficult for them.

2)  RFC 2317 uses the (forward) slash character "/" in some of the 
examples as part of sub-domain that qnames are being aliased to.  (From 
memory) elsewhere the RFC states that some DNS servers and / or clients 
might have problems with the (forward) slash character "/" and indicate 
that a different character may need to be used.

3)  RFC 2317 does not clearly stipulate that sub-domain that qnames are 
being aliased to can be any sub-domain / zone that you want.  This 
leaves people questioning if they have to do some sort of in-addr.arpa 
like reverse DNS zone or if they can make it a sub-domain of (one of) 
their main domain(s).  2317 makes some suggestions about using the 
network, separation character, CIDR prefix length.  But (from memory) 
this wasn't clearly articulated.  I also believe there were examples of 
other methods, thus adding to the confusion.

4)  Some DNS servers (MS-DNS) have problems with an 
0/16.2.0.192.in-addr.arpa.  Or at least their wizards make it seems as 
if it can't be done and leave it up to the reader to figure out how to 
do it manually.

5)  I've run into many ISPs that refuse to do 2317 but will do NS 
delegation.

6)  I've had to coach ISPs (frequently by proxy) on 2317 to try to get 
them to understand enough to decide if they will do it.  (Frequently 
they say no after they learn enough, citing "complexity".)

7)  I've had much less push back asking for IPs to simply be delegated 
using standard NS records to other DNS servers.

Aside:  I believe John was primarily question my recommendation to have 
different versions of the same zone cross delegating to each other.  But 
it's important to know that when I originally started using NS 
delegation instead of CNAME delegation I was using separate zones for 
each and every delegated IP address.  This quickly got unwieldy.  So I 
tried with the single zone, found no problems, and have never seriously 
looked back.  -  I'm always curious about pros and cons of it.  Hence my 
follow up to John's thread on the bind-users list.

I have also run afoul of RBLs that did not know what RFC 2317 Classless 
IN-ADDR.ARPA Delegation was.  Thus their scanners came across my CNAME 
per 2317 and coughed up a fur ball and black listed servers.

While working with the RBL operator (I found them to be quite 
approachable and responsive when being polite) I learned that their 
scanners would not have had any problem with the NS delegation.  -  I 
believe their specific problem was that they were expecting a PTR record 
and did not process the CNAME record at all, much less correctly.  They 
stipulated that they were already processing NS records for delegation 
and would have happily done do and found the requisite PTR.

So, I switched to the NS delegation (using discrete zones at the time) 
and moved on.  I heard from the RBL operator about six months later, 
letting me know that they had retooled a significant portion of their 
infrastructure to support 2317 and thanking me again for bringing it to 
their attention.

I personally feel like aliasing to a sub-domain is atypical of standard 
DNS delegation.  At least in the in-addr.arpa space.  Conversely, using 
an additional NS record for one more delegation is re-using the exact 
same methods that were used to get to the qname in question.

I felt like NS delegations were cleaner and simpler than CNAME delegations.

Of the people that I've helped over the years, telling them to ask their 
upstream ISP to put in an NS record (something they are more likely used 
to) and adding a 6 label zone (with the PTR in the apex) to their server 
worked out MUCH easier.  The conversations were ALWAYS shorter, less 
complex, and clearer.

> it's wrong.

Now I want to test NS delegation (both multiple zones and single zone) 
with DoC and DiG to see what they say.

> if the specifications don't cover this case, they are incomplete.

I won't say how likely (or not) that is, just that it is a statistical 
possibility.

> or at least, that's how i do things.

Fair enough.

With all do respect Paul, how you do or don't do things does not 
directly translate to if it's correct or not.  Though seeing as it's 
/you/, Paul Vixie, chances are quite good that what you do is in fact 
correct.  At least far more so than what I do.

> they think they are solving using NS.

I think I outlined that above.  If not, or if you still have questions, 
please reply and I'll elaborate.

In short, 2317 failed me, flat out.  (That might not be 2317's fault 
directly.  But it failed when NS delegation would not have failed the 
same test.)  I find 2317 to be a possible tool.  I also find NS 
delegation to be another tool for the same task.  I personally think NS 
delegation is simpler.  The people that I've talked to over the years 
seem to agree that NS delegation is simpler.  So, factor in Occam's 
Razor / Parsimony between the two tools and I'm going to choose NS 
delegation over CNAME delegation.  At least absent a reason that I can't 
use NS delegation.

-- 
Grant. . . .
unix || die

---

From: "John Levine" <[email-masked]>
Date: 28 Dec 2018 17:27:31 -0500

>understand by someone who's not familiar with BIND, much less $GENERATE?

I'd think it depends whether invalid delegations bother them, like if,
say, ns1.example.com might not be running BIND.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Fri, 28 Dec 2018 14:50:32 -0800

I once write a full resolve that checked both sides of every delegation point and remembered both sets of ns records. It would not have followed an ns to a non-soa. That would not be wrong.

On Dec 28, 2018, 14:27, at 14:27, John Levine <[email-masked]> wrote:
>In article
><[email-masked]> you
>write:
>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

---

From: Grant Taylor <[email-masked]>
Date: Fri, 28 Dec 2018 16:02:03 -0700

> say, ns1.example.com might not be running BIND.

You seem to be conflating the two independent issues at hand:

1)  Use of RFC 2317's CNAME technique vs the NS technique I'm advocating 
(be it to the interior or apex of the zone).

2)  Use of $GENERATE vs manually creating individual records.

#1 is what records to use.  #2 is how to create said records.  Between 
them there are four possible combinations.

  · Use CNAMEs with manual record creation.
  · Use CNAMEs with $GENERATE.
  · Use NS records with manual record creation.
  · Use NS records with $GENERATE.

-- 
Grant. . . .
unix || die

---

From: "John Levine" <[email-masked]>
Date: 28 Dec 2018 19:27:15 -0500

In article <[email-masked]> you write:
>-=-=-=-=-=-

Not really.

>(be it to the interior or apex of the zone).

Right.  CNAME is valid, NS to the interior of the zone is not.

>2)  Use of $GENERATE vs manually creating individual records.

I agree this doesn't matter.  If you say users can't deal with
$GENERATE, you have my sympathy, but that has nothing to do with whether
your records are valid.

R's,
John