Classless reverse zones CNAME and PTR resolution issue
Mark Andrews
marka at isc.org
Mon Oct 31 10:48:38 UTC 2022
Cross zone CNAMEs cause accidental cache poisoning with some clients when both zones are on the same server. Named no longer follows the CNAME for non-recursive requests to prevent this. More security aware clients will restart the query after processing the CNAME.
--
Mark Andrews
> On 31 Oct 2022, at 09:34, Nagesh Thati <tcpnagesh at gmail.com> wrote:
>
>
> Hello,
> I am facing an issue with CNAME and PTR records resolution issues when classless reverse zones are defined in the BIND 9.16.* version (Without recursion), but it used to work in 9.11.* version (Without recursion). Below example shows what reverse zones are created and how the dig output is giving,
>
> named.conf:
> recursion no;
>
> zone "22.10.13.in-addr.arpa" IN {
> type master;
> file "/var/named/zones/masters/db.22.10.13.in-addr.arpa";
> check-names ignore;
> zone-statistics yes;
> };
> zone "0-25.22.10.13.in-addr.arpa" IN {
> type master;
> file "/var/named/zones/masters/db.0-25.22.10.13.in-addr.arpa";
> check-names ignore;
> zone-statistics yes;
> };
>
> db.22.10.13.in-addr.arpa:
> $TTL 1200
> $ORIGIN 22.10.13.in-addr.arpa.
> 22.10.13.in-addr.arpa. IN SOA remote1.india.com. admin.india.com. (
> 2022102807 ; serial
> 21600 ; refresh
> 3600 ; retry
> 604800 ; expire
> 86400 ; minimum
> )
> IN NS remote1.india.com.
> 0-25.22.10.13.in-addr.arpa. IN NS remote1.india.com.
> 2.22.10.13.in-addr.arpa. 1200 IN CNAME 2.0-25.22.10.13.in-addr.arpa.
>
> db.0-25.22.10.13.in-addr.arpa
> $TTL 1200
> $ORIGIN 0-25.22.10.13.in-addr.arpa.
> 0-25.22.10.13.in-addr.arpa. IN SOA remote1.india.com. admin.india.com. (
> 2022102808 ; serial
> 21600 ; refresh
> 3600 ; retry
> 604800 ; expire
> 86400 ; minimum
> )
> IN NS remote1.india.com.
> 2.0-25.22.10.13.in-addr.arpa. 1200 IN PTR 3G00051Phone.india.com.
>
> DIG Output:
> [root at remote1]# dig @localhost -x 13.10.22.2
>
> ; <<>> DiG 9.16.30 <<>> @localhost -x 13.10.22.2
> ; (2 servers found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32110
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: f29427e34cd79c0101000000635fe20b8accc09065ab6b33 (good)
> ;; QUESTION SECTION:
> ;2.22.10.13.in-addr.arpa. IN PTR
>
> ;; ANSWER SECTION:
> 2.22.10.13.in-addr.arpa. 1200 IN CNAME 2.0-25.22.10.13.in-addr.arpa.
>
> ;; Query time: 1 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Mon Oct 31 14:56:11 GMT 2022
> ;; MSG SIZE rcvd: 122
>
> I am getting the answer as only CNAME, not getting the exact A record for that IP address. This used to work in BIND 9.11.* version, recently I upgraded to 9.16.* latest version and from that I am facing this issue.
>
>
> But when I enable the recursion on BIND 9.16.* then I am getting the expected answer as below,
> [root at remote1]# dig @localhost -x 13.10.22.2
>
> ; <<>> DiG 9.16.30 <<>> @localhost -x 13.10.22.2
> ; (2 servers found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40386
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: 8cee7aad934beda401000000635fe32bf7ce38d08006dbd1 (good)
> ;; QUESTION SECTION:
> ;2.22.10.13.in-addr.arpa. IN PTR
>
> ;; ANSWER SECTION:
> 2.22.10.13.in-addr.arpa. 1200 IN CNAME 2.0-25.22.10.13.in-addr.arpa.
> 2.0-25.22.10.13.in-addr.arpa. 1200 IN PTR 3G00051Phone.india.com.
>
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Mon Oct 31 15:00:59 GMT 2022
> ;; MSG SIZE rcvd: 165
>
> Can someone help me why this behaviour is seen on BIND 9.16.* version.
> Thanks,
> Nagesh
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221031/7afba683/attachment-0001.htm>
More information about the bind-users
mailing list