Date: Thu, 24 Aug 2017 17:07:18 +0000
User-Agent: K-9 Mail for Android
In-Reply-To: <599EF4F2.6070509@isdg.net>
References: <599EF4F2.6070509@isdg.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----F5MZ9ICR9XWF3QWMTKTQRMIEDF9BLW"
Content-Transfer-Encoding: 7bit
To: dnsop@ietf.org, Hector Santos <hsantos@isdg.net>,
 "dnsop@ietf.org" <dnsop@ietf.org>
From: P Vix <paul@redbarn.org>
Message-ID: <151DA7A7-47A7-4353-8A0A-A3EAB9B3EA46@redbarn.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MW1u2MPk4NL7yDJO_TONb7IvMQ4>
Subject: Re: [DNSOP] RFC2317 Question:  Resolving cname delegation
Precedence: list

------F5MZ9ICR9XWF3QWMTKTQRMIEDF9BLW
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

This is why rfc 2308 definition of qname is correct=2E

On August 24, 2017 9:46:58 AM MDT, Hector Santos <hsantos@isdg=2Enet> wrot=
e:
>I have a question related to RFC2317 "Classless IN-ADDR=2EARPA
>delegation=2E"
>
>Earlier this year, I switched from a class C bank of 256 addresses to=20
>a reduced  set of 32 ips (/27)=2E  To get PTR queries to work, RFC2317=20
>was referred by my ISP to prepare the delegation=2E
>
>Having implemented RFC2317, I noticed with PTR lookups directly=20
>against my own DNS server, it returns the proper host names, no=20
>cnames=2E   When the query is done against other DNS servers, it returns=
=20
>the CNAME which points to the expected host name(s)=2E  This I=20
>understand is the expected RFC2317 method setup by the ISP=2E
>
>Not expecting this in my DNS resolver code, I modified the resolver to=20
>take the CNAMEs into account and return the host names instead=2E  Was=20
>this the correct thing to do, thus providing the same results=20
>regardless of the query location?
>
>Reading RFC2317, section 5=2E1 and section 5=2E3, it sounds what I did wa=
s=20
>ok=2E'
>
>I have various PTR lookup scripts that did not expect the CNAME in the=20
>PTR query as RFC2317 indicates may happen, thus possibly failing a PTR=20
>requirement, i=2Ee=2E SMTP receiver connection, etc=2E
>
>Before I release my updates, I wonder if this was the right thing to
>do=2E
>
>Thanks
>
>--=20
>HLS
>
>
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf=2Eorg
>https://www=2Eietf=2Eorg/mailman/listinfo/dnsop

--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E
------F5MZ9ICR9XWF3QWMTKTQRMIEDF9BLW
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body>This is why rfc 2308 definition of qname is correc=
t=2E<br><br><div class=3D"gmail_quote">On August 24, 2017 9:46:58 AM MDT, H=
ector Santos &lt;hsantos@isdg=2Enet&gt; wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px solid rgb(204, =
204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">I have a question related to RFC2317 &quot;Classless=
 IN-ADDR=2EARPA delegation=2E&quot;<br /><br />Earlier this year, I switche=
d from a class C bank of 256 addresses to <br />a reduced  set of 32 ips (/=
27)=2E  To get PTR queries to work, RFC2317 <br />was referred by my ISP to=
 prepare the delegation=2E<br /><br />Having implemented RFC2317, I noticed=
 with PTR lookups directly <br />against my own DNS server, it returns the =
proper host names, no <br />cnames=2E   When the query is done against othe=
r DNS servers, it returns <br />the CNAME which points to the expected host=
 name(s)=2E  This I <br />understand is the expected RFC2317 method setup b=
y the ISP=2E<br /><br />Not expecting this in my DNS resolver code, I modif=
ied the resolver to <br />take the CNAMEs into account and return the host =
names instead=2E  Was <br />this the correct thing to do, thus providing th=
e same results <br />regardless of the query location?<br /><br />Reading R=
FC2317, section 5=2E1 and section 5=2E3, it sounds what I did was <br />ok=
=2E'<br /><br />I have various PTR lookup scripts that did not expect the C=
NAME in the <br />PTR query as RFC2317 indicates may happen, thus possibly =
failing a PTR <br />requirement, i=2Ee=2E SMTP receiver connection, etc=2E<=
br /><br />Before I release my updates, I wonder if this was the right thin=
g to do=2E<br /><br />Thanks<br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E</=
body></html>
------F5MZ9ICR9XWF3QWMTKTQRMIEDF9BLW--