Re: 回复： BIND | Cname chain resolution using forward ( CNAME&A returned but no use A) (#3995)
Petr Menšík
pemensik at redhat.com
Tue Apr 4 16:22:19 UTC 2023
No. forward only; means only it won't try to iterate from root in case
forwarder does not respond or responds with Server Failure. It would try
to get answer its own way iterating from root hints if forward first;
were used. Or forward clause were not present. It will not make bind to
blindly trust to forwarder just like dnsmasq does.
I think usually cloud provides have common zone, in which all their
hosts are. Something like akamaiedge.net. I think your cloud service
provider should be able to recommend a working way. I just guess you
would need to direct a list of their domains, which they use to host
their services. In your case I would say n.shifen.com. would be such
candidate. Just do not include x in the zone name:
# this should work for this example
zone "bd.bcebos.com."
in { type forward ; forward only; forwarders { 10.10.10.10; }; };
zone "shifen.com."
in { type forward ; forward only; forwarders { 10.10.10.10; }; };
Whatever target names your provider uses for CNAME targets would need
similar zone definiton. If they are not able to provide similar list, I
would look for more prepared company.
On 04. 04. 23 17:39, ltns wrote:
> thanks for reply;
> bd.bcebos.com. is provide by our Cloud service provider, it both have
> Internal IP results and extra IP results;
> when not forward to 10.10.10.10,just recursive from Public network，it
> will get extra ip result just like you have try;
> when in our inter network environment,we need forward it to
> 10.10.10.10, it's our Cloud service provider interdns, it will reply
> CNAME bd.bcebos.com., bd.bcebos.com. A 100.67.96.26, A 100.67.96.27
> records to me, and I need access the interIp service through our inter
> network;
>
> I also try dnsmasq and unbound before，just like you have say，dnsmasq
> get "CNAME bd.bcebos.com., bd.bcebos.com. A 100.67.96.26, A
> 100.67.96.27" records,it will use A record
dnsmasq does not have ability to iterate. It blindly trust recursive
servers it uses. Such behaviour is unwanted from more serious
implementation.
>
> unbound 's action is the same as bind named, when it get "CNAME
> bd.bcebos.com., bd.bcebos.com. A 100.67.96.26, A 100.67.96.27", it do
> not use A record, just try to query bd.bcebos.com again
Sure, unbound is decent resolver and would not trust foreign zones in
answers without fetching it himself. All more complex implementations
should behave the same.
>
> what Trouble me is the definition of "forward only",i read some
> Related documents，i think when use forward only, bind will just get
> results from forwarders, no matter what bind get CNAME and A record,
> or just A record , i think it will use A;
> from now on，bind have different behaviour; when config "forward
> only", it also will query cname again ;It's different from what I
> thought before
No, explained above. It changes behavior only in case the reply from
forwarder were SERVFAIL. It will always chase cnames to servers
authoritative for the target name.
>
> ------------------ 原始邮件 ------------------
> *发件人:* "Petr Menšík" <pemensik at redhat.com>;
> *发送时间:* 2023年4月4日(星期二) 晚上8:33
> *收件人:* "ltns"<wwwwwwwwww7572 at qq.com>;"bind-users"<bind-users at lists.isc.org>;
> *主题:* Re: BIND | Cname chain resolution using forward ( CNAME&A
> returned but no use A) (#3995)
>
> 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 <pemensik at redhat.com>
>> To: bind-users at 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-3ee4cfd88550 at 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 at 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
--
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/18e9a531/attachment-0001.htm>
More information about the bind-users
mailing list