Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response

Emmanuel Fusté manu.fuste at gmail.com
Fri Jul 7 10:17:38 UTC 2023


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.


More information about the bind-users mailing list