Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
> I was curious about the additional section count dig is > reporting. I had to do a packet capture to prove it to myself, > but there is an additional records section returned in the > answer from 183.47.126.169. It is the edns OPT pseudosection > which is also shown in my dig output: You appear to be correct, and I stand corrected on this side issue. It doesn't really change the major problem that the name servers serving the cloud.huawei.com zone appear to have a deficient implementation of the concept of a zone. Regards, - Håvard -- 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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
Hi Håvard,
I was curious about the additional section count dig is reporting. I
had to do a packet capture to prove it to myself, but there is an
additional records section returned in the answer from 183.47.126.169.
It is the edns OPT pseudosection which is also shown in my dig output:
% dig +norecurse @183.47.126.169 oauth-login.cloud.huawei.com.
; <<>> DiG 9.10.6 <<>> +norecurse @183.47.126.169
oauth-login.cloud.huawei.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2648
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;oauth-login.cloud.huawei.com. IN
;; AUTHORITY SECTION:
huawei.com. 180 IN SOA ns3.dnsv5.com. enterprise3dnsadmin.dnspod.com.
1688974445 3600 180 1209600 180
;; Query time: 237 msec
;; SERVER: 183.47.126.169#53(183.47.126.169)
;; WHEN: Mon Jul 10 14:29:01 EDT 2023
;; MSG SIZE rcvd: 136
On Mon, Jul 10, 2023 at 1:05 PM Havard Eidnes via bind-users
wrote:
>
> > You are wrong if you think the SOA record is only informal.
> > It's not, see https://www.rfc-editor.org/rfc/rfc2308 for more
> > details.
>
> Exactly. The SOA record included in the "Authority section" of an
> NXDOMAIN ("name does not exist") or NODATA ("answer count" = 0,
> i.e. indicating "name exists, but no record of this type exists")
> indicates "under whose authority is this reply given", as indicated by
> the owner name of the SOA record, and the version number of that zone
> (as indicated by the version number in the SOA record).
>
> Also, following up on an earlier part of this thread:
>
> >>> It is at the core of delegation and trust model of DNS, now
> >>> possibly enforced by DNSSEC.
>
> Correct. It's a matter of how you divide the name space into
> zones, what a minimal zone looks like from an external observer,
> and how delegations work.
>
> A minimal zone will need to contain a SOA record for the zone,
> and the NS RRset for the zone. When a DNS name server which has
> been delegated authority for a given zone, that name server had
> better serve up the correct(!) SOA record with the correct owner
> name when supplying an NXDOMAIN or a NODATA answer.
>
> $ dig huawei.com. ns
> ...
> ;; ANSWER SECTION:
> huawei.com. 2616IN NS nsall4th.huawei.cn.
> huawei.com. 2616IN NS nsallsec.huawei.com.
> huawei.com. 2616IN NS nsall.huawei.com.
> huawei.com. 2616IN NS nsall3rd.huawei.cn.
> ...
>
> Pick one, query:
>
> $ dig @nsall.huawei.com. cloud.huawei.com. ns
> ...
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30727
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
> ...
> ;; AUTHORITY SECTION:
> cloud.huawei.com. 600 IN NS ns4.dnsv5.com.
> cloud.huawei.com. 600 IN NS ns3.dnsv5.com.
> cloud.huawei.com. 600 IN NS gns1.huaweicloud-dns.org.
> ...
>
> This means:
>
> 1) The zone cloud.huawei.com should exist
> 2) This entire zone is delegated to the named name servers (only
>authority over the DS record for the zone name remains with the
>parent NSes, if/when you do DNSSEC).
> 3) NXDOMAIN or NODATA responses from these name servers for names
>in cloud.huawei.com should include the SOA record for the
>cloud.huawei.com zone.
> 4) As stated above, both SOA and NS records for this zone should
>be returned by these name servers (they do not, see below).
>
> Side issue: note that the "additional" count above in the last
> reply is wrong (there is no additional record in the reply).
>
> $ dig @ns4.dnsv5.com. cloud.huawei.com. ns
> ...
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15950
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ...
> ;; AUTHORITY SECTION:
> huawei.com. 180 IN SOA ns3.dnsv5.com.
> enterprise3dnsadmin.dnspod.com. 1688974445 3600 180 1209600 180
> ...
>
> Again, "additional" count is wrong. The owner name of the SOA
> record is also wrong, since the reply from nsall.huawei.com above
> states that cloud.huawei.com is a delegated zone. It is
> therefore wrong by this name server to refer back up the zone
> tree to the parent zone's authority for a name which is clearly
> within the delegated zone.
>
> Also, it failed to respond with a copy of the NS RRset for the
> zone; it should have included that set in the answer section when
> asked explicitly about it.
>
> $ dig @ns4.dnsv5.com. .cloud.huawei.com. a
> ...
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37427
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ...
> ;; AUTHORITY SECTION:
> huawei.com. 180 IN SOA ns3.dnsv5.com.
> enterprise3dnsadmin.dnspod.com. 1688974445 3600 180 1209600 180
> ...
>
> OK, here we get (correctly) a "name does not exist"
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
> You are wrong if you think the SOA record is only informal.
> It's not, see https://www.rfc-editor.org/rfc/rfc2308 for more
> details.
Exactly. The SOA record included in the "Authority section" of an
NXDOMAIN ("name does not exist") or NODATA ("answer count" = 0,
i.e. indicating "name exists, but no record of this type exists")
indicates "under whose authority is this reply given", as indicated by
the owner name of the SOA record, and the version number of that zone
(as indicated by the version number in the SOA record).
Also, following up on an earlier part of this thread:
>>> It is at the core of delegation and trust model of DNS, now
>>> possibly enforced by DNSSEC.
Correct. It's a matter of how you divide the name space into
zones, what a minimal zone looks like from an external observer,
and how delegations work.
A minimal zone will need to contain a SOA record for the zone,
and the NS RRset for the zone. When a DNS name server which has
been delegated authority for a given zone, that name server had
better serve up the correct(!) SOA record with the correct owner
name when supplying an NXDOMAIN or a NODATA answer.
$ dig huawei.com. ns
...
;; ANSWER SECTION:
huawei.com. 2616IN NS nsall4th.huawei.cn.
huawei.com. 2616IN NS nsallsec.huawei.com.
huawei.com. 2616IN NS nsall.huawei.com.
huawei.com. 2616IN NS nsall3rd.huawei.cn.
...
Pick one, query:
$ dig @nsall.huawei.com. cloud.huawei.com. ns
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30727
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
...
;; AUTHORITY SECTION:
cloud.huawei.com. 600 IN NS ns4.dnsv5.com.
cloud.huawei.com. 600 IN NS ns3.dnsv5.com.
cloud.huawei.com. 600 IN NS gns1.huaweicloud-dns.org.
...
This means:
1) The zone cloud.huawei.com should exist
2) This entire zone is delegated to the named name servers (only
authority over the DS record for the zone name remains with the
parent NSes, if/when you do DNSSEC).
3) NXDOMAIN or NODATA responses from these name servers for names
in cloud.huawei.com should include the SOA record for the
cloud.huawei.com zone.
4) As stated above, both SOA and NS records for this zone should
be returned by these name servers (they do not, see below).
Side issue: note that the "additional" count above in the last
reply is wrong (there is no additional record in the reply).
$ dig @ns4.dnsv5.com. cloud.huawei.com. ns
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15950
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...
;; AUTHORITY SECTION:
huawei.com. 180 IN SOA ns3.dnsv5.com.
enterprise3dnsadmin.dnspod.com. 1688974445 3600 180 1209600 180
...
Again, "additional" count is wrong. The owner name of the SOA
record is also wrong, since the reply from nsall.huawei.com above
states that cloud.huawei.com is a delegated zone. It is
therefore wrong by this name server to refer back up the zone
tree to the parent zone's authority for a name which is clearly
within the delegated zone.
Also, it failed to respond with a copy of the NS RRset for the
zone; it should have included that set in the answer section when
asked explicitly about it.
$ dig @ns4.dnsv5.com. .cloud.huawei.com. a
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37427
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...
;; AUTHORITY SECTION:
huawei.com. 180 IN SOA ns3.dnsv5.com.
enterprise3dnsadmin.dnspod.com. 1688974445 3600 180 1209600 180
...
OK, here we get (correctly) a "name does not exist" error, since
the name truly doesn't exist, but again the owner name for the
SOA record in the response is wrong, and refers to the parent
zone, not the zone where the name would exist if it did exist.
Upwards referral => SERVFAIL. You get what you deserve for not
correctly implementing the delegation model and zone delination
rules.
$ dig @ns3.dnsv5.com. oauth-login.cloud.huawei.com.
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22050
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...
;; AUTHORITY SECTION:
huawei.com. 180 IN SOA ns3.dnsv5.com.
enterprise3dnsadmin.dnspod.com. 1688974445 3600 180 1209600 180
...
Again, "Additional" count is wrong, and the SOA owner name is
wrong -- it should have been cloud.huawei.com, since the copy of
the NS RRset from the huawei.com zone indicates that
cloud.huawei.com should be a zone.
Best regards,
- Håvard
--
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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
You are wrong if you think the SOA record is only informal. It’s not, see https://www.rfc-editor.org/rfc/rfc2308 for more details. Then > In a similar way, bind should not object to the SOA mail contect being valid, > as a surprising number of zones actually fail to handle mail to that address mixes things that **are** important to DNS (caches) and those that **aren’t** important to the DNS. You used that as a strawman argument and that never helps to have a useful discussion. Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 7. 7. 2023, at 12:35, Jakob Bohm via bind-users > wrote: > > On 2023-07-07 12:17, Emmanuel Fusté wrote: >>> Le 07/07/2023 à 11:57, Jakob Bohm via bind-users a écrit : >>> >>> >>> On 2023-06-02 05:02, Jesus Cea wrote: On 2/6/23 4:25, Mark Andrews wrote: > Yep, some people just don’t take care with delegations. Complain to > Huawei. > Complain to the other companies you list in your followup email. > > All it takes to fix this is to change the name of the zone on the child > servers > (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from > “huawei.com” > to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the > zone > if they are fully qualified. If there are other delegations from > huawei.com > for other sub zones to these servers they will also need to be > instantiated. > > It’s maybe 10 minute work for each subdomain to fix. It just requires > someone > to do the work. I sympathize. Expertise and caring for the job is something the world is losing fast and few people care at all. Complaining to business is not going to work, because this misconfiguration works fine for 99.9% of their users, clients of more "lax" DNS resolvers. What I get from your reply is that BIND is not expected to do anything about this. It is a bit disappointed but I agree that BIND is doing the right thing. Too bad big players don't care. But I need to "solve" this, so dropping BIND (nooo!) or patching software is on my table now. > When people come to you and say that it works with Google, et al. point > them at > https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error > and say > “Here is a DNS configuration testing site and it reports the zone as > broken, you > need to take it up with the company." "Whatever, Google works and you don't. You sucks!". Few people care about doing the right thing if crap works for them. If only 8.8.8.8 cared and gave back SERVFAIL as it should, everybody would fix her configuration immediately. Postel law [*] was a mistake (be strict when sending and forgiving when receiving). Nice advice, awful consequences we will pay forever. https://en.wikipedia.org/wiki/Robustness_principle >>> >>> The robustness principle isn't the problem here. It is more that parts of >>> the >>> bind code isapparently being strict about receiving out-of-range values in >>> an >>> informational part ofDNS responses, then turning a mostly usable reply from >>> remote servers into a SERVFAIL of binds own making, rather than just >>> filtering >>> out that informational part if bind considers it worth checking at all. >>> >> It is at the core of delegation and trust model of DNS, now possibly >> enforced by DNSSEC. Peer centric resolvers are lax on this checking for all >> but the security of their users. >> So in your opinion it is purely useless, and bad data it better than >> nodata/error. >> > I am saying that the SOA copy in the authority section of responses is purely > informational, unlike the data that provides DNSSEC signatures or even the > data that provides IP addresses for servers in responses to MX queries. > > So from that perspective, if bind code checks that this informal copy of an > SOA record is for the wrong zone, it should simply filter out that SOA > record instead of filtering out the entire response to the actual query. > > In the special case of using that SOA copy to get the negative response TTL, > that special use should only check that the SOA copy was provided in the > same DNS response as the negative response to be cached, not the diagnostic > data about the origin server's zone files. > > In a similar way, bind should not object to the SOA mail contect being valid, > as a surprising number of zones actually fail to handle mail to that address > (I personally had to go through hoops with support people when trying to > coordinate a small change with another zone that I no longer had a business > relationship with, so validating this is useful in a compliance checker, but > not > in a caching resolver). > > Enjoy > > Jakob > -- > Jakob
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 2023-07-07 12:17, Emmanuel Fusté wrote: Le 07/07/2023 à 11:57, Jakob Bohm via bind-users a écrit : On 2023-06-02 05:02, Jesus Cea wrote: On 2/6/23 4:25, Mark Andrews wrote: Yep, some people just don’t take care with delegations. Complain to Huawei. Complain to the other companies you list in your followup email. All it takes to fix this is to change the name of the zone on the child servers (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from “huawei.com” to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the zone if they are fully qualified. If there are other delegations from huawei.com for other sub zones to these servers they will also need to be instantiated. It’s maybe 10 minute work for each subdomain to fix. It just requires someone to do the work. I sympathize. Expertise and caring for the job is something the world is losing fast and few people care at all. Complaining to business is not going to work, because this misconfiguration works fine for 99.9% of their users, clients of more "lax" DNS resolvers. What I get from your reply is that BIND is not expected to do anything about this. It is a bit disappointed but I agree that BIND is doing the right thing. Too bad big players don't care. But I need to "solve" this, so dropping BIND (nooo!) or patching software is on my table now. When people come to you and say that it works with Google, et al. point them at https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error and say “Here is a DNS configuration testing site and it reports the zone as broken, you need to take it up with the company." "Whatever, Google works and you don't. You sucks!". Few people care about doing the right thing if crap works for them. If only 8.8.8.8 cared and gave back SERVFAIL as it should, everybody would fix her configuration immediately. Postel law [*] was a mistake (be strict when sending and forgiving when receiving). Nice advice, awful consequences we will pay forever. https://en.wikipedia.org/wiki/Robustness_principle The robustness principle isn't the problem here. It is more that parts of the bind code isapparently being strict about receiving out-of-range values in an informational part ofDNS responses, then turning a mostly usable reply from remote servers into a SERVFAIL of binds own making, rather than just filtering out that informational part if bind considers it worth checking at all. It is at the core of delegation and trust model of DNS, now possibly enforced by DNSSEC. Peer centric resolvers are lax on this checking for all but the security of their users. So in your opinion it is purely useless, and bad data it better than nodata/error. I am saying that the SOA copy in the authority section of responses is purely informational, unlike the data that provides DNSSEC signatures or even the data that provides IP addresses for servers in responses to MX queries. So from that perspective, if bind code checks that this informal copy of an SOA record is for the wrong zone, it should simply filter out that SOA record instead of filtering out the entire response to the actual query. In the special case of using that SOA copy to get the negative response TTL, that special use should only check that the SOA copy was provided in the same DNS response as the negative response to be cached, not the diagnostic data about the origin server's zone files. In a similar way, bind should not object to the SOA mail contect being valid, as a surprising number of zones actually fail to handle mail to that address (I personally had to go through hoops with support people when trying to coordinate a small change with another zone that I no longer had a business relationship with, so validating this is useful in a compliance checker, but not in a caching resolver). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
Le 07/07/2023 à 11:57, Jakob Bohm via bind-users a écrit : On 2023-06-02 05:02, Jesus Cea wrote: On 2/6/23 4:25, Mark Andrews wrote: Yep, some people just don’t take care with delegations. Complain to Huawei. Complain to the other companies you list in your followup email. All it takes to fix this is to change the name of the zone on the child servers (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from “huawei.com” to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the zone if they are fully qualified. If there are other delegations from huawei.com for other sub zones to these servers they will also need to be instantiated. It’s maybe 10 minute work for each subdomain to fix. It just requires someone to do the work. I sympathize. Expertise and caring for the job is something the world is losing fast and few people care at all. Complaining to business is not going to work, because this misconfiguration works fine for 99.9% of their users, clients of more "lax" DNS resolvers. What I get from your reply is that BIND is not expected to do anything about this. It is a bit disappointed but I agree that BIND is doing the right thing. Too bad big players don't care. But I need to "solve" this, so dropping BIND (nooo!) or patching software is on my table now. When people come to you and say that it works with Google, et al. point them at https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error and say “Here is a DNS configuration testing site and it reports the zone as broken, you need to take it up with the company." "Whatever, Google works and you don't. You sucks!". Few people care about doing the right thing if crap works for them. If only 8.8.8.8 cared and gave back SERVFAIL as it should, everybody would fix her configuration immediately. Postel law [*] was a mistake (be strict when sending and forgiving when receiving). Nice advice, awful consequences we will pay forever. https://en.wikipedia.org/wiki/Robustness_principle The robustness principle isn't the problem here. It is more that parts of the bind code isapparently being strict about receiving out-of-range values in an informational part ofDNS responses, then turning a mostly usable reply from remote servers into a SERVFAIL of binds own making, rather than just filtering out that informational part if bind considers it worth checking at all. It is at the core of delegation and trust model of DNS, now possibly enforced by DNSSEC. Peer centric resolvers are lax on this checking for all but the security of their users. So in your opinion it is purely useless, and bad data it better than nodata/error. Emmanuel. -- 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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 2023-06-02 05:02, Jesus Cea wrote: On 2/6/23 4:25, Mark Andrews wrote: Yep, some people just don’t take care with delegations. Complain to Huawei. Complain to the other companies you list in your followup email. All it takes to fix this is to change the name of the zone on the child servers (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from “huawei.com” to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the zone if they are fully qualified. If there are other delegations from huawei.com for other sub zones to these servers they will also need to be instantiated. It’s maybe 10 minute work for each subdomain to fix. It just requires someone to do the work. I sympathize. Expertise and caring for the job is something the world is losing fast and few people care at all. Complaining to business is not going to work, because this misconfiguration works fine for 99.9% of their users, clients of more "lax" DNS resolvers. What I get from your reply is that BIND is not expected to do anything about this. It is a bit disappointed but I agree that BIND is doing the right thing. Too bad big players don't care. But I need to "solve" this, so dropping BIND (nooo!) or patching software is on my table now. When people come to you and say that it works with Google, et al. point them at https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error and say “Here is a DNS configuration testing site and it reports the zone as broken, you need to take it up with the company." "Whatever, Google works and you don't. You sucks!". Few people care about doing the right thing if crap works for them. If only 8.8.8.8 cared and gave back SERVFAIL as it should, everybody would fix her configuration immediately. Postel law [*] was a mistake (be strict when sending and forgiving when receiving). Nice advice, awful consequences we will pay forever. https://en.wikipedia.org/wiki/Robustness_principle The robustness principle isn't the problem here. It is more that parts of the bind code isapparently being strict about receiving out-of-range values in an informational part ofDNS responses, then turning a mostly usable reply from remote servers into a SERVFAIL of binds own making, rather than just filtering out that informational part if bind considers it worth checking at all. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- 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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 6/7/23 12:17 AM, Jesus Cea wrote: The list is quite long, in a few minutes I have a 859 unique requests with the same configuration error. Interestingly, quite a few from "ntp.org". For example: resolver: notice: DNS format error from 102.130.49.148#53 resolving 0.centos.pool.ntp.org/ for #YYY Name pool.ntp.org (SOA) not subdomain of zone centos.pool.ntp.org -- invalid response resolver: notice: DNS format error from 102.130.49.148#53 resolving 0.debian.pool.ntp.org/ for #YYY Name pool.ntp.org (SOA) not subdomain of zone debian.pool.ntp.org -- invalid response I just sent an email to NTP mailing list. That looks like a pool issue. You should send an email to the NTP pool mailing list rather than the NTP mailing list. They are different. Danny -- 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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 2/6/23 4:25, Mark Andrews wrote: Yep, some people just don’t take care with delegations. Complain to Huawei. Complain to the other companies you list in your followup email. Huawei is already notified, days ago. No reply and no changes so far. The list is quite long, in a few minutes I have a 859 unique requests with the same configuration error. Interestingly, quite a few from "ntp.org". For example: resolver: notice: DNS format error from 102.130.49.148#53 resolving 0.centos.pool.ntp.org/ for #YYY Name pool.ntp.org (SOA) not subdomain of zone centos.pool.ntp.org -- invalid response resolver: notice: DNS format error from 102.130.49.148#53 resolving 0.debian.pool.ntp.org/ for #YYY Name pool.ntp.org (SOA) not subdomain of zone debian.pool.ntp.org -- invalid response I just sent an email to NTP mailing list. Lenovo is guilty too: resolver: notice: DNS format error from 103.30.232.121#53 resolving ibase.gtm.lenovo.com/ for #YYY Name lenovo.com (SOA) not subdomain of zone gtm.lenovo.com -- invalid response qq.com too: resolver: notice: DNS format error from 121.51.160.207#53 resolving ns3.qq.com/ for : Name qq.com (SOA) not subdomain of zone ns3.qq.com -- invalid response -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -- 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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
> On 02/06/2023 13:59, Jesus Cea wrote: >> On 2/6/23 10:38, Cathy Almond wrote: >>> Has this just started - as in, it worked before ... when? >> >> No idea. We have been biten by this because a new client. The issue >> could be for ages, no idea.> That may be so. For the client, they're >> getting a SERVFAIL from your resolver instead of 'there is no RR >> for oauth-login.cloud.huawei.com'. > > But they should be getting a query response for the A record for the > same name, and then using that - assuming that they do actually query > for the A record too? > > Is the client actually broken because of the broken provisioning of > the servers for cloud.huawei.com, or is the issue just the plague of > log messages you're seeing? > > (Aside: it is nevertheless a pity Huawei can't set up this delegation > properly - it might just be an incompletely/improperly configured > (maybe proxying?) set of load-balancers or something of that ilk). It definately looks like a load-balancer of some sort which doesn't sufficiently implement the DNS standards, and probably has no concept of "zone", or even knows anything about other RR types than "A". Ref. the answers you get to dig @ns3.dnsv5.com. oauth-login.cloud.huawei.com. a (gives two IPv4 addresses) compared to dig @ns3.dnsv5.com. oauth-login.cloud.huawei.com. dig @ns3.dnsv5.com. cloud.huawei.com. ns Both of the two latter say "NOERROR", "answer-count=0" and refers in the authority section to ;; AUTHORITY SECTION: huawei.com. 180 IN SOA ns3.dnsv5.com. enterprise3dnsadmin.dnspod.com. 1686041357 3600 180 1209600 180 However, asking one of the huawei.com name servers for the name servers for cloud.huawei.com as e.g. dig @nsall.huawei.com. cloud.huawei.com. ns gives this result: ;; AUTHORITY SECTION: cloud.huawei.com. 600 IN NS gns1.huaweicloud-dns.org. cloud.huawei.com. 600 IN NS ns3.dnsv5.com. cloud.huawei.com. 600 IN NS ns4.dnsv5.com. So... Neither of those three appear to even implement the concept of "zone", and the observed behaviour ensues, as the SOA when asked for or NS records for that name results in an upwards referral, and that now triggers a SERVFAIL, as that doesn't progress the resolution of the name. Regards, - Håvard -- 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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 02/06/2023 13:59, Jesus Cea wrote: > On 2/6/23 10:38, Cathy Almond wrote: >> Has this just started - as in, it worked before ... when? > > No idea. We have been biten by this because a new client. The issue > could be for ages, no idea.> That may be so. For the client, they're getting a SERVFAIL from your resolver instead of 'there is no RR for oauth-login.cloud.huawei.com'. But they should be getting a query response for the A record for the same name, and then using that - assuming that they do actually query for the A record too? Is the client actually broken because of the broken provisioning of the servers for cloud.huawei.com, or is the issue just the plague of log messages you're seeing? (Aside: it is nevertheless a pity Huawei can't set up this delegation properly - it might just be an incompletely/improperly configured (maybe proxying?) set of load-balancers or something of that ilk). -- 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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 2/6/23 7:59, Nick Tait via bind-users wrote: On 2/06/23 15:02, Jesus Cea wrote: What I get from your reply is that BIND is not expected to do anything about this. It is a bit disappointed but I agree that BIND is doing the right thing. Too bad big players don't care. But I need to "solve" this, so dropping BIND (nooo!) or patching software is on my table now. Don't know if it will work, but something to try could be to create a forwarding zone for each of the zones that is having this problem, and forward the queries to (e.g.) Google? In theory that would cause BIND to ask Google for the answer instead of working it out for itself? It doesn't work, because Google (8.8.8.8) is giving back exactly what huawei provides (a NODATA reply, with an invalid SOA in the authoritative section) and BIND "verifying" resolver detects the problem and reply to the DNS client with a (correct but inconvenient) SERVFAIL. -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -- 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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 2/6/23 10:38, Cathy Almond wrote: Has this just started - as in, it worked before ... when? No idea. We have been biten by this because a new client. The issue could be for ages, no idea. It sounds like 'they changed something', possibly by accident (maybe adding more servers or changing their provisioning tools?), so it wouldn't hurt to let them know directly. I tried a handful of Huawei emails. No reply so far. -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -- 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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 01/06/2023 15:58, Jesus Cea wrote: I am getting errors "Name huawei.com (SOA) not subdomain of zone cloud.huawei.com". The problem raises when requesting on oauth-login.cloud.huawei.com . The problem was described in the mailing list: https://lists.isc.org/pipermail/bind-users/2021-January/104064.html BIND is replying with a SERVFAIL. This is correct and appropriate. Nevertheless resolvers like 8.8.8.8, 1.1.1.1, 9.9.9.9 and many (most) other are not doing that SOA verification, so for users we are the guilty, not Huawey, because "using Google it works!". In fact, we have a big customer phone app failing because of this (yes, this seems to be a bug with that app but, again, "with google it works!"). What can we do? Is possible to disable that check in bind? We are using 9.16. We could upgrade to 9.18, if needed. Thanks. Has this just started - as in, it worked before ... when? It sounds like 'they changed something', possibly by accident (maybe adding more servers or changing their provisioning tools?), so it wouldn't hurt to let them know directly. -- 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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 2/06/23 15:02, Jesus Cea wrote: What I get from your reply is that BIND is not expected to do anything about this. It is a bit disappointed but I agree that BIND is doing the right thing. Too bad big players don't care. But I need to "solve" this, so dropping BIND (nooo!) or patching software is on my table now. Don't know if it will work, but something to try could be to create a forwarding zone for each of the zones that is having this problem, and forward the queries to (e.g.) Google? In theory that would cause BIND to ask Google for the answer instead of working it out for itself? Nick. -- 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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 2/6/23 4:25, Mark Andrews wrote: Yep, some people just don’t take care with delegations. Complain to Huawei. Complain to the other companies you list in your followup email. All it takes to fix this is to change the name of the zone on the child servers (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from “huawei.com” to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the zone if they are fully qualified. If there are other delegations from huawei.com for other sub zones to these servers they will also need to be instantiated. It’s maybe 10 minute work for each subdomain to fix. It just requires someone to do the work. I sympathize. Expertise and caring for the job is something the world is losing fast and few people care at all. Complaining to business is not going to work, because this misconfiguration works fine for 99.9% of their users, clients of more "lax" DNS resolvers. What I get from your reply is that BIND is not expected to do anything about this. It is a bit disappointed but I agree that BIND is doing the right thing. Too bad big players don't care. But I need to "solve" this, so dropping BIND (nooo!) or patching software is on my table now. When people come to you and say that it works with Google, et al. point them at https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error and say “Here is a DNS configuration testing site and it reports the zone as broken, you need to take it up with the company." "Whatever, Google works and you don't. You sucks!". Few people care about doing the right thing if crap works for them. If only 8.8.8.8 cared and gave back SERVFAIL as it should, everybody would fix her configuration immediately. Postel law [*] was a mistake (be strict when sending and forgiving when receiving). Nice advice, awful consequences we will pay forever. https://en.wikipedia.org/wiki/Robustness_principle -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -- 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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
Yep, some people just don’t take care with delegations. Complain to Huawei. Complain to the other companies you list in your followup email. All it takes to fix this is to change the name of the zone on the child servers (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from “huawei.com” to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the zone if they are fully qualified. If there are other delegations from huawei.com for other sub zones to these servers they will also need to be instantiated. It’s maybe 10 minute work for each subdomain to fix. It just requires someone to do the work. This is a very old (last millennia) mis configuration method used by people who want to avoid doing delegations. Domain name speculators used to do this using “com” or even “.” as the zone name and wildcard A records to provide A answers for the zones delegated to the server. It “works” if all you return is positive answers but that hasn’t been true since IPv6 came into existence. e.g. "*. A ” When people come to you and say that it works with Google, et al. point them at https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error and say “Here is a DNS configuration testing site and it reports the zone as broken, you need to take it up with the company." Mark > On 2 Jun 2023, at 00:58, Jesus Cea wrote: > > I am getting errors "Name huawei.com (SOA) not subdomain of zone > cloud.huawei.com". The problem raises when requesting on > oauth-login.cloud.huawei.com . The problem was described in the mailing list: > > https://lists.isc.org/pipermail/bind-users/2021-January/104064.html > > BIND is replying with a SERVFAIL. This is correct and appropriate. > Nevertheless resolvers like 8.8.8.8, 1.1.1.1, 9.9.9.9 and many (most) other > are not doing that SOA verification, so for users we are the guilty, not > Huawey, because "using Google it works!". In fact, we have a big customer > phone app failing because of this (yes, this seems to be a bug with that app > but, again, "with google it works!"). > > What can we do? Is possible to disable that check in bind? > > We are using 9.16. We could upgrade to 9.18, if needed. > > Thanks. > > -- > Jesús Cea Avión _/_/ _/_/_/_/_/_/ > j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/ > Twitter: @jcea_/_/_/_/ _/_/_/_/_/ > jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > -- > 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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 1/6/23 17:00, Ondřej Surý wrote:
From top of my head - try disabling QNAME minimization.
I don't see the relevance but I tried "qname-minimization off" in my
configuration. No changes, I still see the SERVFAIL.
I insist this is not a bug in BIND. The original domain is
misconfigured. But this misconfiguration is pretty common and resolvers
like 8.8.8.8, 1.1.1.1, 9.9.9.9 just ignore the issue and provide a nice
(and wrong, I agree) "NOERROR" reply. They are faulty, not BIND. But my
clients do not agree: "it works fine with google/cloudflare/infoblox,
you give back a SERVFAIL, goodbye until you fix it, rookie!".
You can see the issue yourself doing:
dig -t @YOUR_DNS_SERVER_IP oauth-login.cloud.huawei.com
If you are using BIND you will see a SERVFAIL. Then try with 8.8.8.8,
1.1.1.1, 9.9.9.9 and whoever other open DNS resolver you know about.
Compare the results.
All big ISP resolvers I tried in Spain give back a NOERROR. Universities
too.
This issue was described perfectly in this mailing list a couple of
years ago:
https://lists.isc.org/pipermail/bind-users/2021-January/104064.html
This huawei misconfiguration is quite common around and since big DNS
players just accept it, I am having a quite hard time defending that
BIND is actually doing the right thing.
For instance, a few examples from my logs(only a few seconds of them!).
There are MANY MANY more. Try requesting for (using your BIND
server and the 8.8.8.8):
aes.orange.es
api.mediago.io
appmimovistar.movistar.es
eneotecnologia.com
epns.eset.com
t3pub.movistar.es
trace-eu.mediago.io
trace.mediago.io
I can provide a quite long list if requested.
Studying the sourcecode, I see this in "lib/dns/resolver.c":
"""
if (!dns_name_issubdomain(>name, >domain)) {
dns_name_format(>domain, buf, sizeof(buf));
UNEXPECTED_ERROR(__FILE__, __LINE__,
"'%s' is not subdomain of '%s'", fctx->info,
buf);
result = ISC_R_UNEXPECTED;
goto cleanup_fcount;
}
"""
Nothing there looks like can be configured, beside just deleting that
code and recompiling.
There are QNAME minimization code down the same function, but the code
doesn't reach there, the error is generated before getting there. So no,
"qname-minimization off" doesn't solve this.
--
Jesús Cea Avión _/_/ _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/
Twitter: @jcea_/_/_/_/ _/_/_/_/_/
jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/
"My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
On 1/6/23 17:00, Ondřej Surý wrote:
From top of my head - try disabling QNAME minimization.
I don't see the relevance but I tried "qname-minimization off" in my
configuration. No changes, I still see the SERVFAIL.
I insist this is not a bug in BIND. The original domain is
misconfigured. But this misconfiguration is pretty common and resolvers
like 8.8.8.8, 1.1.1.1, 9.9.9.9 just ignore the issue and provide a nice
(and wrong, I agree) "NOERROR" reply. They are faulty, not BIND. But my
clients do not agree: "it works fine with google/cloudflare/infoblox,
you give back a SERVFAIL, goodbye until you fix it, rookie!".
You can see the issue yourself doing:
dig -t @YOUR_DNS_SERVER_IP oauth-login.cloud.huawei.com
If you are using BIND you will see a SERVFAIL. Then try with 8.8.8.8,
1.1.1.1, 9.9.9.9 and whoever other open DNS resolver you know about.
Compare the results.
All big ISP resolvers I tried in Spain give back a NOERROR. Universities
too.
This issue was described perfectly in this mailing list a couple of
years ago:
https://lists.isc.org/pipermail/bind-users/2021-January/104064.html
This huawei misconfiguration is quite common around and since big DNS
players just accept it, I am having a quite hard time defending that
BIND is actually doing the right thing.
For instance, a few examples from my logs(only a few seconds of them!).
There are MANY MANY more. Try requesting for (using your BIND
server and the 8.8.8.8):
aes.orange.es
api.mediago.io
appmimovistar.movistar.es
eneotecnologia.com
epns.eset.com
t3pub.movistar.es
trace-eu.mediago.io
trace.mediago.io
I can provide a quite long list if requested.
Studying the sourcecode, I see this in "lib/dns/resolver.c":
"""
if (!dns_name_issubdomain(>name, >domain)) {
dns_name_format(>domain, buf, sizeof(buf));
UNEXPECTED_ERROR(__FILE__, __LINE__,
"'%s' is not subdomain of '%s'", fctx->info,
buf);
result = ISC_R_UNEXPECTED;
goto cleanup_fcount;
}
"""
Nothing there looks like can be configured, beside just deleting that
code and recompiling.
There are QNAME minimization code down the same function, but the code
doesn't reach there, the error is generated before getting there. So no,
"qname-minimization off" doesn't solve this.
--
Jesús Cea Avión _/_/ _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/
Twitter: @jcea_/_/_/_/ _/_/_/_/_/
jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/
"My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
From top of my head - try disabling QNAME minimization. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 1. 6. 2023, at 16:58, Jesus Cea wrote: > > I am getting errors "Name huawei.com (SOA) not subdomain of zone > cloud.huawei.com". The problem raises when requesting on > oauth-login.cloud.huawei.com . The problem was described in the mailing list: > > https://lists.isc.org/pipermail/bind-users/2021-January/104064.html > > BIND is replying with a SERVFAIL. This is correct and appropriate. > Nevertheless resolvers like 8.8.8.8, 1.1.1.1, 9.9.9.9 and many (most) other > are not doing that SOA verification, so for users we are the guilty, not > Huawey, because "using Google it works!". In fact, we have a big customer > phone app failing because of this (yes, this seems to be a bug with that app > but, again, "with google it works!"). > > What can we do? Is possible to disable that check in bind? > > We are using 9.16. We could upgrade to 9.18, if needed. > > Thanks. > > -- > Jesús Cea Avión _/_/ _/_/_/_/_/_/ > j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/ > Twitter: @jcea_/_/_/_/ _/_/_/_/_/ > jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > -- > 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
