Re: Different RPZ behavior for IDN domains between BIND 9.20.23 and 9.20.26
Petr Špaček <[email protected]>
| Newsgroups | gmane.network.dns.bind.user |
|---|---|
| Message-ID | <[email protected]> |
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 -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.