Different RPZ behavior for IDN domains between BIND 9.20.23 and 9.20.26

Petr Špaček pspacek at isc.org
Tue Aug 11 07:30:59 UTC 2026


On 10. 08. 26 21:26, Ondřej Surý wrote:
> Thanks Peter,
> 
> idx.linkhealth.com is delegated to:
> 
> ;; AUTHORITY SECTION:
> idx.linkhealth.com.	300	IN	NS	ns-858.awsdns-43.net.
> idx.linkhealth.com.	300	IN	NS	ns-1053.awsdns-03.org.
> idx.linkhealth.com.	300	IN	NS	ns-408.awsdns-51.com.
> idx.linkhealth.com.	300	IN	NS	ns-1732.awsdns-24.co.uk.
> 
> but these servers are not authoritative for idx.linkhealth.com, but for linkhealth.com:
> 
> ;; QUESTION SECTION:
> ;idx.linkhealth.com.		IN	SOA
> 
> ;; ANSWER SECTION:
> idx.linkhealth.com.	30	IN	CNAME	eastus2.prodv4.idx.linkhealth.com.
> 
> ;; AUTHORITY SECTION:
> linkhealth.com.		172800	IN	NS	ns-1053.awsdns-03.org.
> linkhealth.com.		172800	IN	NS	ns-1732.awsdns-24.co.uk.
> linkhealth.com.		172800	IN	NS	ns-408.awsdns-51.com.
> linkhealth.com.		172800	IN	NS	ns-858.awsdns-43.net.
> 
> AND
> 
> ;; ANSWER SECTION:
> linkhealth.com.		900	IN	SOA	ns-1053.awsdns-03.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

FTR Microsoft used to have a similar problem in Azure DNS and to their 
credit they fixed it.

Perhaps poke the DNS provider instead of zone owner?

I understand this puts you between rock and hard place, but please 
understand our position too - if we go on accepting more and more 
garbage we will eventually drown in the cesspool.

-- 
Petr Špaček


More information about the bind-users mailing list