在 HTTP 基礎上實現 DNS

Velva34Z 8年前發布 | 6K 次閱讀 HTTP 網絡技術

簡介

UDP或TCP所發送的傳統的DNS查詢和響應是沒有加密的。這就很容易被竊聽和受到欺騙（包括基于DNS的互聯網過濾）。從遞歸解析器到客戶端的響應是最易遭受意外或被惡意更改的，而遞歸解析器和權威名稱服務器之間的通信通常需要包含額外的保護。

目前，基于網絡的應用程序必須使用瀏覽器擴展才能利用那些高級的DNS功能，比如 DANE , DNS-SD service discovery , ，甚至可以查看IP地址以外的任何東西。依賴DNSSEC的功能擴展必須要自我驗證，因為瀏覽器和操作系統可能不會（能）驗證DNSSEC。

為了解決這些問題，谷歌的公共DNS提供了一種通過加密的HTTPS進行連接的 DNSSEC驗證方法，這種方法使用的是一種Web友好的API，它不需要對瀏覽器或操作系統進行什么配置或安裝什么擴展。在 HTTPS基礎上實現的 DNS大大提高了客戶和遞歸解析器之間的隱私和安全，并且 DNSSEC 還提供了一種端到端的認證DNS查找。

谷歌公共DNS提供的API可以在 https://dns.google.com/resolve? 找到，同時還提供了一種用戶友好的Web界面 https://dns.google.com/query? 。雖然后者在瀏覽器中可以顯示結果，但相應的API并未實現；要注意不要混淆這兩個網址。

API規范

注意:API還是beta版本，還會有變化。要報告一個錯誤或請求一個新的功能。

所有的API調用都是HTTP GET請求。參數名稱是不區分大小寫的。在有重復參數的情況下，將使用第一個值。使用http: URLs進行API調用是被禁止的（403 Forbidden）。

支持的參數

name

字符串, 需要

唯一需要的參數。它的長度必須在1和 253 之間（忽略一個可選的跟蹤點，如果存在的話）。所有標簽（由點分隔的名稱部分）必須是1到63個字節長。API不支持 escape字符或非 ASCII字符，但它們并沒有被明確地拒絕。國際化域名必須使用 punycode格式（例如， "xn--qxam"而不是"ελ" ）。

類型

字符串，默認：1

RR 類型可以被從1到65535的數字或者是一組規范的字符串（不敏感的字符，比如A或者aaaa）所代替。你可以使用255來進行‘ANY’的查詢，但是你要知道這并不是使用A或者AAAA或者MX記錄代替它去發送查詢（報文）。主域名服務器不需要返回像這樣的查詢（報文）所有的記錄；一些甚至不做出回應，其他的（像 cloudflare.com ）僅僅只返回HINFO。

檢查禁用

布爾型，默認：false

檢查禁用位。使用cd，cd=1，或者cd=true來使DNSSEC驗證失效；使用cd=0，cd=false，或者不使用cd參數來使DNSSEC驗證進行有效的驗證。

edns_client_subnet

字符串, 默認值: 空

表示edns0-client-subnet 選項.格式是帶子網掩碼的IP地址。例如： 1.2.3.4/24,2001:700:300::/48.

如果你出于隱私考慮使用基于HTTPS的DNS，而且不想要你的IP地址的任何一部分為了位置精度而發送到授權域名服務器，就讓 edns_client_subnet=0.0.0.0/0。谷歌公用DNS通常會發送粗略的網絡信息（通常將你IPv4地址的最后一部分歸零）。

random_padding

字符串, 忽略

這項參數的值被忽略，例如: XmkMw~o_mgP2pf.gpw-Oi5dK.

API 客戶端關注可能的利用HTTPS的報文大小的旁信道隱私攻擊。GET請求可以利用這一點通過填充隨機數據來讓所有請求變成同樣大小。要防止URL的誤解析，需要將填充字符限制到未限制的URL字符：大寫或小寫字母，數字，連字符，句號，下劃線和波浪號。

JSON格式的DNS響應

下面是一個成功的響應 (這里添加的注釋在實際的響應中不會出現):

{
  "Status": 0,  // 沒有錯誤（NOERROR） - 標準的DNS響應代碼(32位整數).
  "TC": false,  // 響應是否有刪減
  "RD": true,   // 對于Google公共DNS來說，總為真
  "RA": true,   // 對于Google公共DNS來說，總為真   
  "AD": false,  // 是否需要用DNSSEC驗證所有的響應數據
  "CD": false,  // 是否要求客戶端禁止使用DNSSEC
  "Question":
  [
    {
      "name": "apple.com.",  // 結尾帶有一個點的完全限定域名（FQDN）
      "type": 1              // A - 標準的DNS RR類型
    }
  ],
  "Answer":
  [
    {
      "name": "apple.com.",   // 總是和Question部分中的name相同
      "type": 1,              // A - 標準的DNS RR類型
      "TTL": 3599,            // 記錄的生命周期秒數
      "data": "17.178.96.59"  // A的數據 - IP地址
    },
    {
      "name": "apple.com.",
      "type": 1,
      "TTL": 3599,
      "data": "17.172.224.47"
    },
    {
      "name": "apple.com.",
      "type": 1,
      "TTL": 3599,
      "data": "17.142.160.59"
    }
  ],
  "Additional": [ ],
  "edns_client_subnet": "12.34.56.78/0"  // IP地址 / 掩碼長度 
}

參見EDNS客戶子網 RFC draft 以了解更多有關“掩碼長度”的細節以及它對緩存有何影響。

下面是提供了診斷信息的失敗響應:

{
  "Status": 2,  // 服務失敗(SERVFAIL) - 標準的DNS響應代碼(32位整數).
  "TC": false,  // 響應是否有刪減
  "RD": true,   // 對于Google公共DNS來說，總為真
  "RA": true,   // 對于Google公共DNS來說，總為真
  "AD": false,  // 是否需要DNSSEC驗證所有的響應數據
  "CD": false,  // 是否要求客戶端禁止使用DNSSEC
  "Question":
  [
    {
      "name": "dnssec-failed.org.",  // 結尾帶有一個點的完全限定域名（FQDN）
      "type": 1                      // A - 標準的DNS RR類型
    }
  ],
  "Comment": "DNSSEC validation failure. Please check http://dnsviz.net/d/dnssec-failed.org/dnssec/."
}

內部引用SPF和TXT記錄的域名服務器屬性如下：

{
  "Status": 0,  // 無錯誤 - 標準DNS響應碼（32位整數）
  "TC": false,  // 響應是否有刪減
  "RD": true,   // 對于Google公共DNS來說，總為真
  "RA": true,   // 對于Google公共DNS來說，總為真
  "AD": false,  // 是否需要DNSSEC驗證所有的響應數據
  "CD": false,  // 是否要求客戶端禁止使用DNSSEC
  "Question": [
    {
      "name": "*.dns-example.info.",  // 結尾帶有一個完全限定域名（FQDN）
      "type": 99                      // SPF - 標準 DNS RR 類型
    }
  ],
  "Answer": [
    {
      "name": "*.dns-example.info.",   //總是Question的機器名
      "type": 99,                      // SPF - 標準 DNS RR 類型
      "TTL": 21599,                    // 記錄的生命周期秒數
      "data": "\"v=spf1 -all\""        // SPF的具體數據 - 引用的字符串
    }
  ],
  "Comment": "Response from 216.239.38.110"
  //由認證域名服務器返回的無緩存響應
}
{
  "Status": 0,  // 無錯誤 - 標準DNS響應碼（32位整數）
  "TC": false,  //  響應是否有刪減
  "RD": true,   //對于Google公共DNS來說，總為真
  "RA": true,   // 對于Google公共DNS來說，總為真
  "AD": false,  // 是否需要DNSSEC驗證所有的響應數據
  "CD": false,  //  是否要求客戶端禁止使用DNSSEC
  "Question": [
    {
      "name": "s1024._domainkey.yahoo.com.", // 結尾帶有一個完全限定域名（FQDN）
      "type": 16                             // TXT - 標準 DNS RR 類型
    }
  ],
  "Answer": [
    {
      "name": "s1024._domainkey.yahoo.com.", // 總是Question的機器名
      "type": 16,                            // TXT - 標準 DNS RR 類型
      "data": "\"k=rsa;  p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrEee0Ri4Juz+QfiWYui/E9UGSXau/2P8LjnTD8V4Unn+2FAZVGE3kL23bzeoULYv4PeleB3gfm\"\"JiDJOKU3Ns5L4KJAUUHjFwDebt0NP+sBK0VKeTATL2Yr/S3bT/xhy+1xtj4RkdV7fVxTn56Lb4udUnwuxK4V5b5PdOKj/+XcwIDAQAB; n=A 1024 bit key;\""
      //TXT的具體數據 - 多行引用字符串 
    }
  ],
}

"Master file" 中對RRs（TXT和SPF）類型格式要求雙引號，并且需要避開JSON的雙引號字符串。

單個字符串限制是255字節,而類似yahoo.com DKIM 的長TXT類型的記錄包含多個字符串的情況需要每個字符串分開處理.

許多使用長TXT類型記錄，例如RFC 4408 (SPF) 或 RFC 4871 (DKIM)格式要求將多個串聯字符串按照一個TXT或者SPF記錄對待，但是通常不會需要進行這個處理。

注意：盡管HTTP不截斷，我們也可能得到一個從認證域名服務器返回的被截斷的響應。所以我們需要在響應中包含TC標志位。

注意：考慮到HTTP消息沒有大小限制，我們通常不需要EDNS機制

唯一有意義的ENDS選項（即edns-client-subnet）是一個請求參數和JSON響應中的頂級屬性。

來自：https://www.oschina.net/translate/dns-over-https

本文由用戶 Velva34Z 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1476347744532.html

HTTP 網絡技術

在 HTTP 基礎上實現 DNS

簡介

API規范

支持的參數

name

JSON格式的DNS響應

相關經驗

相關資訊

相關文檔

目錄