FTL v6.2 (dnsmasq v2.90) - Insecure DS reply Warnings for Tailscale Reverse DNS Zones (*.100.in-addr.arpa)

[Ali_SAHIN]

Merhaba Pi-hole Topluluğu,

Yakın zamanda Pi-hole kurulumumu pihole -up en son sürümlere (Core v6.1, FTL v6.2, Web v6.2.1) güncelledim ve hemen DNSMASQ_WARN Pi-hole günlüğümde tekrarlayan mesajlarla karşılaşmaya başladım. Kurulumum, Pi OS 64-bit çalıştıran bir Raspberry Pi 5, Pi-hole ve Tailscale (aynı RPi'de de çalışıyor).

Sorun:

Gördüğüm özel uyarı şu:
DNSMASQ_WARN: Insecure DS reply received for <zone>.100.in-addr.arpa, check domain configuration and upstream DNS server DNSSEC support

<zone> Gözlemlediğim örnekler arasında 66 (for 66.100.in-addr.arpa ) ve 100 (for 100.100.in-addr.arpa ) bulunmaktadır. Bu ters DNS bölgeleri Tailscale'in 100.64.0.0/10 IP aralığındaki IP adreslerine karşılık gelir.

Bu sorun FTL v6.2 güncellemesinden hemen sonra başladı (anladığım kadarıyla şimdi dnsmasq v2.90 kullanıyor). Sistemim bu güncellemeden yaklaşık 3 hafta önce bu belirli uyarılar olmadan çalışıyordu.

Sorun Giderme Adımları:

1. Sistem Saati: Raspberry Pi'min sistem saatinin doğru olduğunu ve NTP üzerinden senkronize edildiğini doğruladım ( timedatectl status gösterir System clock synchronized: yes ).
2. İlk Yukarı Akış DNS'i: 127.0.0.1#5053 Pi-hole'um başlangıçta yukarı akış çözücüsü olarak DNSCrypt-proxy dinlemesini kullanacak şekilde yapılandırılmıştı .
3. Genel Yukarı Akışlarla Test Etme: Sorunu izole etmek için, Pi-hole'un yukarı akış DNS sunucularını geçici olarak iyi DNSSEC desteğiyle bilinen genel çözücülere (Cloudflare'in 1.1.1.1 ve Google'ın 8.8.8.8) doğrudan değiştirdim ve DNSCrypt-proxy'yi atladım. Bu bölgeler için uyarılar, bu genel çözücülerle bile devam etti.Insecure DS reply *.100.in-addr.arpa Bu, davranıştaki değişikliğin FTL v6.2 / dnsmasq v2.90'ın bu belirli ters DNS bölgeleri için DNSSEC'yi ele alış biçimiyle ilgili olduğundan şüphelenmeme yol açıyor.
4. Pi-hole'da DNSSEC Ayarı: Pi-hole'daki (Ayarlar > DNS) "DNSSEC Kullan" seçeneği bu süre boyunca etkindi.

Hipotez ve Bağlam:

Bu uyarıların Tailscale'in özel/sanal IP aralığıyla ilişkili ters DNS bölgeleri için olduğunu ve sorunun FTL güncellemesinden sonra başladığını ve büyük genel DNSSEC destekli yukarı akışlarda bile devam ettiğini göz önünde bulundurarak, dnsmasq v2.90'ın daha katı DNSSEC doğrulaması veya genel DNS hiyerarşisi üzerinden sorgulandıklarında bu bölgeler için DS kayıtlarını işleme biçiminde bir değişiklik olabileceğini düşünüyorum. Bu bölgelerde standart genel DNSSEC kayıtları olmayabilir veya genel DNS üzerinden doğrulama yolları doğası gereği sorunlu olabilir.

Önerilen Çözüm / Sonraki Adım:

Aldığım tavsiyelere dayanarak, Tailscale'e özgü sorgular ( 100.64.0.0/10 IP'ler ve *.ts.net etki alanları için ters aramalar dahil) için DNS'i yönetmenin en sağlam yolunun, bunların Tailscale'in kendi DNS sunucusu tarafından çözümlenmesini sağlamak olduğu anlaşılıyor ( 100.100.100.100 ).

Bunu başarmak için, bir sonraki adımda Pi-hole'da Koşullu Yönlendirmeyi aşağıdaki ayarlarla uygulamayı planlıyorum :

• CIDR gösteriminde yerel ağ:100.64.0.0/10
• DHCP sunucunuzun (yönlendiricinizin) IP adresi:100.100.100.100
• Yerel alan adı (isteğe bağlı):<my-tailscale-domain>.ts.net

Umuyorum ki bu, bu sorguların genel akış çözücülerime (şu anda DNSCrypt-proxy, ancak genel olanlarla da test edildi) gitmesini önleyecek ve böylece bu belirli bölgeler için DNSSEC doğrulama sorunlarının önüne geçecektir.

Topluluğa Sorular:

1. Insecure DS reply Bu davranış (FTL v6.2'ye güncellemeden sonra Tailscale'in IP'leri gibi özel/sanal IP aralıklarının ters DNS bölgeleri için artan uyarılar 100.x.y.z ) bilinen bir sorun mu yoksa daha sıkı DNSSEC doğrulaması nedeniyle dnsmasq v2.90 ile beklenen bir değişiklik mi?
2. Yukarıda açıklandığı gibi Koşullu Yönlendirmeyi yapılandırmak, Pi-hole, Tailscale ve DNSSEC uyarılarını içeren bu özel senaryo için genel olarak önerilen ve en iyi yaklaşım mıdır?
3. dnsmasq Koşullu Yönlendirme kullanılmıyorsa veya başka sorunlar varsa, bu tür özel/sanal ters arama bölgeleriyle DNSSEC'yi ele almak için Pi-hole içinde önemli olabilecek başka ayarlar veya hususlar var mı ?

Yararlı olacaksa bir hata ayıklama günlüğü belirteci sağlamaktan mutluluk duyarım.

Pi-hole'daki harika çalışmanız ve sunabileceğiniz tüm fikirler için teşekkür ederiz!

[Bucking_Horn]

Note that FTL v6.2 embeds dnsmasq v2.92.
There have been adjustments to DNSSEC treatment since v2.90, but I am unaware whether those may contribute to what you are observing.

Note that Tailscale utilises a special (sort of private) IP range (100.64.0.0/10) that is reserved for CGNAT, as employed by ISPs, which could contribute to your observation. The expected answer from public DNS servers would be NXDOMAIN, but if your ISP's DNS servers would be used upstream, and your Tailscale range would by chance match your ISP's, DNS reverse lookup replies may actually yield names.

Conditionally forwarding lookups for your Tailscale range would likely avoid your issue, as long as it would indeed be tied to DNSSEC: By default, pihole-FTL/dnsmasq would not apply DNSSEC validation for such domain-specific forwards.