我也不是很懂libvirtd, 只知道會帶出dnsmasq,然後霸佔dns port(53)
每次要安裝power dns , 最傷腦筋的就是dns port被霸佔, 原本以為是dnsmasq本身的服務, 就systemctl disable dnsmasq , 後來發現還是被佔用, 原來是libvirtd , 只要停用這個服務就好了, systemctl disable libvirtd .
標籤: dns
It works !
Postfix 擋廣告的限制設定 sender, client, and recipient restrictions
Postfix 擋廣告的限制設定, 重要的有三個,簡稱三兄弟:
老大: smtpd_sender_restrictions
這部份著墨不多, 基本上就是檢查寄件者格式是否正確, 是第一階段限制
老2: smtpd_client_restrictions
這個設定重點在於限制主機名稱 或是 ip
例如:
check_client_access hash:/etc/postfix/sender_mail_hostname_check
代表你必須正確地, 將要限制的郵件主機名稱,或是ip (不能使用萬用字元), 寫入sender_mail_hostname_check 這個檔案裡面, 才能限制該主機.
接著再加上這個很威猛的設定 reject_unknown_client_hostname
利用dns方式, 來驗證主機名稱是否相符正, 否則就拒絕, 舉例來說:
若該郵件主機 ip 是1.2.3.4 , 且dns查詢結果是 xxx.com , 可是實際上 xxx.com 正向查詢不是 1.2.3.4 , 就會被擋下來!
ps. 1.2.3.4 可以宣稱是yyy.com 這個網域的郵件主機, 跟實際dns是xxx.com可以不一樣的.
光是這一招就能解決大部分廣告信, 因為廣告主機都會胡亂宣稱.
當然也造成很多誤判狀況, 因為有些IT人員並不會很認真處理主機ip的反解.
** reject_unknown_client_hostname 可以改用 reject_unknown_reverse_client_hostname 來替代, 只要反查不要查不出主機名稱 , 就不會擋下來, 比較寬鬆.
老3. smtpd_recipient_restrictions
這部份就很多設定了, 重點在於
check_sender_access hash:/etc/postfix/sender_email_check
sender_email_check 紀錄了寄件者郵箱或是網域是否可以限制
與老2不同的是, 這裡可以使用萬用字元, 因為阻擋的不是ip , 而是email
CentOS 7 在postfix郵件伺服器上加裝spf檢查功能,防堵垃圾郵件
SPF 是一種透過dns設定, 用於認證郵件伺服器是否合法, 進而阻擋拉圾郵件的機制, 咖啡偶管理的郵件伺服器老舊了, 從CentOS 6 改成CentOS7 , 安裝spf的方式不一樣, 因此記錄下來,
請進 10021號 IT地窖練功吧
又一家須謹慎考慮的台灣網域代管公司-戰國策
咖啡偶先前遇到一家曾經有名的台灣網域代管機構 twnci.net
不僅功能越來越不好, 繳費與服務也有問題.
現在又遇到一家不優的dns代管公司-戰國策
他們的dns實際上使用一家新加坡dns代管公司 webnic.cc , 因此dns的轉出與轉入 ,必須等webnic處理才能成功.
咖啡偶因戰國策dns 沒有CAA 功能 , 因此建議朋友轉出, 可是問題來了, 轉出是有期限的, 過了4天後, 我代朋友詢問戰國策, 不知轉出的進度如何, 可是戰國策工程師剛開始的回覆有點扯, 就是希望你先取消再重新轉出…
過了1天後(也就是5天多了), 我堅持戰國策處理 , 接手的工程師改成罐頭回覆, 意思就是5~7天就知道答案, 然後沒多久忽然email來函說轉出成功了!
其實最大的問題是戰國策無法從webinc取得客戶目前轉出的進度, 完全狀況外, 這是很麻煩的事情, 我不是急著要轉,只是想知道是否正在處理而已, 但這卻無法得到正確的答覆.
像戰國策這種收費高出快一倍(.com)的dns代管, 又不能夠掌握客人的進度(轉出), 真是不夠優質, 需要謹慎考慮使用這家的dns代管服務.
褪去的twnci.net
twnci.net 是很早期就提供網域註冊公司.
可惜後續維護不力,不僅常發生發票錯誤,延遲寄發, 或是回覆緩慢,甚至DNS設定都出問題.
這樣間接苦了還在給twnci.net管網域的公司.
因為這些公司的網域,很難轉出去給其他良好的網域代管公司,如google, godaddy.
後來咖啡偶陰錯陽差, 發現他們自己也交給別人代管, 大家可以鬆一口氣移轉出去了
網址在這裡:
https://manage.opensrs.net
bind的ddns策略
bind從8.1.2開始支援RFC2136,也就是俗稱的ddns功能.
但是要動態修改,目前只能依靠nsupdate指令.
一般的ddns策略為:
1. 提供web介面申請帳號密碼以及對應的主機名稱
2. 使用者透過程式,若偵測ip更動,自動跟web server聯繫,提供新的ip.
現在一般ip分享器提供數個熱門ddns廠商,應該很方便使用.
若有自己的domain需要提供給大家申請,有兩種作法:
1. 跟ddns提供商申請(當然要給錢)
2. 自製ddns服務
自製ddns也不會很複雜
安裝bind之後,自己寫一個socket server.
client固定時間連線到socket server將申請的主機名稱傳送過去,
socket server收到連線後,會立即知道對方ip,
接下來做些簡單的帳號認證,
做完認證之後,server將對方ip,主機名稱與原來的做比對,若不一樣,
就執行nsupdate指令,修改ddns.