Ptt 信件伺服器 node.ptt.cc 查不到反解的問題

就如同標題所說的,Ptt 對外寄信的伺服器 node.ptt.cc 查不到反解的問題:

$ host node.ptt.cc
node.ptt.cc has address 140.112.172.16
$ host 140.112.172.16
Host 16.172.112.140.in-addr.arpa not found: 2(SERVFAIL)

情況大概是這樣,Ptt 使用的 140.112.172.0/27 這個網段 (尾碼從 0~31) 不是 /24 以上的範圍,而 140.112.172.0/24 是台大計中管轄範圍,所以台大就把 140.112.172.x 這段的反解 PTR record 用 CNAME 的方式指到 x.0-31.172.112.140.in-addr.arpa,像是 140.112.172.16 這樣:

;; ANSWER SECTION:
16.172.112.140.in-addr.arpa. 86400 IN   CNAME   16.0-31.172.112.140.in-addr.arpa.

然後再針對 0-31.172.112.140.in-addr.arpa 設定 NS RR 到 ns0.ptt.ccns1.ptt.cc 兩台 NS server:

;; AUTHORITY SECTION:
0-31.172.112.140.in-addr.arpa. 86400 IN NS      ns1.ptt.cc.
0-31.172.112.140.in-addr.arpa. 86400 IN NS      ns0.ptt.cc.

但是 ns0.ptt.ccns1.ptt.cc 都不見了:

$ host ns0.ptt.cc
Host ns0.ptt.cc not found: 3(NXDOMAIN)
$ host ns1.ptt.cc
Host ns1.ptt.cc not found: 3(NXDOMAIN)

導致反解查不到對應的資料 (會是 SERVFAIL):

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58463

猜了一下,看起來 ns0.ptt.cc 還活著,只是 Cloudflare 上面的 DNS record 沒設定過去:

$ dig ns0.ptt.cc @140.112.172.16

;; ANSWER SECTION:
ns0.ptt.cc.             300     IN      A       140.112.172.16

不過 ns1.ptt.cc (140.112.172.10) 看起來就沒服務了,但至少在 Cloudflare 上補個 DNS record 上去應該就會動了 (只是沒有兩台互相備援)。

Cloudflare 預定推出 SSH command logging 功能

Cloudflare 預定要推出 SSH command logging 功能:「Introducing SSH command logging」。

看起來是 Cloudflare Zero Trust 產品線:

We’re excited to announce SSH command logging as part of Cloudflare Zero Trust.

翻了 Zero Trust 的 Pricing 資訊,Free Plan 看起來是 50 users 以下不用錢,但不確定這個功能會被放到 Core Features 內還是會被放到另外要收費的部份。

早在 AWS 在 2016 年的時候有用 script 整合了一個方案出來,裡面提到的方法不限於 AWS 上才能用:「How to Record SSH Sessions Established Through a Bastion Host」。

翻了一下 open source 專案,看起來有一些 open source 方案可以用:

另外這個需求在資安要求比較高的行業算是很常見,非 open source 的方案就有不少,先隨便抓兩個:

Route 53 支援 DNS64,以及 NAT Gateway 支援 NAT64

AWS 宣佈了一套機制,讓 IPv6-only 的機器可以連到 IPv4-only 的服務:「Let Your IPv6-only Workloads Connect to IPv4 Services」。

首先是 DNS64,針對只有 IPv4-only 的 A record 自動加上 AAAA record (如果已經有 AAAA record 的則不變),這邊提到的 64:ff9b::/96 是來自 DNS64 標準內的規範:

The DNS resolver first checks if the record contains an IPv6 address (AAAA record). If it does, the IPv6 address is returned. The IPv6 host can connect to the service using just IPv6. When the record only contains an IPv4 address, the Route 53 resolver synthesizes an IPv6 address by prepending the well-known 64:ff9b::/96 prefix to the IPv4 address.

再來就是 NAT Gateway 可以把 64:ff9b::/96 透過 NAT64 轉到 IPv4 network 上:

You may configure subnet routing to send all packets starting with 64:ff9b::/96 to the NAT gateway. The NAT gateway recognizes the IPv6 address prefix, extracts the IPv4 address from it, and initiates an IPv4 connection to the destination. As usual, the source IPv4 address is the IPv4 address of the NAT gateway itself.

由於有些 protocol 會帶 IP address 資訊,所以不能保證 NAT64 一定會動,但大多數的情況應該是可以解決,至少提供了 IPv6-only server 連到 IPv4-only network 上的方法...

連安裝 Windows 95 都可以 Speedrun...

看到「Speedrunning Windows 95」這篇,連裝 Windows 95 都可以有 speedrun:

Now, there’s a world record speedrun, installing Windows 95B in just 1 minute 10.9 seconds.

可以看到是在 VirtualBox 裡面裝的,這樣看起來也跟電腦速度有關... (把所有東西都塞到 memory 裡面?)

SMTP 的強加密連線機制

RFC 8461 成為正式標準 (Standards Track),描述 Mail server 到 mail server 之間的強加密連線機制:「SMTP MTA Strict Transport Security (MTA-STS)」。

Policy 設定的方法有好幾種:

第一種是透過 _mta-stsTXT record 設定,這點通常會配合 DNSSEC 確保 DNS 的查詢沒有被改。

第二種是透過 HTTPS 在某個特定的 host (mta-sts) 取得 policy 檔案。像是對 example.com 的資料會從 https://mta-sts.example.com/.well-known/mta-sts.txt 取得。

第三種是透過 HTTPS 的 certificate 裡面帶 mta-sts 資訊出來。

不只有 DNS 可以設定,使得整個架構變得有點複雜...

Cloudflare 的 DNS Resolver 也提供 Purge 功能了

Cloudflare 提供的 1.1.1.11.0.0.1 也提供 purge 功能了,在 https://cloudflare-dns.com/purge-cache/ 這邊:「Refresh Stale DNS Records on 1.1.1.1」。

Google 的類似:「Flush Cache | Public DNS | Google Developers」。不小心弄錯東西,有需要 purge 的時候還蠻方便的...

SSH 的 SSHFP record

很久前看過 SSHFPT record,當時支援度不高就忘記了... 剛剛在 Cloudflare 的這篇「Additional Record Types Available with Cloudflare DNS」看到發現 OpenSSH 很久前就有支援了...

用法是 VerifyHostKeyDNS 這個 option,像是 ssh -o "VerifyHostKeyDNS=yes" -o "StrictHostKeyChecking=yes" hostname 這樣的指令,對於 ~/.ssh/known_hosts 裡沒有的機器,在第一次連線的時候會去查 DNS record,如果沒有查到的話就會中斷。

產生 SSHFP record 的方式則是可以參考「How do I generate SSHFP records?」這篇,也就是直接用 sshkey-gen -r [hostname],程式就會去讀 /etc/ssh/ 下的資料產生了。

ORM 常見的效能問題

在「How not to structure your database-backed web applications: a study of performance bugs in the wild」這邊看到的,裡面提到的論文是以 Rails 的 ActiveRecord 分析,不過概念上還算通用...

重點在最後一張 (Table 7 那張):

看一下在腦裡留個印象,之後遇到的時候至少大概知道怎麼查...

台固的網域名稱轉出到 Gandi,以及 GDPR...

看到 othree 的「TFN 域名轉出」這篇,剛好前陣子把 git.tw 也轉到 Gandi 上,也遇到一樣的問題... 以往的經驗是網域註冊商會提供 authorization code,但台固的系統是讓你自己輸入,懂這點後就好處理了:

所以結論是,TFN 域名轉出時要輸入的移轉中密碼其實就是給使用者自訂 authorization code,而且還有個蠻短的長度限制 XD

另外是因為 GDPR 所以看不到 whois 資料了,像是 othree 提到的 markdown.tw

gslin@GSLIN-HOME [~] [14:32/W2] whois markdown.tw
Domain Name: markdown.tw
   Domain Status: clientTransferProhibited
   Registrant:
      
      Not displayed due to GDPR
      FR

   Administrative Contact:
      Not displayed due to GDPR

   Technical Contact:
      Not displayed due to GDPR

   Record expires on 2020-03-07 (YYYY-MM-DD)
   Record created on 2011-03-07 (YYYY-MM-DD)

   Domain servers in listed order:
      ns-171-a.gandi.net      
      ns-114-b.gandi.net      
      ns-144-c.gandi.net      

Registration Service Provider: GANDI SAS

我自己的 git.tw 也是:

gslin@GSLIN-HOME [~] [14:34/W2] whois git.tw
Domain Name: git.tw
   Domain Status: clientTransferProhibited
   Registrant:
      
      Not displayed due to GDPR
      FR

   Administrative Contact:
      Not displayed due to GDPR

   Technical Contact:
      Not displayed due to GDPR

   Record expires on 2019-05-23 (YYYY-MM-DD)
   Record created on 2008-05-23 (YYYY-MM-DD)

   Domain servers in listed order:
      kristin.ns.cloudflare.com      
      paul.ns.cloudflare.com         

Registration Service Provider: GANDI SAS

這樣就有點麻煩了,以後如果要聯絡的話只剩下 DNS 內的 SOA record

GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務

以往在 GitHub 上如果要使用 HTTPS 只能使用 *.github.io 網域,現在 GitHub 宣佈透過 Let's Encrypt 的服務支援了:「Custom domains on GitHub Pages gain support for HTTPS」:

We have partnered with the certificate authority Let’s Encrypt on this project. As supporters of Let’s Encrypt’s mission to make the web more secure for everyone, we’ve officially become Silver-level sponsors of the initiative.

不過目前只支援 CNAME record (標準) 或是 ALIAS record 的方式 (非標準,也稱為 ANAME,有些 DNS provider 有支援,主要用在網域本身 (i.e. root domain) 無法使用 CNAME)。

如果是使用 A record,則是需要更新 IP 位置:

If you are using A records, you must update your site’s DNS records with new IP addresses. Please see our guide to setting up your custom domain with Pages and update any A records you might have set.

另外也提供 HTTP 轉 HTTPS 的選項:

以前 HTTPS 還得自己弄伺服器處理,現在可以直接往 GitHub 上丟了...

另外用查出來的 IP 看了一下架構,IP 是 Fastly 的,所以應該是跟 Fastly 合作,但不確定是 Fastly 自己搞定 Let's Encrypt 的憑證,或是 Fastly 提供 Port 80/443 的 TCP Proxy?