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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
