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