This is public response for the name from my connection:

$ dig x.bd.bcebos.com.

; <<>> DiG 9.18.13 <<>> x.bd.bcebos.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11566
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;x.bd.bcebos.com.        IN    A

;; ANSWER SECTION:
x.bd.bcebos.com.    360    IN    CNAME    bd.bcebos.com.
bd.bcebos.com.        360    IN    CNAME bos.bd.baidubce.n.shifen.com.
bos.bd.baidubce.n.shifen.com. 60 IN    A    110.242.70.8

Now if you override just the zone "x.bd.bcebos.com.", it asks in the forwarder. But because the forwarder answers with name leading outside of its own zone, named will create separate query to bd.bcebos.com. Unless that has own forward zone definition for it, it uses global forwarders or iteration from root hints.

$ dig ns bd.bcebos.com.

; <<>> DiG 9.18.13 <<>> ns bd.bcebos.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54957
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
; COOKIE: cae27b6bb14ffd9815d2855f642c0f8300482e9548e4bf0a (good)
;; QUESTION SECTION:
;bd.bcebos.com.            IN    NS

;; ANSWER SECTION:
bd.bcebos.com.        57    IN    CNAME bos.bd.baidubce.n.shifen.com.

;; AUTHORITY SECTION:
n.shifen.com.        206    IN    SOA    ns1.n.shifen.com. baidu_dns_master.baidu.com. 2304040275 5 5 2592000 3600

This is some black magic, because SOA is not inside names we asked.

$ dig +norec @ns1.n.shifen.com. bd.bcebos.com.

; <<>> DiG 9.18.13 <<>> +norec @ns1.n.shifen.com. bd.bcebos.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 6168
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: ce297c8717115be001000000642c1022251028e6f44a59cc (good)
;; QUESTION SECTION:
;bd.bcebos.com.            IN    A

;; Query time: 201 msec
;; SERVER: 110.242.68.39#53(ns1.n.shifen.com.) (UDP)
;; WHEN: Tue Apr 04 13:55:14 CEST 2023
;; MSG SIZE  rcvd: 70

It does not allow me to even ask. So those chains are quite strange. In any case, bind will *NOT* blindly accept any names from forwarders for foreign zones. Its CNAME target leads outside its defined zone, it will always fetch it using separate zone fetches. So it will try asking bd.bcebos.com. and bos.bd.baidubce.n.shifen.com. nameservers and only their response is offered to end user. If there is a way to make bind trust those responses, I don't know about it. I think it is considered bad practice.

If the forwarder offers custom view, it should not override it using CNAMEs. It should just set it different addresses directly. This looks like not small private view to public records. I do not think it can work like you are trying to do. Either you will have zone not pointing to other zones, or you have to forward them all. BIND won't take into account in response to what name this response arrived. It won't let server of unrelated zones to insert cache records for other names. It does it to protect you from spoofing. dnsmasq will let you do that, because it does not have proper iteration capabilities. Use that if you need such split view. I doubt unbound, powerdns or any good recursive DNS will allow what you are trying to do. BIND9 included.

On 04. 04. 23 12:58, ltns wrote:
i am very very sorry ,
*the zone info of first mail -> **zone "bd.baidubce.com."*  i write wrong;
the wright is * zone "x.bd.bcebos.com."*
please just see this mail,

 when i use bind-9.11 for my interdns deviceip is 10.1.1.1, i config
 zone "x.bd.bcebos.com."
 in { type forward ; forward only; forwarders { 10.10.10.10; }; };

 1,when i dig @10.1.1.1 x.bd.bcebos.com.
 2,10.10.10.10 return record "CNAME bd.bcebos.com., bd.bcebos.com. A 100.67.96.26, A 100.67.96.27" to device10.1.1.1
dig @10.1.1.1 bd.bcebos.com. gives what response? That one you should receive.zone "x.bd.bcebos.com." role ended when cname target is not under x.bd.bcebos.com.
 3,but device10.1.1.1 not return A 100.67.96.26, A 100.67.96.27 to me
 4,device10.1.1.1 go to qurey bd.bcebos.com. recursive itself, and get another record 110.242.70.8

 i have questions
1,why config is forward only, bind get CNAME & A records from forwarders, but bind do not return A  record to me?and query cname domain recursive again itself?
 thanks







Message: 3
Date: Tue, 4 Apr 2023 12:05:04 +0200
From: Petr Men??k <pemen...@redhat.com>
To: bind-users@lists.isc.org
Subject: Re: BIND | Cname chain resolution using forward ( CNAME&A
returned but no use A) (#3995)
Message-ID: <e54b9e63-f17c-ac84-eb58-3ee4cfd88...@redhat.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

That is because forwarder is supposed to handle only zone
"bd.baidubce.com.", but addresses response is from bd.bcebos.com zone.
Therefore it queries contents of that according to global forwarders or
iteratively. BIND9 attempts to deliver the most authoritative answer it
can, so it ignores hints from server not authoritative for it. I do not
know a way to disable such behavior. Dns caches such as dnsmasq would
forward the reply as it is, but bind uses zones with authoritative
servers preferred. It does so to prevent unrelated servers pushing
invalid answers into your cache.

Workaround might be to forward also bd.bcebos.com. zone to the same
server. Can you share why should it return different addresses than the
authoritative servers offers?

I think if you need to override some addresses, RPZ might help you. At
least you would have a list of rules where the answer is modified. I
think most proper servers do it this way without ability to change the
behavior.

Just my 2 cents.

Regards,
Petr

On 04. 04. 23 8:08, Yang via bind-users wrote:
>
> hi?bind admin,
>
> ?when i use bind-9.11 for my interdns? deviceip is 10.1.1.1,
>
> i config
>
> zone "bd.baidubce.com."
>
> ?in?{ type forward ; forward only; forwarders { 10.10.10.10; }; };
>
>
> 1?when i dig @10.1.1.1 x.bd.bcebos.com.
>
> 2?10.10.10.10 return record "CNAME bd.bcebos.com., A 100.67.96.26, A
> 100.67.96.27" to device10.1.1.1
>
> 3?but device10.1.1.1 not return A 100.67.96.26, A 100.67.96.27 to me
>
> 4?device10.1.1.1 go to qurey bd.bcebos.com. recursive itself?and get
> another record 110.242.70.8
>
> i have questions
>
> 1?why config is forward only? but bind get CNAME & A?bind do not
> return A to me?and query cname again itself?
>
> ?thanks
>
>
--
Petr Men??k
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230404/42996e1b/attachment.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
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


------------------------------

End of bind-users Digest, Vol 4219, Issue 1
*******************************************

--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-- 
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

Reply via email to