Re: [DNSOP] RFC2317 Question: Resolving cname delegation

[Grant Taylor <[e-mail]>]

On 08/26/2017 12:23 PM, Hector Santos wrote:
> This was done, at least the first part of providing the ISP the two NS
> servers required.  They used RFC2317 to setup the cname delegation. On
> my servers, I had done what you suggestion with the second method using
> a parent c.b.a.in-addr.arpa zone.   It all seems to work, except for the
> unexpected cname+ptr records with non-authoritive results.

If CNAME is still involved, you didn't do what I'm recommending.

Suppose that this is the ISP's reverse DNS zone:


$ORIGIN .
$TTL 3600
2.0.192.in-addr.arpa	IN	SOA	ispdnsserver.example.com.
hostmaster.example.com. (
					1234567890	; serial
					3600		; refresh
					1800		; retry
					604800		; expire
					)
			IN	NS	ispdnsserver.example.com.
$GENERATE 1-122 $ PTR somehost.example.com.
123			IN	NS	mydnsserver.example.net.
$GENERATE 124-255 $ PTR somehost.example.com.


This would be your reverse DNS zone:


$ORIGIN .
$TTL 3600
2.0.192.in-addr.arpa	IN	SOA	mydnsserver.example.net.
hostmaster.example.com. (
					1234567890	; serial
					3600		; refresh
					1800		; retry
					604800		; expire
					)
			IN	NS	mydnsserver.example.net.
$GENERATE 1-122 $ NS ispdnsserver.example.com.
123			IN	PTR	myserver.example.net
$GENERATE 124-255 $ NS ispdnsserver.example.com.


Notice how the ISP is using an NS record instead of a PTR or a CNAME record.

The ISP is quite literally delegating DNS responsibility to you, the
exact same way that the upstream parent, 0.192.in-addr.arpa., delegated
2.0.192.in-addr.arpa. to the ISP.

That is the catch.  You are re-using THE EXACT SAME METHOD that is
already used, NS delegation.

Do NOT use CNAMEs in the parent zone.

> Still studying the impact.  I was trying to prevent some consistency in
> the results in the resolver.  In the same way, that its done for
> A->CNAME->A results.

CNAMEs in reverse DNS have been problematic for me.  (See previous email.)

> Thanks

You're welcome.



-- 
Grant. . . .
unix || die