ISC DHCPD 要 EoL

看到「ISC DHCP Server has reached EOL」這個,月初的時候 ISC 宣佈了 EoL,除非有嚴重的安全性問題冒出來,不然官方打算停止維護了:

The 4.4.3-P1 and 4.1-ESV-R16-P2 versions of ISC DHCP, released on October 5, 2022, are the last maintenance versions of this software that ISC plans to publish. If we become aware of a significant security vulnerability, we might make an exception to this, but it is our intention to cease actively maintaining this codebase.

ISC 則是在推 Kea

Network and system administrators deploying DHCP in new environments should look beyond ISC DHCP for a solution, as it would be irresponsible to invest in new deployments of this software which is now end-of-life. Naturally, ISC suggests new users consider our Kea DHCP server, but there are alternatives.

從維基百科上的「Comparison of DHCP server software」這頁可以看到目前 DHCP server 的選擇。最直接的差異是,其他非 ISC 的全部都是 GPL,只有 ISC 的是 non-GPL。

不過一般不太會自己架 DHCP server,大多是用設備內建裝的跑,以後如果有機會要裝的話,也許得去熟悉 Kea 了...

原來 ISC 自己已經不用 ISC license 了

查資料的時候翻到「ISC Software Licenses」這頁,發現從 2015 年開始 ISC 就打算換掉原先的 ISC license,陸陸續續都轉移到 MPL 2.0...

在維基百科的頁面上可以看到一些說明,包括 KeaBINDISC DHCP 都已經換完了:

In 2015, ISC announced they would release their Kea DHCP Software under the Mozilla Public License 2.0, stating, "There is no longer a good reason for ISC to have its own license, separate from everything else". They also preferred a copyleft license, stating, "If a company uses our software but improves it, we really want those improvements to go back into the master source". Throughout the following years, they re-licensed all ISC-hosted software, including BIND in 2016 and ISC DHCP Server in 2017.

不過 INN 還是維持著 ISC license,應該是因為不算是 ISC 的正式產品?

Smart TV 與遊戲主機的 DNS 經常是設死的

Hacker News Daily 上看到「Your Smart TV is probably ignoring your PiHole」,裡面提到了很多遊戲主機並不會依照從 DHCP 拿到的 DNS 設定使用,而是直接設死:

Nearly 70% of smart TVs and 46% of game consoles were found to contain hardcoded DNS settings - allowing them to simply ignore your local network’s DNS server entirely. On average, Smart TVs generate an average of 60 megabytes of outgoing Internet traffic per day, all the while bypassing tools like PiHole.

裡面提到的論文是「Characterizing Smart Home IoT Traffic in the Wild」這篇,裡面分析了不同種類的裝置 DNS 的狀況,以及 HTTP/HTTPS 的比率:

回到原來的文章,裡面提到了用 NAT 的方式把 1.1.1.1 的 TCP/UDP Port 53 導到 Pi-hole 上面過濾,這樣看起來還行,下面的 DNS over TLSDNS over HTTPS 因為走其他特定的 TCP port,應該是不受影響...

AWS 允許 Hybrid Cloud 下的 DNS Query

AWS 對於 Hybrid Cloud (混合雲,通常是講與傳統機房的混搭應用,也就是雲端跟地端的混搭) 推出兩個功能,一個是讓 AWS 的 DNS Resolver 對於某些 domain 可以回機房端查詢 (雲端查詢地端 domain)。另外一種是反過來,讓機房端的 DNS Resolver 可以查 AWS 這邊的資料 (地端查詢雲端 domain):「New – Amazon Route 53 Resolver for Hybrid Clouds」。

兩者都可以自己幹,但就得花功夫自己架設,而且有很多細節得處理:

  • 建立 EC2 instance,在上面跑 Unbound,然後 EC2 instance 的 DNS servers 設定要指到這邊。
  • 由於 EC2 的 DHCP 服務沒有辦法指定發放的 IP range,所以為了多重意外而中獎 (關機的時候剛好有其他機器 DHCP 拿到這組 IP),需要開獨立的 subnet 只放固定 IP 的服務。
  • 為了系統的穩定性,需要在兩個不同 AZ (或是三個) 架設這些 DNS Resolver,所以對應有兩個或是三個 subnet 得建立。

而地端到雲端通常會簡單一些,因為地端通常都已經有內部的 DNS Resolver 可以用,通常只需要在雲上面有 proxy 的角色就可以解決。

不過現在這些 AWS 都直接提供了:

常見的區域都可以用:

Hybrid Cloud is available today in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Sydney), Asia Pacific (Tokyo) and Asia Pacific (Singapore), with other commercial regions to follow.

費用的部分不算便宜 (跟自己弄三台 t3.nano 比起來),但畢竟不需要自己管理,而且對於已經有機房的單位應該只是零頭而已:

Route 53 Resolver remains free for DNS queries served within your VPC. Resolver Endpoints use Elastic Network Interfaces (ENIs) costing $0.125 per hour. DNS queries that are resolved by a Conditional Forwarding Rule or a Resolver Endpoint cost $0.40 per million queries up to the first billion and $0.20 per million after that.

在 DHCP 的情境下強制指定 DNS servers

我在 Vultr 上的 Trac 自動開票程式有時候會爛掉,沒把票開出來,把 stderr 輸出到檔案後發現是找不到 hostname:

socket.gaierror: [Errno -3] Temporary failure in name resolution

看了看 /etc/resolv.conf 發現系統使用的 DNS server 設定是透過 DHCP 取得設定的。但 Vultr 只有提供一組 DNS server,當查不到東西時就爆掉了... 所以找了一下,看到「How to override the DHCP-provided nameserver?」這篇,但裡面是用「增加到前面的方式」,跟我想要改成只用 1.1.1.11.0.0.1 不太一樣。

知道目錄後拿關鍵字去 dhclient.conf 的 manpage 裡面找,就可以看到四種設定方式:

        default [ option declaration ] ;
        supersede [ option declaration ] ;
        prepend [ option declaration ] ;
        append [ option declaration ] ;

這四組看名字就大概知道用途了。接下來就是把對應的 interface 查出來以後,用 supersede 就搞定了:

    supersede domain-name-servers 1.1.1.1, 1.0.0.1;

重開機測試可以確認 /etc/resolv.conf 的內容改變了。接下來再來觀察看看還會不會有狀況...

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

都可以考慮看看...

Dnsmasq 的安全性漏洞

Google 這次出手炸的好痛:「Behind the Masq: Yet more DNS, and DHCP, vulnerabilities」。

當需要在 client 端處理 DNS 的事情,有蠻多開發者都會選擇用 Dnsmasq 處理,這次直接拉出七個 CVE (編號 CVE-2017-13704 與 CVE-2016-{14491-14496}),其中三個是 RCE:

看了一下,Ubuntu 也推出更新了,接下來有一堆機器要升級 Dnsmasq... :o

一張網卡上面從 ISP 取得多個 DHCP IP 或是取得多個 PPPoE IP

昨天跟朋友吃飯的時候談到這個問題,回家幫他找一下解法。主要的限制是各 ISP 對單一 mac address 限制分配一個 IP,所以問題只在於要怎麼在 Linux 下的單一網卡建立多個不同的 mac address,後續的就好做了。

主要是參考 Macvlan and IPvlan basics 這篇文章的指令測試。

首先是建立 fakevlan1 (卡號系統會隨機產生),然後啟用他,最後呼叫 dhclient 請 ISP 提供 IP:

# ip link add fakevlan1 link eth1 type macvlan mode bridge
# ifconfig fakevlan1 up
# dhclient fakevlan1

這邊細部沒有處理 routing 的問題 (dhclient 會收到 ISP 提供的各種 routing 與 dns 資訊),看起來可以透過「Can I prevent a default route being added when bringing up an interface?」這邊的方法處理掉。

PPPoE 的方法我相信也類似啦... (手邊沒有 HiNet 線路可以測試 XD)

北都數位 (TaipeiNet) 的網路

在住的地方拉了北都數位的 cable 與網路來用,首先是速度,30M 有跑滿,不知道用的人多了之後會如何:

線路 IP 反解看起來是走遠傳 SEEDNet,而實際 traceroute 也都是走遠傳的骨幹。

首先是 DHCP 的 DNS 設定頗糟糕,居然配出 HiNet 的 168.95.1.1:

螢幕快照 2016-01-22 15.11.18

然後測了老半天,遠傳看起來完全沒有 Akamai Edge?查了一堆站台,不是走香港、日本,不然就是 HiNet 的 Akamai Edge (即使我把 DNS 硬設為 SEEDNet 自己的 DNS resolver),這樣吃國際頻寬不會吃很兇嗎?

之後找時間來看看遠傳的行動網路如何好了,固網這塊感覺好慘...