Subject: [DNSOP] RFC2317 Question: Resolving cname delegation

From: Hector Santos <[email-masked]>
Date: Thu, 24 Aug 2017 11:46:58 -0400

I have a question related to RFC2317 "Classless IN-ADDR.ARPA delegation."

Earlier this year, I switched from a class C bank of 256 addresses to 
a reduced  set of 32 ips (/27).  To get PTR queries to work, RFC2317 
was referred by my ISP to prepare the delegation.

Having implemented RFC2317, I noticed with PTR lookups directly 
against my own DNS server, it returns the proper host names, no 
cnames.   When the query is done against other DNS servers, it returns 
the CNAME which points to the expected host name(s).  This I 
understand is the expected RFC2317 method setup by the ISP.

Not expecting this in my DNS resolver code, I modified the resolver to 
take the CNAMEs into account and return the host names instead.  Was 
this the correct thing to do, thus providing the same results 
regardless of the query location?

Reading RFC2317, section 5.1 and section 5.3, it sounds what I did was 
ok.'

I have various PTR lookup scripts that did not expect the CNAME in the 
PTR query as RFC2317 indicates may happen, thus possibly failing a PTR 
requirement, i.e. SMTP receiver connection, etc.

Before I release my updates, I wonder if this was the right thing to do.

Thanks

-- 
HLS

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 24 Aug 2017 18:06:24 +0200

Hello.

On 08/24/2017 05:46 PM, Hector Santos wrote:
> [...] Not expecting this in my DNS resolver code, I modified the
> resolver to take the CNAMEs into account and return the host names
> instead.  Was this the correct thing to do, thus providing the same
> results regardless of the query location? [...]

I can't see any hint in RFC2317 that resolvers should/could change the
data they obtain from upstream, even if just "expand CNAMEs" (and it's
only BCP RFC anyway).  In particular, if the particular zone is covered
by DNSSEC, you may trigger validation errors by that.

--Vladimir

---

From: P Vix <[email-masked]>
Date: Thu, 24 Aug 2017 17:07:18 +0000

This is why rfc 2308 definition of qname is correct.

On August 24, 2017 9:46:58 AM MDT, Hector Santos <[email-masked]> wrote:
>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Grant Taylor <[email-masked]>
Date: Thu, 24 Aug 2017 11:31:06 -0600

On 08/24/2017 09:46 AM, Hector Santos wrote:
> this the correct thing to do, thus providing the same results regardless 
> of the query location?

This is one of the gotchas for classless in-addr.arpa delegation.

> Before I release my updates, I wonder if this was the right thing to do.

I prefer to use a different method to do classless in-addr.arpa delegation.

Specifically, I ask ISPs to put an NS record for the IP(s) in question 
pointing to my own DNS server.  Then I configure zone(s) that match the 
full in-addr.arpa name with the PTR in the zone apex.

You can have a separate zone (d.c.b.a.in-addr.arpa.) for each IP 
(a.b.c.d) -or- you can have a single parent zone (c.b.a.in-addr.arpa.) 
with individual PTR records, much like the ISP normally does.

If you do the second method (parent c.b.a.in-addr.arpa. zone) I'd 
recommend that you have NS records for the other 224 IPs that point to 
your ISP's name server that is authoritative for the zone.

In effect, you are actually delegating the IPs an additional level.

I got bit by SORBS not understanding classless in-addr.arpa delegation 
(since been fixed) more than a decade ago and have never had any similar 
problems.

-- 
Grant. . . .
unix || die

---

From: Hector Santos <[email-masked]>
Date: Sat, 26 Aug 2017 14:23:06 -0400

On 8/24/2017 1:31 PM, Grant Taylor wrote:

> pointing to my own DNS server.  Then I configure zone(s) that match
> the full in-addr.arpa name with the PTR in the zone apex.
>

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.

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.

Thanks

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 26 Aug 2017 14:23:11 -0400

> by DNSSEC, you may trigger validation errors by that.

You're right. But I believe it does allude to potential problems and 
confusion.

As I study this more, the issue is this old RFC promoted unexpected 
cname for the qname in PTR results.  My ISP is using it for delegating 
our new /27 segment of ips.

The direct DNS server authoritive response is:

qname                  qtype   data
d.c.b.a.in-addr.arpa   PTR     host1
d.c.b.a.in-addr.arpa   PTR     host2
..
d.c.b.a.in-addr.arpa   PTR     hostN

The non-authoritive response is:

qname                  qtype   data
d.c.b.a.in-addr.arpa   CNAME   d.X.c.b.a.in-addr.arpa
d.X.c.b.a.in-addr.arpa PTR     host1
d.X.c.b.a.in-addr.arpa PTR     host2
..
d.X.c.b.a.in-addr.arpa PTR     hostN

Where X is the the first IP in the delegated IP range.

Although my resolver will only return the requested PTR records, the 
record.name field will contain the cname.  I am still studying the 
impact.   The exploratory change in the resolver was to basically 
compare the name field with the qname, and set it to the qname if 
different.   That way the clients will get the same expected results. 
  I don't think its any different when A->CNAME->A operations is done 
and cached.

It does not seem its going to be a impact on my SMTP clients/senders 
that could be setup to dynamically obtain the EHLO/HELO hostname by 
extracting the first record in a PTR lookup.   But it could be an 
impact on incoming SMTP filter scripts that could be setting a PTR 
requirement. Not sure.

It does seem safe, for our system compatibility, to make it 
consistent. In my opinion, the delegation CNAME is meta-data and it 
should be passive in the query results.

Thanks for the heads up.

-- 
HLS

---

From: Grant Taylor <[email-masked]>
Date: Sat, 26 Aug 2017 14:01:28 -0600

On 08/26/2017 12:23 PM, Hector Santos wrote:
> 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

---

From: Tony Finch <[email-masked]>
Date: Wed, 30 Aug 2017 20:53:01 +0100

Hector Santos <[email-masked]> wrote:
>
> Not expecting this in my DNS resolver code, I modified the resolver to take
> the CNAMEs into account and return the host names instead.  Was this the
> correct thing to do, thus providing the same results regardless of the query
> location?

Yes.

You should also make sure your response parser isn't tripped up by DNAME
records (you can safely skip them).

See also https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis which
sadly ran out of steam and stalled...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Southeast Iceland: Variable 3 or 4, becoming westerly 5 to 7. Moderate or
rough. Mainly fair, occasional drizzle later. Moderate or good.

---

From: Hector Santos <[email-masked]>
Date: Thu, 31 Aug 2017 08:56:24 -0400

> records (you can safely skip them).

Ok, I'm going to explore DNAME types (at least it to my resolver).

> sadly ran out of steam and stalled...

Interesting. Thanks for the note.

-- 
HLS