mkdir -p $PWD/adguardhome/workdir
mkdir -p $PWD/adguardhome/confdir
docker rm -f adguardhome
docker run \
-d \
--name=adguardhome \
--restart=always \
-v $PWD/adguardhome/workdir:/opt/adguardhome/work \
-v $PWD/adguardhome/confdir:/opt/adguardhome/conf \
-p 53:53/tcp \
-p 53:53/udp \
-p 67:67/udp \
-p 68:68/tcp \
-p 68:68/udp \
-p 80:80/tcp \
-p 443:443/tcp \
-p 853:853/tcp \
-p 3000:3000/tcp \
adguard/adguardhome
標籤彙整: dns
使用EDNS跟DNSSec保護DNS資料
DNS伺服器扮演著將IP與網域對應的工作.
但因為當初DNS設計並沒有考量安全性的設計,導致至今有許多DNS偽造的情況.
為瞭解決上述問題,衍生出了DNSSec以及EDNS等相關技術的發展.
然而DNS已經行之有年,許多DNS Server並沒有落實EDNS.
所以過去有一段時間,公用的DNS Server對於未支援EDNS的伺服器會採用二次查詢的方式.
也就是第一次會使用EDNS查詢,失敗後改用傳統DNS方式查詢.
如此一來就可以相容兩種系統,但是也造成EDNS遲遲無法普及.
因此幾個公用的DNS Server(如Google 8.8.8.8, GloudFlare 1.1.1.1)約定在2019/2/1這天要來測試只做EDNS查詢,並將這一天稱為DNS Flag Day.
所以當DNS Server不支援EDNS時,將會造成網域名稱無法順利解析.
為避免上述狀況,本研究採用下列方式,開啟EDNS及DNSSec之設定.
下面是有關於如何將DNS提升至EDNS的方法:
1.確定網域名稱,並準備好網域設定檔
DOMAIN=cbe.tw
# 網域設定檔: ${DOMAIN}.txt
2.建立公私鑰
2.1.KSK
KSK_KEY=$(dnssec-keygen -r /dev/urandom -f KSK -a RSASHA512 -b 2048 -n ZONE ${DOMAIN})
2.2.ZSK
ZSK_KEY=$(dnssec-keygen -r /dev/urandom -a RSASHA512 -b 1024 -n ZONE ${DOMAIN})
3.將key附加到網域設定檔 ( 也就是${DOMAIN}.txt )
cat K${DOMAIN}*.key >> ${DOMAIN}.txt
4.產生加簽後的網域設定檔 ( )
dnssec-signzone -o ${DOMAIN} -k ${KSK_KEY}.key ${DOMAIN}.txt ${ZSK_KEY}.key
上述步驟將會產生:
* 加簽過後的網域設定檔,檔名會是 ${DOMAIN}.txt.signed
* DS紀錄檔(DS records),檔名會是 dsset-${DOMAIN}.
5.啟用DNSSec
* 將${DOMAIN}.txt.signed放到 DNS Server上 (如Bind9 or CoreDNS).
* 到網域註冊商上加入DS records.
* 開啟TCP 53 port,並做好對應的NAT.
6.檢測
* https://dnsflagday.net/#domain-holders
* https://dnssec-analyzer.verisignlabs.com/
* http://dnsviz.net/
解決pfsense內網中,無法向pfsense的public ip查詢DNS問題
儘管已經做了DNS server的NAT
卻只能從外部IP對DNS server做查詢.
但內網對無法做查詢.
解決辦法是在NAT中,將所有內網連到外部IP的DNS查詢,導向DNS server
refer:
https://www.netgate.com/docs/pfsense/nat/accessing-port-forwards-from-local-networks.html
https://www.netgate.com/docs/pfsense/dns/redirecting-all-dns-requests-to-pfsense.html