> On 4 Oct 2024, at 10:43, 大浦 義 <oou...@sandi.co.jp> wrote:
>
> Are searches from one authoritative zone to another authoritative zone using
> cname no longer allowed?
It is pointless to follow CNAMEs when returning non recursive (RA=0) responses
as recursive servers throw the rest of the response away to prevent cache
poisoning and for recursive servers that are vulnerable to cache poisoning using
that method not following the CNAME prevents accidental cache poisoning.
The recursive server will follow the CNAME and query for the target and return a
complete response at the cost of a couple of extra queries.
Recursive responses (RD=1, RA=1) will follow the CNAME.
> /etc/named.conf
> acl "local" {
> xxx.xxx.xxx.xxx; 127.0.0.1;
> };
> ・
> ・
> ・
> allow-recursion { local; };
>
> --
> Client xxx.xxx.xxx.xxx→9.9.4:OK 9.9.18:OK
> Client yyy.yyy.yyy.yyy(not include acl) →9.9.4:OK 9.9.18:NG
>
>
> -----Original Message-----
> From: 大浦 義
> Sent: Friday, October 4, 2024 9:35 AM
> To: Matus UHLAR - fantomas <uh...@fantomas.sk>; bind-users@lists.isc.org
> Subject: RE: Referencing by cname from one authoritative zone to another
> authoritative zone
>
> Dear.
>
> ・9.9.4
> Master
> ns0.bbb.co.jp
> Slave
> ns1.bbb.co.jp
> ns2.bbb.co.jp
>
> ・9.18.28
> Master
> ns0-2024.bbb.co.jp
> Slave
> ns1-2024.bbb.co.jp
> ns2-2024.bbb.co.jp
>
> # dig @ns1-2024.bbb.co.jp ns2.bbb.co.jp.
>
> ; <<>> DiG 9.18.28 <<>> @ns1-2024.bbb.co.jp ns2.bbb.co.jp.
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12653 ;; 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: 4096
> ; COOKIE: 86a5aef292eec6700100000066ff3765baf0fbd3340da90b (good) ;; QUESTION
> SECTION:
> ;ns2.bbb.co.jp. IN A
>
> ;; ANSWER SECTION:
> ns2.bbb.co.jp. 900 IN A 1.2.3.5
>
> ;; Query time: 6 msec
> ;; SERVER: 1.2.3.14#53(ns1-2024.bbb.co.jp) (UDP) ;; WHEN: Fri Oct 04 09:31:33
> JST 2024 ;; MSG SIZE rcvd: 89
>
>
>
> -----Original Message-----
> From: bind-users <bind-users-boun...@lists.isc.org> On Behalf Of Matus UHLAR
> - fantomas
> Sent: Thursday, October 3, 2024 6:50 PM
> To: bind-users@lists.isc.org
> Subject: Re: Referencing by cname from one authoritative zone to another
> authoritative zone
>
> On 03.10.24 09:21, 大浦 義 wrote:
>> ・9.9.4→OK
>> # dig @ns1.bbb.co.jp time1.aaa.ne.jp
>
>> ;; ANSWER SECTION:
>> time1.aaa.ne.jp. 3600 IN CNAME ns2.bbb.co.jp.
>> ns2.bbb.co.jp. 900 IN A 1.2.3.5
>>
>> ;; AUTHORITY SECTION:
>> bbb.co.jp. 900 IN NS ns6-tk02.ccc.ad.jp.
>> bbb.co.jp. 900 IN NS ns2.bbb.co.jp.
>> bbb.co.jp. 900 IN NS ns1.bbb.co.jp.
>>
>> ;; ADDITIONAL SECTION:
>> ns1.bbb.co.jp. 900 IN A 1.2.3.4
>
>> ・9.18.28→NG
>> # dig @ns1-2024.bbb.co.jp time1.aaa.ne.jp
>
>> ;; ANSWER SECTION:
>> time1.aaa.ne.jp. 3600 IN CNAME ns2.bbb.co.jp.
>
>
> Now do:
> dig @ns1-2024.bbb.co.jp ns2.bbb.co.jp.
>
> what records does ns2.bbb.co.jp. have on ns1-2024.bbb.co.jp ?
>
>
>> On 03.10.24 08:40, 大浦 義 wrote:
>>> Referencing by cname from one authoritative zone to another authoritative
>>> zone may not work properly depending on the version.
>>> Is this due to a specification change? Is there a way to handle this?
>>> I am running nslookup from a client that is not included in acl
>>> respectively.
>>> I would like to make the NG part become OK.
>>>
>>> --
>>> One Server Has Two Zone.
>>> aaa.ne.jp & bbb.co.jp
>>>
>>> ・aaa.ne.jp
>>> time1 CNAME ns2.bbb.co.jp.
>>> time2 CNAME ns1.bbb.co.jp.
>>>
>>> ・bbb.co.jp
>>> ns1 A 1.2.3.4
>>> ns2 A 1.2.3.5
>>> time CNAME ns2
>>>
>>> ・Bind9.9.4→OK
>>>> nslookup time2.aaa.ne.jp
>>> 名前: ns1.bbb.co.jp
>>> Address: 1.2.3.4
>>> Aliases: time2.aaa.ne.jp
>>>
>>> ・Bind9.18.28→NG
>>>> nslookup time2.aaa.ne.jp
>>> 名前: ns1.bbb.co.jp
>>
>> nslookup is NOT a good tool to resolve DNS problems. Use "dig" instead.
>>
>>
>> dig time2.aaa.ne.jp @"IP of Bind9.9.4"
>>
>>
>> dig time2.aaa.ne.jp @"IP of Bind9.18.28"
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> How does cat play with mouse? cat /dev/mouse
> --
> 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> --
> 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
