Tag: unbound

自己從頭搞整套 Pi-hole 方案 (DNS 阻擋廣告的方案)

如果不用 Pi-hole 這種套件的話，從頭自己搞差不多就是這樣：「Ads blocking with OpenBSD unbound(8)」。

作者除了阻擋的必要功能部份以外，還把 log 導出來丟進 InfluxDB，透過 Grafana 可以看狀態，這類似於 Pi-hole 提供的方案：

Grafana to render the statistics ;
InfluxDB to store the information ;
syslogd(8) and awk(1) to turn DNS queries into statistics ;
collectd(1) and shell script to store unbound statistics and logs ;
unbound(8) and shell script to get and block DNS queries.

對應的 diagram 長這樣 (但為什麼作者要用 comic sans 呢...)：

瀏覽器可以用 uBlock Origin 這類方案來做，可以擋的更細緻，而手機 app 一般就只能靠這種方法過濾掉部份的廣告。

如果想要擋更多的話 (像是只擋某個 url，而不是整個 domain)，得用自建的 root CA 加上 MITM 的方式攔 HTTPS 連線，這通常都是在手機上面跑 virtual VPN，像是 iOS 上的 Surge 5 或是 Quantumult X。

AWS 提供 Hybrid Cloud 環境下 DNS 管理的說明

不知道為什麼出現在 browser tab 上，不知道是哪邊看到的... AWS 放出了一份文件，在講 hybrid cloud 環境下當你同時有一般 IDC 機房，而且使用內部 domain 在管理時，網路與 AWS 打通後要怎麼解決 DNS resolver 的問題：「Hybrid Cloud DNS Solutions for Amazon VPC」。

有些東西在官方的說明文件內都寫過，但是是 AWS 的特殊設計，這邊就會重複說明 XDDD

像是這份文件裡提到 Amazon DNS Server 一定會在 VPC 的 base 位置加二 (舉例來說，10.0.0.0/16 的 VPC，Amazon DNS Server 會在 10.0.0.2)：

Amazon DNS Server
The Amazon DNS Server in a VPC provides full public DNS resolution, with additional resolution for internal records for the VPC and customer-defined Route 53 private DNS records.4 The AmazonProvidedDNS maps to a DNS server running on a reserved IP address at the base of the VPC network range, plus two. For example, the DNS Server on a 10.0.0.0/16 network is located at 10.0.0.2. For VPCs with multiple CIDR blocks, the DNS server IP address is located in the primary CIDR block.

在官方文件裡，則是在「DHCP Options Sets」這邊提到一樣的事情：

When you create a VPC, we automatically create a set of DHCP options and associate them with the VPC. This set includes two options: domain-name-servers=AmazonProvidedDNS, and domain-name=domain-name-for-your-region. AmazonProvidedDNS is an Amazon DNS server, and this option enables DNS for instances that need to communicate over the VPC's Internet gateway. The string AmazonProvidedDNS maps to a DNS server running on a reserved IP address at the base of the VPC IPv4 network range, plus two. For example, the DNS Server on a 10.0.0.0/16 network is located at 10.0.0.2. For VPCs with multiple IPv4 CIDR blocks, the DNS server IP address is located in the primary CIDR block.

另外也還是有些東西在官方的說明文件內沒看過，像是講到 Elastic Network Interface (ENI) 對 Amazon DNS Server 是有封包數量限制的；這點我沒在官方文件上找到，明顯在量太大的時候會中獎，然後開 Support Ticket 才會發現的啊 XDDD：

Each network interface in an Amazon VPC has a hard limit of 1024 packets that it can send to the Amazon Provided DNS server every second.

Anyway... 這份文件裡面提供三種解法：

  • Secondary DNS in a VPC，直接用程式抄一份到 Amazon Route 53 上，這樣 Amazon DNS Server 就可以直接看到了，這也是 AWS 在一般情況下比較推薦的作法。
  • Highly Distributed Forwarders，每台 instance 都跑 Unbound，然後針對不同的 domain 導開，這樣可以有效避開單一 ENI 對 Amazon DNS Server 的封包數量限制，但缺點是這樣的設計通常會需要像是 Puppet 或是 Chef 之類的軟體管理工具才會比較好設定。
  • Zonal Forwarders Using Supersede，就是在上面架設一組 Unbound 伺服器集中管理，透過 DHCP 設定讓 instance 用。但就要注意量不能太大，不然 ENI 對 Amazon DNS Server 的限制可能會爆掉 XD

都可以考慮看看...

Percona XtraDB Cluster 上用 keepalived 實作高可靠度架構

Percona 的人寫了一篇「Using keepalived for HA on top of Percona XtraDB Cluster」，是用 Keepalived 實作高可靠度架構。

目前常見的文章是透過 HAProxy 達成，但 HAProxy 本身就會成為 SPOF，所以一般人的想法就是在 HAProxy 上跑 Keepalived，保持可靠度。但這個問題我之前就抱怨過，既然要跑 Keepalived (我的例子裡是 Heartbeat)，為什麼不在 Percona XtraDB Cluster 上跑就好，load balance 的任務則可以透過 DNS round robin 達成：

We would standardly use keepalived to HA HAproxy, and keepalived supports track_scripts that can monitor whatever we want, so why not just monitor PXC directly?

不過我還是偏愛 Heartbeat，因為 Heartbeat 的功能多了一些，不過架構還是很簡單，實際用起來也發現不容易出問題。

另外 Heartbeat 不論是在 Linux 還是 FreeBSD 上都跑得很好，我連內部機器用的 DNS resolver (跑 Unboound) 都上 Heartbeat。

另外也因為 Keepalived 目前不支援 FreeBSD (參考「About "ipvs" and "keepalived"」這篇文章)，所以也沒打算花時間測試了... :o

用 Unbound 跑處理 DNS Round Robin 服務的問題...

環境是內部有兩台互相做 HA 的 server (用 Heartbeat 或是用 CARP)，然後給一個內部用的 domain 指到兩個 IP address，於是發現不太平均：「Unbound 回傳 RR Set 的順序問題」。

2010 年的時候就有人提過要這個功能，然後被打槍：「[Unbound-users] Round Robin DNS」，最主要的理由是「這應該是 client 要做的事情」。

2012 年三月有人決定自己來：「[Unbound-users] patch implementing round robin rrsets」，patch 本身蠻簡單的 (不過看起來不能保證 thread-safe)，另外也有一些 RFC 隱性希望 DNS resolver 可以處理 round robin 的事情。

四月的時候有人把 patch 修過，解決了 thread-safe 問題：「[Unbound-users] patch: rrset-roundrobin/minimal-responses」。

看起來之後的版本有機會內建了...