工程趣聞 2026 年 8 月 9 日

2026-08-09 — DNS 新增 _for-sale TXT 節點讓網域免停站公告求售,同時一篇部落格文章反駁「寫程式從來不是難的部分」的流行說法

primary=https://specification.website/spec/foundations/for-sale-dns/ primary=https://www.rfc-editor.org/rfc/rfc10023.html primary=https://blog.senko.net/code-was-never-the-hard-part-is-an-insult-to-all-programmers primary=https://gruhn.me/blog/2026-08-03/ primary=https://koushikdasika.com/blog/coding-was-never-the-hard-part/ primary=https://joereis.substack.com/p/code-wasnt-the-hard-part-keep-building

想賣網域不用停站:DNS 新增 _for-sale 節點,一筆 TXT record 公告求售

specification.website · 2026-08-08

2026 年 8 月 8 日,技術規格網站 specification.website 刊出一份名為《_for-sale DNS Records》的規格文件,定義了 _for-sale 這個 DNS 節點名稱,讓網域擁有者能透過一筆 TXT record 對外宣告「這個網域正在出售」,而網站與服務可以照常運作,不必掛出停用頁或把網域轉交給仲介商代管。這份規格對應到 IETF 在 2026 年 7 月發布的 RFC 10023《The "_for-sale" Underscored and Globally Scoped DNS Node Name》,作者是 SIDN Labs 的 M. Davids,屬於 Informational 等級文件,不是強制標準。

規格細節

規格把宣告動作放在網域下的 _for-sale 這個 leaf node,查詢時只要對 _for-sale.example.comTXT record 就能讀到內容。每一筆 record 都必須以版本標籤 v=FORSALE1; 開頭,如果整個 RRset 裡沒有任何一筆帶著合法版本標籤,解析端就得把這個節點視為無效並忽略。這種「underscored 節點」的作法沿用 RFC 8552 訂下的慣例,和 DKIM、ACME 驗證使用的命名邏輯是同一套。

版本標籤後面接的是 tag=value 格式的內容,規格定義了四種標籤,一筆 record 只能帶一組:

  • ftxt= 自由格式的人類可讀文字說明
  • furi= 聯絡窗口或詳細資訊網址
  • fval= 開價金額,格式為幣別代碼加數字(例如 USD12500)
  • fcod= 需要雙方事先約定的專屬代碼
_for-sale IN TXT "v=FORSALE1;furi=https://example.com/for-sale"
_for-sale IN TXT "v=FORSALE1;ftxt=Serious offers only"
_for-sale IN TXT "v=FORSALE1;furi=https://example.com/fs?d=eHl6"
_for-sale IN TXT "v=FORSALE1;fval=USD12500"

單一 character-string 上限是 255 bytes,建議 TTL 不超過 3600 秒,同一個 RRset 裡可以放多筆 record,但每筆只能帶一組 tag-value。規格也限定這個節點只在 zone leaf 生效,.arpa 底下的同名節點一律忽略,避免被誤用在反解區。

影響範圍

因為是 Informational 而非強制標準,採不採用完全看網域擁有者、掛牌平台跟解析工具願不願意支援。規格頁面本身只附了 dig +short TXT _for-sale.example.com 當作驗證指令,顯示目前設計重點在「讓機器讀得到」,而不是綁定特定登錄商或仲介平台——目前沒有找到任何 registrar 已正式支援這個紀錄類型,也沒有公開的參考實作。這代表短期內它比較像是給網域仲介、爬蟲和自動化服務先行遵守的公開慣例,而非馬上能在多數 DNS 控制台按幾下就設定完成的功能。

規格頁面另外連到站內一頁 DNSSEC 相關說明,暗示這類公開宣告紀錄如果沒有簽章保護,理論上可能被第三方竄改或偽造求售訊息。規格本身並未強制要求部署 DNSSEC,只把它列為延伸閱讀,等於把安全性的取捨留給實際佈署的一方自行判斷。

原始來源:specification.website 規格頁RFC 10023


「程式從來不是難的部分」為什麼讓工程師光火?Senko Rašić 正面反駁

senko.net · 2026-08-09

2026 年 8 月 9 日,工程師 Senko Rašić 在自己的部落格發表文章,標題直接開嗆〈"Code was never the hard part" is an insult to all programmers〉。他鎖定的是 AI 寫程式討論圈裡反覆出現的一句話——「寫程式很簡單,搞懂到底要做什麼才是真正困難的部分」,認為這句話同時貶低了工程師與負責釐清需求的人兩種專業。這句台詞不只一人在講,Koushik DasikaJoe Reis 都曾用幾乎一模一樣的標題發文,顯示它已經是討論區裡的固定台詞。

原本的論點

這句流傳說法背後的邏輯是,LLM 讓「把想法變成程式碼」這件事幾乎零成本,語法細節與除錯技巧因此不再稀缺;真正值錢的變成「知道要做什麼」——理解需求、拆解問題、判斷優先順序。Rašić 在文中連到 Niklas Gruhn 的 〈Don't be a meat proxy〉,裡面有類似的描述:把 ticket 說明複製貼上進 Claude Code,幾乎零努力就能生出一些程式碼。這呼應了「產出程式碼已經很廉價」這個前提,只是 Gruhn 原文談的其實是別把 AI 輸出原封不動轉發給別人,重點在人的判斷力,不在貶低寫程式本身。

反駁的邏輯

Rašić 的第一條反駁路線針對「寫程式很簡單」本身:他反問,如果寫程式真的簡單,為什麼工程師多年來能拿到高薪、得經歷嚴格的面試流程、還得投入長時間訓練?他也指出《Clean Code》、《The Pragmatic Programmer》這類書籍存在本身,就說明這門技藝沒有表面上看起來那麼容易。他把這種說法當成對所有寫過正式產品程式碼的人的一種輕視。

第二條路線針對「搞懂需求才是難的」這句話:他認為如果決定要做什麼才是真正困難、也才是真正值錢的工作,那產品經理、業務分析師的地位與待遇應該高過工程師,但現實並非如此。他同時舉出 John Carmack、Fabrice Bellard 這類公認技術能力極強的工程師,說明「寫程式的技藝」本身仍然能造成決定性差異,不是隨便誰接上 LLM 就能取代。他最後把立場收在兩者都難、都值得長期琢磨,而不是把其中一項說成可有可無。

原始來源:Senko Rašić 原文Niklas Gruhn〈Don't be a meat proxy〉

End of article
0
Would love your thoughts, please comment.x
()
x