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

[Grant Taylor <[e-mail]>]

On 12/27/18 12:59 PM, Paul Vixie wrote:
> in RFC 2317 we do this with CNAME not NS. did the proponent explain why 
> 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.

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

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.

> first i'd have to know what problem caused by CNAME in the outer zone 
> 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