2010年2月24日

DNSSEC HOWTO 實作(實際設定)

DNSSEC keys tester & roller

DNSSEC keys 更替工具



location:

http://lyrics.meicho.com.tw/program/DNSSEC/rolling_keys.zip







HISTORY:

2009/10/24 11:3:18-28 0:0:26 main program by kanashimi

2010/2/24 11:00:29 公開





說明:

近來 DNSSEC 越來越受到注目,意外發現自己之前列出實作方法的文章排在 Google 搜尋中文網頁 "DNSSEC Howto" 的前三名,為了讓大家更方便的使用,寫了這個小工具。

本工具的用途為自動探測並更替 (rolling) ZSK key,限制條件為已經自己操作過 DNSSEC 的設置,熟知其機制,使用 bind9,並且僅有單一組 ZSK key 的情況。



** 請千萬注意:

1. 因為只適用在小弟的機器上,因此使用時非常需要注意!這支程式說是工具,其實比較合適的用法是請大家研究程式碼的設定方式之後自己手動操作。當然,您若是 願意測試後提一點建議,相信能夠幫助更多人…

2. 使用前請初始化 user config 部分的設定。



有任何建議請到 下列討論區發表:

https://meicho.com.tw/phpBB3/viewforum.php?f=9



main siite:

http://lyrics.meicho.com.tw/





TODO:

initial DNSSEC

roll KSK

get zone file from named config file









old DNSSEC note:



https://www.isc.org/solutions/dlv

http://alan.clegg.com/files/DNSSEC_in_6_minutes.pdf

http://www.nlnetlabs.nl/dnssec_howto/#part.dnssec

帶 有數字簽名驗證的域名系統安全協議(Domain Name System SECurity,DNSSEC)

http://www.ietf.org/rfc/rfc4431.txt?number=4431

http://blog.chinaunix.net/u2/70435/showart_716278.html





# backup all config





cd /etc/namedb/DNSSEC



# KSK (Key Signing Key) should be rolled once a year

dnssec-keygen -r/dev/random -a RSASHA1 -b 4096 -n ZONE -f KSK _domain_name_

K_domain_name_.+005+22222



# ZSK (Zone Signing Key) should be rolled every 3 months

dnssec-keygen -r/dev/random -a RSASHA1 -b 1024 -n ZONE _domain_name_

K_domain_name_.+005+11111





# add key

vi ../master/_domain_name_.hosts

#$include ../DNSSEC/K_domain_name_.+005+11111.key

#$include ../DNSSEC/K_domain_name_.+005+22222.key

#.. and others

# change zone serial



dnssec-signzone -N INCREMENT -o _domain_name_ -k K_domain_name_.+005+22222.key ../master/_domain_name_.hosts K_domain_name_.+005+11111.key





wget --no-check-certificate https://www.dns-oarc.net/files/odvr/configs/bind/trusted-keys.conf

mv -f trusted-keys.conf trusted-keys

## another way:

#sh

{ echo 'trusted-keys {'; cat "K_domain_name_.+005+22222.key"; echo '};'; } > trusted-keys



#vi trusted-keys

#_domain_name_. 257 3 5 "~";



wget http://ftp.isc.org/www/dlv/dlv.isc.org.key http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf





vi ../named.conf

# modify file at zone section

# file "master/_domain_name_.hosts.signed";



# dnssec-enable yes; dnssec-validation yes; dnssec-lookaside "." trust-anchor "dlv.isc.org.";

# channel dnssec_log

#include "DNSSEC/dlv.isc.org.named.conf";

#include "DNSSEC/trusted-keys";



# restart bind

# /usr/sbin/named -u bind -t /var/named -c /etc/namedb/named.conf



# copy config files

#/bin/cp -prif /var/named/var/log/named/* /var/log/named/bak/

/bin/cp -prif /etc/namedb /var/named/etc/ && /usr/sbin/named-checkconf && /usr/sbin/rndc reload



#tail /var/named/var/log/named/bind.log



# test

dig _domain_name_ DNSKEY

dig _domain_name_ A +dnssec +multiline +retry=1



# for error: the working directory is not writable

#chmod g+w /var/named/etc/namedb

#..useless





dnssec-signzone -N INCREMENT -l dlv.isc.org. -o _domain_name_ -k K_domain_name_.+005+22222.key ../master/_domain_name_.hosts K_domain_name_.+005+11111.key

# restart bind



# send "dlvset-_domain_name_." to dlv-registry@isc.org



# add "dlv IN A" which list in mail



# test & see log

# http://www.networksorcery.com/enp/protocol/dns.htm

tail -f /var/named/var/log/named/bind_dnssec.log

# https://lists.isc.org/pipermail/bind-users/2009-January/074760.html

# Authoritative servers will never set the AD bit for their own zones.

# https://www.dns-oarc.net/oarc/services/odvr

dig +dnssec @149.20.64.20 _domain_name_

# OK. We get the AD bit set.



dig +dnssec @149.20.64.20 www._domain_name_

# wait 3 min.

dig +dnssec @149.20.64.20 www._domain_name_

# OK. We get the AD bit set.











# after: Rolling keys

# http://www.nlnetlabs.nl/publications/dnssec_howto/index.html#x1-490005.5



# backup all config





# ZSK (Zone Signing Key) should be rolled every 3 months

dnssec-keygen -a RSASHA1 -b 1024 -n ZONE _domain_name_

K_domain_name_.+005+33333



# add key

vi ../master/_domain_name_.hosts

#$include ../DNSSEC/K_domain_name_.+005+44444.key

#.. and others

# comment old ZSK

# change zone serial



# -N INCREMENT automatically increments the serial number during signing. Removes “human error factor”

dnssec-signzone -N INCREMENT -o _domain_name_ -k K_domain_name_.+005+22222.key ../master/_domain_name_.hosts K_domain_name_.+005+33333.key





# copy config files

/bin/cp -prif /etc/namedb /var/named/etc/ && /usr/sbin/named-checkconf && /usr/sbin/rndc reload





# login https://dlv.isc.org/ and check it

2010年1月10日

軟體源碼親和力

Jedi's BLOG 提到想把 open source 帶入不熟悉 source 的社群中會有障礙,並引伸出開放源碼不見得安全。我卻想到,法律不也有類似的情形嗎?雖然法律是公開的,現在台灣也有資料庫可查(所以「取得知識」的權力對大部分人來說不但具備且近於免費);但不曉得法律以及法界約定俗成(所謂潛規則)的就是不知道該怎麼處理比較好,因此才有「懂法律」的說法。而制定法律的也不見得都能做到公平公正、不偏頗。相同的,因為大部分人生活中不會太常用到法律,而深究法律又得花費大量時間,因此才有法律諮詢或代理的服務,讓不懂的人也能有扇窗。雖然程式通常只有撰寫專案的 team 或個人比較熟悉,但法律還是有類似的情形:通常某些特殊法只有相關的專家才知道每條法則的言外之音。打個比方,Linux 的 source 是民法或刑法,但其他程式,就像對著作權只有研究過著作權的才能「鑽法律漏洞」。不同的可能在比例上吧。當然我們也可以對每條法律作注疏,讓普通人都知道他們真正的意涵與在各種情況下的處置,但我們卻沒這麼做。我們知道的頂多是有些「生活法律」之類的書籍或資訊罷了。當然這或許不能說是理想,但社會會變成這樣總是有其背後的道理肇因。因此對 open source,「增加親和力」或許在現階段還是理想吧?我們無法冀望大家都會寫程式,就如同不能妄想大家都懂法律;也不能要求程式撰寫者都能夠做好親和力工程;可以的話現在的世界大家都能懂法律,也不太需要公設義務律師的存在了。我們所見到的是,與法律相同,有很多人正是靠這分隔閡來賺錢。所以資料庫的證照與系統管理的不能互通,而我們要某個功能的應用程式,還是得找軟體設計公司。也所以巨匠電腦資訊課程才能如此壯大啊。

2009年4月25日

媒體與社會責任

應付之作。因為差了一天,正式填補完成時,有些前夜大綱到底在提什麼已經忘了。

媒體與社會責任

臺灣有許多報導好以聳動筆法與題材來炒作新聞,媒體亂象似乎已是國內外公認(自他公認)的現狀。在平面媒體的未來我們稍微提過這點。有些人理直氣壯,如黎智英曾說報導正確是最重要的,而別怪媒體為什麼要報負面新聞。近年來媒體競相追逐羶色腥八卦新聞,一些人認為追逐觸及率與媒介覆蓋率是媒體亂象的主因。以現在台灣的情況,我想多數人應該都同意,報導不應只是要求真,而尚需要包含些其他的考量。如同公民有公民的責任,知識分子有知識分子的;媒體也應當有其需負的社會責任。我們想知道,那會包含哪些內容?當下倉卒間(咄嗟に)我所想到,理想的新聞媒體所應具有的條件起碼包含下列項目。這邊對詞彙的定義,其範疇可能會比普通的常識更大一點。或者說,需要更多些的想像力。例如首個「報導」不只是指平面媒體,而可能包括從電視新聞起,所有對事件的陳述,以及取材的方法。
基本與被動的責任:
事件報導與更進一步的陳述本身應重事實,不染上任何價值觀之色彩。
報導本身能不偏好某部分題材,或從道德等特殊價值觀的角度作評論、判斷等,例如「是~」、「未免太~」。用語應盡量避免引人遐想;非不得已,也應加註以預防被斷章取義或誤解。「嚴守中立、不涉入情感」是某些人對新聞報導的要求,但我們還需注意,「中立」本身可能已是某些偏見的中間值。
理想的報導除了外,尚應呈現各方面事實。媒體經常報導的是片面事實,但不是真相。光是秉公報導,縱使盡是事實,卻不表示就真的能見到真相;有時反而會予人錯誤的信任感,久了進而導致錯誤的認知。不說已過為「和諧」的大陸媒體,這邊舉常常報導社會光明面的大愛新聞為例。當有人因為認為時下新聞過於負面,新聞只看大愛時,這固然表示大愛獲得了這些人的信任,卻也表現了一種矯往過度的趨勢。大愛雖予人有「充滿愛」的印象,但這種價值觀本身就是種偏倚。
可惜的是,能報導的太多;資源(包括觀眾的時間)有限時,對事件重要性之選擇將大大的影響報導的真確性。下面我們會提到,可以以「是否能為社會帶來幸福」來作為選擇依據。但人們對「幸福」的認定標準各有不同,因此其間尚存有問題。(順帶一提,我個人覺得「和諧」從某種角度來說相當的幸福,當絕大多數人都認同時;雖然對許多人來說,光是不能自由發表言論這點就足以認定那是屁。)
分析與評論、或批判性節目,應保持自洽之價值觀體系。
光是對事時的陳述自然是不夠的。觀眾總是需要引路人告訴他們到底發生了什麼事,這些事又代表了什麼。只是這種節目理當明言參雜了特殊價值觀評價,並應從各種可能角度切入,以防偏頗。某些節目會標榜深入思考,從另一個角度看來卻是價值觀灌輸。
當然這邊所云為理想。舉例來說就算媒體可以擺脫對出錢出力贊助商的責任,引導方法這部分還是很難完全去除社會風氣與輿論,甚至是播報者個人價值觀的影響。
對此我們的解決法同樣採取人海戰術。盡量使各種意見浮現,目的在讓觀眾自己看清真相以決策所要持的態度。因為我們頂多只能決定哪些立場是有缺陷、存在矛盾的,而無法說哪些絕對是對的。當然這些評論很可能是參與者自以為是的真相,但若可能,應讓真理越辯越明。因此媒體應提供每個人溝通反饋的管道,並能做簡明的統整,使觀眾了解各種意見(態度立場/attitude)及其地位,並知道各意見可能的缺失以及其符合真相的部分。
對於未能理性或無能力全面性理解事實的觀眾,應提供引導方法,並預先注射「預防針」。
這點為上一點的延伸。報導「行為」不應逾越主流價值觀所允許之畛域,但分析不在此限。主流價值觀不代表就絕對是自洽的。(如戰爭時、極端的民族主義等。)
實際例子,狗仔隊侵犯隱私事件之所以層出不窮,就因為有人想看。對那些喜歡看羶腥新聞的人來說,他們自覺沒錯。若報導僅僅站在窺探名人的角度,那這些人就不會產生其他的想法。
政治新聞更需要注意這點。假如報導能指引觀眾從各種不同角度來思考新聞事件的價值,那麼不同黨派的人相互理解的可能性也會較高。引導可說是為了不給這些人(其實應該算是普羅大眾)「不良」示範所做的準備。這世上沒有絕對的利害善惡,當然也沒絕對的正義(甚至可說過於強烈的正義有時還更趨向於「惡」);依 Gödel's incompleteness theorems,甚至沒有「真理」。但我們有必要維持一個自洽且可被廣泛接受的主流價值觀。
下面並非責任,但不代表可以忽略;算是理想吧。好媒體應主動的:
為社會帶來幸福
例如改變觀眾:使進化。
這邊需注意的是,何謂進化。舉例來說,圓融價值觀,並拓展視界。例如訪問持槍犯與人質時,記者或許需要讓觀眾體會各方的心理,並避免刺激犯人。
拓展視界除了像 Discovery,還包括尋找公眾關切的問題。這應該算是上面「引導」的加強版。當觀眾沒意識到自己不曉得某些重要議題時,媒體應提醒他們。
從報紙煽色腥新聞內容探討報業企業社會責任之研究(by 呂郁女)整理了新評會(中華民國新聞評議委員會)研究,同樣做出份列表,以下稍提些意見。
經濟性責任
視影響力。應該說因為負責任的對象是觀眾,所以基本上這不是問題。我們不會因有人買不起大英百科全書而怪罪大英百科未竟經濟性責任。
法律性責任
媒體在某方面來說是良心事業。當然我們可以說在大陸就得遵守中共法令。但這將會包括對人權的剝削。此項改成上述「自洽之價值觀」較宜。
倫理性責任
媒體應對自己負責。例如社會普遍希望多一點政治內容時,媒體仍應導正風氣,而非同流合汙。可惜結果正如時下所見。另可參照「新聞橋」為何走入歷史?。
自發性責任
近上述「為社會帶來幸福」。
教育性責任
近上述「預防針」。
後來發現,書評尋找一把共通刻度的倫理量尺所提 Contemporary Media Ethics 似乎比所參照其他文章更接近這邊所取的概念。裡面提到了持槍犯與人質的問題。
2009/4/23-25 0:11:4