CNC ?記錄類型?A ?記錄??又稱IP 指向，用戶可以設置本身和子域名到木標主機地址上，從而實現(xiàn)通過域名找到服務器。?說明：?1）指向的目標主機地址類型只能使用IP 地址；?2）泛域名解析，即將該

CNC ?

記錄類型?

A ?記錄??

又稱IP 指向，用戶可以設置本身和子域名到木標主機地址上，從而實現(xiàn)通過域名找到服務器。?

說明：?

1）指向的目標主機地址類型只能使用IP 地址；?

2）泛域名解析，即將該域名所有未指定的子域名都指向一個空間?

3）當相同子域名有多個目標地址時，表示輪循

CNAME ??

通常稱別名指向. ?

說明：?

1）CNAME 的目標主機地址只能使用域名，不能使用IP 地址；?

2）域名前不能有任何其他前綴，如：http://等是不被允許的；?

3）A 記錄優(yōu)先于CNAME 記錄。即如果一個主機地址同時存在A 記錄和CNAME 記錄，則CNAME 記錄不生效。?

????4）空主機頭不能進行CNAME 。?

NS 記錄?

解析服務器記錄。用來表明由哪臺服務器對該域名進行解析。這里的NS 記錄只對子域名生效。

說明：

·“優(yōu)先級”中的數(shù)字越小表示級別越高；

·NS記錄可以填寫IP 地址，也可以填寫像ns1.lxdns.com 這樣的域名，但必須保證該域名有效。如，將www.abc .com.lxdns.com 的NS 記錄指向到ns1.lxdns.com ，在設置NS 記錄的同時還需要設置ns1.lxdns.com 的 指向，否則NS 記錄將無法正常解析； ·NS 記錄優(yōu)先于A 記錄。即，如果一個主機地址同時存在NS 記錄和A 記錄，則A 記錄不生效。這里的NS 記錄只對子域名生效。

郵件交換記錄MX

用于將以該域名為結尾的電子郵件指向對應的郵件服務器以進行處理。如：用戶所用的郵件是以域名mydomain.com 為結尾的，則需要添加該域名的MX 記錄來處理所有以@mydomain.com結尾的郵件。

說明：

·MX記錄可以使用主機名或IP 地址；

·MX記錄可以通過設置優(yōu)先級實現(xiàn)主輔服務器設置，“優(yōu)先級”中的數(shù)字越小表示級別越高。也可以使用相同優(yōu)先級達到負載均衡的目的；

當域名的MX 記錄有多個目標地址且優(yōu)先級相同時，表示輪循，可以達到負載均衡的目的

MX 和A 記錄可以并存

TXT 記錄?TXT 記錄，一般指為某個主機名或域名設置的說明。

TXT 記錄的一個重要的作用就是設置SPF 記錄，以防止你的郵件服務器發(fā)送的郵件被當作垃圾郵件。 SPF 是為了防范垃圾郵件而提出來的一種DNS 記錄類型，它是一種TXT 類型的記錄，它用于登記某個域名擁有的用來外發(fā)郵件的所有IP 地址。

按照SPF

的格式在DNS 記錄中增加一條TXT 類型的記錄，將提高該域名的信譽度，同時可以防止垃圾郵件偽造該域的發(fā)件人發(fā)送垃圾郵件。SPF 是跟DNS 相關的一項技術，它的內容寫在DNS 的txt 類型的記錄里面。mx 記錄的作用是給寄信者指明某個域名的郵件服務器有哪些。SPF 的作用跟mx

相反，它向收信者表明，哪些郵件服務器是經過某個域名認可會發(fā)送郵件的。由定義可以看出，SPF 的作用主要是反垃圾郵件，主要針對那些發(fā)信人偽造域名的垃圾郵件。

PTR 記錄????

反向域名解析就是從Ip 地址解析出域名。由于一些門戶網站的免費郵件系統(tǒng)需要對發(fā)送的郵件有個反向域名遞歸查詢的要求，如果反向解析的ip 和郵件包頭的源ip 不一致，則郵件被當作SPAM 被屏蔽掉，所以一般郵件服務器需作反向解析。

?

CNC.SH ?

?

常見問題?

客戶未授權過來。?

51CDN ?

操作和GLB0平臺類似，目前平臺不能直接發(fā)布，需要登錄到機器（192.168.0.81：57891）(賬號密碼均是watch) 目錄/home/expect/2nd ‐external ，然后執(zhí)行腳本手工發(fā)布：?./dx_2nd_61.129.67.223.pl???發(fā)布串?

./wt_2nd_210.192.121.165.pl??發(fā)布串?

發(fā)布時還可以直接用0.60上的/tmp/fabu.pl?腳本進行發(fā)布?

?

View 的個數(shù)也比較少。?

?

目前有2種形式的。?

別名到51cdn.com ?

Ns 記錄到ns1.51cdn.com 和ns2.51cdn.com ???

?

?

?

?

INTDNS 、lxdns 、cdn20?

部署過程?

生成配置?‐>?MD5校驗?‐>配置確認—>部署。?

生成配置：?

生成本次修改所涉及區(qū)域的hosts 文件、named.conf ?.hosts 文件中域名包括本次改動的域名和與修改域名同zone 的其他未改動的域名。?

MD5校驗：?

對本次生成的文件，拿歷史發(fā)布的版本同遠程的DNS 服務器上的文件進行MD5值對比?配置確認:?

確認配置文件并本地發(fā)布?‐>?打包配置文件?‐>?上傳到遠程DNS 服務器??

打包配置文件，這個打包的文件包括遠程部署腳本及dig 腳本，只是為了預防遠程部署腳本有異常，這邊每次都會一起打包，這個文件很小，不影響包的大小?

部署：?

執(zhí)行遠程部署腳本?‐>?部署成功后，在dns 服務器上進行dig 檢驗?

執(zhí)行遠程部署腳本：?

備份本次需要部署的文件?‐>?覆蓋文件?‐>?rndc ?reload ?

部署成功后，在dns 服務器上進行dig 檢驗?

分view ?dig 本次涉及到的頻道，并且是有調整到的區(qū)域，再加上固定dig 的區(qū)域。并且是在dns 服務器上執(zhí)行dig ，并將dig 結果保存成兩文件文件（成功及失敗），然后匯總發(fā)回平臺的機器并反饋到平臺的界面?

?

對于外部二級還要強制dig 網通北京、電信上海、電信廣東???

?

默認TTL ?

內部dns ：默認ttl ?3600s ?

外部一級默認ttl ??3600s ?

外部二級默認ttl ??A ??120s ??CNAME ??600?

?

DNS 集群?

目前外部dns 是由4*5臺?集群 單臺上海移動組成的?

?

集群是lvs dns的形式。?

常見問題?

1、 Md5校驗失敗?

Dns 機器上的文件的md5值與歷史發(fā)布版本的md5值不一致?？赡艹霈F(xiàn)md5校驗失敗的原因：?

1、 機器故障后恢復等原因補充部署，因為不需要部署所有的機器，所以導致線上的dns 服務器配置內容是一致的，僅僅序列號有差別。?

2、 Boss 平臺升級涉及到dns 部署功能的時候，會找一臺機器進行驗證部署，這時其他機器的配置也是對的，只是序列號不同。?

3、 Boss 平臺主備切換的時候，因為備機上的發(fā)布目錄數(shù)據(jù)陳舊導致。?

4、 部署還沒完成，被強制T 出的情況，下次別人部署時會提示md5校驗失敗。?解決方案：忽略，繼續(xù)部署。?

2、 配置文件部署后，DNS 解析校驗失敗?

校驗失敗的域名較少時，可以進行手動dig 看看。如果還是失敗的話可以再重新部署。?上海移動—超時?

?

3、 部署成功，但解析沒生效的?

部署時沒包括解析的內容。對未生效的zone 進行自定義部署。?

4、 配置文件上傳失敗?

網絡原因或者dns 機器宕機導致。恢復后再重新部署。?

FORWARD ?

轉發(fā)只發(fā)生在那些服務器不是其權威服務器并且其緩存沒有答案的請求上。?

Forward ?這個選項僅在轉發(fā)服務器列表非空的情況下有意義。值為first 時，即其缺省值時，將使服務器首先請求轉發(fā)服務器，并且如果它不回答問題時，服務器自行查找回答。如果指定only ，服務器只請求轉發(fā)服務器。?

?

Forwarders ?指定用于轉發(fā)的ip 地址，缺省時空列表，即不轉發(fā)。?

轉發(fā)也可以按域來配置，允許全局轉發(fā)選項被多種方式覆蓋。你可以設置某個特定的域使用不同的轉發(fā)服務器，或者使用不同的forward ?only/first行為，或者全都不轉發(fā)。?

?

內部dns ?轉發(fā)。（轉發(fā)服務器121.14.35.209;218.60.37.53）?

有些客戶覺得源變更時通知我們這里更改比較麻煩，他們就采用內部dns 轉發(fā)的形式，?他們可將某個域的轉發(fā)到他們dns 服務器上，每次他們只需修改他們dns 服務器上的配置即。

?

?

注意事項?

?

配置forward 的域名不需要配置內部dns 。擴展內容配置在數(shù)據(jù)庫中。?

平臺將約束有配置擴展內容的zone 的域名不能配置內部dns 。?

DIG 加熱?

作用?

用于強制加熱公網DNS 上我司CDN 加速域名的緩存熱度，以減少CDN 域名的DNS 解析時間，從而減少HTTP 請求的總體響應時間，給CDN 客戶更好的CDN 加速體驗。?

dnsrefresher 發(fā)包機器?

目前是安裝在0.60上，0.60每小時從boss 數(shù)據(jù)庫讀取1次所有非智能DNS 的客戶域名，跟之前正式的域名列表文件對比，如果不一致且頻道數(shù)量大于100則覆蓋之前的正式頻道列表，然后推送到dnsrefresher 機器上。配置文件每次都跟頻道列表一并推動到dnsrefresher 機器上，如果公網dns 的ip 列表在過去1個小時內有更改，也一并推送到dnsrefresher 機器。?

dnsrefresher 機器?

目前有2臺（60.210.18.50?61.147.122.3）。機器接收0.60傳送過來的頻道列表及配置文件，過濾掉不需要加熱和沒有別名到我司入口的域名，生成頻道臨時列表，跟正式頻道列表對比，如果不一致且頻道數(shù)量大于100則覆蓋正式頻道列表，然后重啟服務。?

配置文件?

配置文件中可以設置不需要加熱的域名和添加未別到我司入口的域名進行加熱。? refresher.conf ?

#定義refresher 發(fā)布機器IP ，可以多臺，換行分隔?

[refresher?server]??

121.10.120.115?

?

#我司CDN 加速的域名后綴，用于過濾沒別名到CDN 的客戶域名，當前只有cdn20.com 和lxdns.com ?

[domain?suffix]?

cdn20.com ?

lxdns.com ?

?

#過濾沒別名到CDN 的客戶域名時dig 測試用的DNS 地址，當前用GOOGLE 的2臺，因為這2臺沒有對IP 進行限制，而且服務穩(wěn)定。?

[dig?dns]?

8.8.8.8?

8.8.4.4?

?

#除已經加速外還需要額外加熱的域名，均可在該處配置。?

[additional?domain]?

myview.51cdn.com ?

?

#排除不需要加熱的域名，可在該處配置。?

[exclude?domain]?

itv.iopen.com.cn ?

?

公網dns ?

目前每天都有在收集。?