# DNS Operations

### References

+ 📄 [**IETF 121 Dublin**](https://docs.google.com/document/d/1FM8o2V7OxxkEh4LJFAhM9SB9T6vmfmAShuamjXMm9XE)
+ 📄 [**Notion: DNS**](https://rogeliokg.notion.site/DNS-142fe0809ab680d59f1fc0916d11013e?pvs=4)
+ 📄 [**DNSSEC Algorithm Numbers**](https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml)
+ 🎬 [**IETF 121: Domain Name System Operations (DNSOP) 2024-11-07 17:30**](https://youtu.be/ODhjo8u1btw)
+ 🎬 [**DNSSec Explained**](https://youtu.be/_8M_vuFcdZU)
+ 🔗 [**agenda-121-dnsop-02**](https://datatracker.ietf.org/meeting/121/materials/agenda-121-dnsop-02)
+ 🔗 [**DNS Hacking 之 基礎知識：DNS 運作與紀錄類型**](https://tech-blog.cymetrics.io/posts/crystal/dns-hacking-1/)
+ 🔗 [**DNS Hacking 之 電話簿攻防之術：DNSSEC、DoT/DoH**](https://tech-blog.cymetrics.io/posts/crystal/dns-hacking-2/)
+ 🔗 [**DNS Hacking 之 Subdomain Enumeration 的技巧與自動化挖掘**](https://tech-blog.cymetrics.io/posts/crystal/dns-hacking-3/)
+ 🔗 [**root signing ceremony**](https://www.cloudflare.com/zh-tw/learning/dns/dnssec/root-signing-ceremony/)
+ ⚒️ [**sha1-online.com**](http://www.sha1-online.com/)

### 1. [Integration of DNS Domain Names into Application Environments: Motivations and Considerations][1]

#### DNS integration

讓 DNS 可以和軟體服務整合 (作為軟體服務的一環提供)，
比如說讓使用者可以使用 domain name 來作為他們的 identifier。

#### Draft

responsive DNS integration

#### Case Study

+ **BlueSky**
[BlueSky] 是一個 social media，採用 AT Protocol (他們自己設計的一套協議)，
使用者能使用 domain name 來作為他們的 identifier。
`rogeliolg.bsky.social` -> `https://bsky.app/profile/rogeliokg.bsky.social`

+ **AT Protocol**

+ **身份管理**
<mark>去中心化 ID</mark>（DID, Decentralized Identifiers）
<mark>每個使用者都有一個唯一的 DID</mark>，
例如 `did:web:example.com` 或 `did:plc:unique-string`。
<mark>這些 ID 獨立於任何特定平台</mark>，確保使用者的身份無法被單一服務控制或剝奪。

+ **DNS 集成**
使用者可以將自己的域名 (如 `@mydomain.com`) 綁定到身份上，
並通過 DNS 進行驗證，確保身份的可追溯性和唯一性。

+ **可遷移性**
使用者擁有對其數據的完全控制權，包括貼文、粉絲、關注關係等。
使用者可以隨時將數據導出並遷移到其他兼容 AT 協議的服務，而不會丟失訊息。

#### Challenges & Prospects
+ **挑戰**
+ **同步問題**
每個 domain name 都有自己的生命週期，如何在一個 domain name 過期、轉移時迅速地更動相關的 DNS record 是一大挑戰。
+ **展望**
+ **簡化管理**
在動態環境 (比如 cloud platform、container app 等) 中，DNS record 能夠隨著基礎設施的變動自動更新，可以避免手動操作的繁瑣。

### 2. [Addition of Extended DNS Errors codes][2]

#### Prerequisite

+ first come first served
IANA 對許多編碼類型的分配採用簡單的優先申請政策，任何開發者或組織都可以提出申請，只要符合基本格式要求，並且該代碼尚未被使用，就會分配給申請者。
這降低了設計和實現門檻，鼓勵創新，但也可能導致代碼表變得雜亂或重複，特別是在語義過於具體或模糊時。

+ **[RFC 8914]**: Extended DNS Errors (EDE)
...

+ **[RFC 8482]**: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
RFC 8482 定義的 HINFO 錯誤碼
當 DNS 伺服器配置為最小化響應時，可能不會提供詳細的錯誤描述，而是簡單返回「無法處理查詢」的最小必要資訊。這樣做可以保護伺服器配置資訊並節省資源。

+ **[RFC 8806]**: Running a Root Server Local to a Resolver
一種特定的 DNS 配置方法。讓 DNS 運營商可以在其本地運行一個 root server，以提高 DNS 查詢的性能和可靠性。

#### Draft

因為 Extended DNS Errors (EDE) 採用 first come first serve 原則，
他其實可以單純向 IANA 申請就好，不用寫成正式文件這麼嚴格，
但他想放出他的 idea 讓大家討論。

+ **新增三個 EDE code**
+ **ECS code**
表示回應因 ECS (EDNS Client Subnet) 調整。
使用場合：authoritative DNS server 或 DNS resolver。
問題討論：若 DNS resolver 接收到此代碼，是否應將其傳遞給使用者端？此代碼是否也可涵蓋其他基於負載平衡的調整？

+ **minimum response code**
表示針對 ANY 查詢的回應被故意簡化 ([RFC 8482])。
使用場合：authoritative DNS server 或 DNS resolver。
問題討論：是否可擴展至其他節省流量的情境 (例如不傳遞 glue 資訊)？

+ **local route code**
表示回應來自本地 root server ([RFC 8806])。
使用場合：使用本地 root server 的 DNS resolver。

#### Challenges & Prospects

+ **挑戰**
目前已有類似方案
已經有其他類似的特殊用途 TLD（例如 ".local", ".alt" 等），
這些域名也是處理內網問題。要如何讓 ".internal" 和這些現有方案區分開來，而且還能獲得廣泛接受，是一個挑戰。
+ **展望**
內網的高效管理
這表示企業對內部 DNS 系統有需求。而隨著雲端計算和分散式網路架構的發展，越來越多的企業可能會尋求這種標準化方案來簡化內部 domain name 管理。這將有助於內網的統一和規範化。

### 3. [A Top-level Domain for Private Use][3]

#### Prerequisite

+ **[RFC 1918]**: Address Allocation for Private Internets
private IP

#### Draft

為了防止內網 IP 地址衝突，
講者想設計一個專門給內網用的 TLD `.internal`。
其不會在公共 DNS 被 resolve。

#### Challenges & Prospects
+ **挑戰**
+ **目前已有類似方案**
已經有其他類似的特殊用途 TLD（例如 ".local", ".alt" 等），
這些域名也是處理內網問題。要如何讓 ".internal" 和這些現有方案區分開來，而且還能獲得廣泛接受，是一個挑戰。
+ **展望**
+ **內網的高效管理**
這表示企業對內部 DNS 系統有需求。而隨著雲端計算和分散式網路架構的發展，越來越多的企業可能會尋求這種標準化方案來簡化內部 domain name 管理。這將有助於內網的統一和規範化。

### 4. [Upper limit values for DNS][4]

#### Draft
+ DNS 中，有些參數並沒有明確的上限
+ RRset 中 record 的上限數量
+ type RRSIG 的上限數量？
> 註：RRSIG 是 RRset 的簽章
+ type DS 的上限數量？
> 註：DS 是在上層中，hash 下層 zone KSK public key 的 DNSKEY 記錄產生
+ type CNAME 的上限數量？
+ type DNAME 的上限數量？
> 註：DNAME 是將 subdomain name 映射到 domain name

+ 沒有上限的話會發生啥事
+ DNS server 容易遭到
+ DoS 攻擊
> 只需要在某個 zone 裡面準備一條長到不行的 CNAME chain
> 或者超大的 RRSet 即可。
+ [KeyTrap]
> 簡單來說就是一個惡意的 DNS server，它可以傳送某種惡意的 DNSSEC signature，讓 DNS resolver 需要花上很長一段 CPU 時間去解析 signature。

+ DNS packet size limit
+ 使用 UDP 有 512 Bytes 上限，使用 TCP 有 65535 Bytes 上限
> 一方面講者可能是覺得 TCP 的 65535 Bytes 有點太大 (很好做攻擊)，
> 另一方面 UDP 的 512 他覺得太小，應該要 1400 Bytes 左右 (unfragmented UDP)

+ RRset 中 record 的上限數量
> 他覺得一個 RRSet 裡面的 records 數量應該要 <= 13

+ 關於 DNSSEC (DNSKEY, DS, RRSIG)
+ 之所以有 KeyTrap 的漏洞可鑽，就是因為 DNSKEY, DS, RRSIG 這些 RRset 沒有設定 record 上限
+ DNSKEY
> 講者考慮到 DNSKEY (+2) 的輪替 (rollover, +1x2) 問題和 Multi-Signer models (+1x2)，認為 DNSKEY 的上限可以壓在 6
+ DS
> 他覺得最大是 3
+ 一個 RRset 能有幾個 RRSIG
> [Unbound] 預設 8
> 他覺得最大 2 就好 (然後 DNSKEY 的 RRSIG 他覺得是 3)

+ CNAME alias levels (別名鏈多長)
+ 大部分的 resolver 實作都能撐住 10 個 CNAME 長的別名鏈
> Unbound 預設 11
> 他覺得理想是 1 (是個狠人)
> 不過他也知道目前蠻多網域是有 3 個 CNAME 長的別名鏈

+ 使用 in-domain nameserver
(相對於 unrelated nameserver，減少 name resolution cost 和 error)

+ unrelated nameserver (bad)

      Domain:
        rogeliokg.com
      Name Servers:
        ns1.dns-parking.com
        ns2.dns-parking.com

+ in-domain nameserver (good)

      Domain:
        cloudflare.com
      Name Servers:
        ns3.cloudflare.com
        ns4.cloudflare.com
        ns5.cloudflare.com
        ns6.cloudflare.com
        ns7.cloudflare.com

#### Challenges & Prospects
+ **挑戰**
+ **過度限制的風險**
設定過低的上限值可能會限制 DNS 的靈活性和可擴展性，
尤其是對於一些特殊的需求 (例如大規模域名系統) 來說，過低的限制在這些情況下，可能反而會導致更低的運行效率。
+ **協議本身的變化**
隨著 DNS 協議的不斷發展，未來可能會出現與當前上限值不兼容的情況，這會要求這項草案要能夠靈活調整，以便適應新協議的特性。
+ **展望**
+ **修正 DNSSEC 的痛點**
這項草案提出的方案針對 DNSSEC 的痛點做了不少補強，兩相結合之下可以加強 DNSSEC 的安全性。

[1]: https://datatracker.ietf.org/doc/draft-sheth-dns-integration/
[2]: https://datatracker.ietf.org/doc/draft-bortzmeyer-more-edes/
[3]: https://datatracker.ietf.org/doc/draft-davies-internal-tld/
[4]: https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-dns-upper-limit-values/

[BlueSky]: https://bsky.social/about/blog/4-28-2023-domain-handle-tutorial
[RFC 1918]: https://www.rfc-editor.org/rfc/rfc1918.html
[RFC 8914]: https://www.rfc-editor.org/rfc/rfc8914.html
[RFC 8482]: https://www.rfc-editor.org/rfc/rfc8482.html
[RFC 8806]: https://www.rfc-editor.org/rfc/rfc8806.html
[Unbound]: https://www.nlnetlabs.nl/projects/unbound/about/
[KeyTrap]: https://www.ithome.com.tw/news/161286