DNSのお仕事その１(修正版)

19.11.10 / DNSって何？ / Author: aico / Comments: (3)

サブドメインとルートドメインとは？(修正版)

19.11.10 / DNSって何？ / Author: aico / Comments: (0)

逆引きって何だろう？

14.10.10 / DNSって何？ / Author: aico / Comments: (1)

ドメイン名(FQDN)からIPアドレスを調べること、それを正引きと呼びます。

DNSがこの正引きをしてくれることで、小悪魔ブログを見たりできるのです。

その反対に、IPアドレスからドメイン名(FQDN)を調べることを逆引きといいます。

今日は、逆引きについて勉強しましょう！

逆引きとは、IPアドレスからドメイン名を調べることをいいます。

正引きにドメインツリーがあるように、逆引きにもドメインツリーが存在します。

小悪魔IPアドレスで見てみましょう！

.arpaとin-addrって２つ何か上に付いてますね。in-addr.arpa.とは、逆引き用のドメインです。

逆引き用のドメインはIPアドレスを逆順に並べたものに、in-addr.arpaのついた形をしています。

試しにdigコマンドで逆引きの様子を見てみましょう！

$ dig 32.176.6.125.in-addr.arpa. ptrと打つと対応するドメイン名(FQDN)が見れます。

すると、このように返ってきました。

125.6.176.32の返事がco-akuma.directorz.jpではないようですね。なぜでしょう？

IPアドレスには対応するドメイン名を複数ふることができます。(※１つのドメイン名にふれるIPアドレスは１つです)

なのでここに書かれたドメイン名はいわば代表ドメイン名のようなもので、ディレクターズで管理しやすいようふったドメイン名です。そのため、co-akuma.directorz.jpではなかったのです。

しかし、この逆引き、何のために必要なのでしょうか？

逆引きは、例えば、アタックを受けたときに、どこのドメインから攻撃を受けているのかを調べることが出来て、トラブル時の手助けになります。(ただし、アタックするようなIPは設定してないことも多い)

他にも、tracerouteで経路確認する時などに、逆引きの設定があると直感的にどこを経由しているかがわかります。

また、アプリケーションの中には、逆引きの応答をタイムアウトまで待ってしまうアプリケーションも存在します。(例えばftpやMySQL)

逆引きの設定はあくまでも任意！設定も自由にできますが、補助的な役割で利用されることが多いため設定しておくと良いことあるかも！

whoisとは？

10.10.10 / DNSって何？ / Author: aico / Comments: (6)

whoisコマンドとは、ドメイン名の登録者などの情報を見ることができるコマンドです。

それではdirectorz.co.jpでwhoisの中身を試しに見てみましょう！

ターミナルで、

$ whois -h whois.jprs.jp directorz.co.jp/eと打つと情報が見れます。

日本のドメイン名を管理している団体はJPRSです。

そのため、検索先サーバにはドメイン名登録を管理しているJPRSのwhoisサーバが入っています。

また、whoisはJPRSの検索サービスでも見ることが出来ます。

さてさて、directorz.co.jpをwhois検索すると、

Domain Information:

a. [Domain Name]                DIRECTORZ.CO.JP

g. [Organization]               Directorz Co., Ltd.

l. [Organization Type]          corporation

m. [Administrative Contact]     KK19885JP

n. [Technical Contact]          KK19885JP

p. [Name Server]                dns1.directorz.jp

p. [Name Server]                dns2.directorz.jp

[State]                         Connected (2010/10/31)

[Registered Date]               2008/10/31

[Connected Date]                2008/10/31

[Last Update]                   2009/11/01 01:48:21 (JST)

となっていて、パッと見ると管理者の名前がわからなくなってますね。

そのため、$ whois -h whois.jprs.jp KK19885JP/eと入れると管理者情報が見れます。

反対にIPアドレスからもwhois検索できます。

$ whois -h whois.nic.ad.jp 182.161.76.35/e

サーバの中でwhoisのサービス用ポート番号として割り当てられているのは43番ポートです。

そのため、telnetでwhois.jprs.jpの43番ポートに入ってdirectorz.co.jpと打つと、whoisと同じ情報が見れます！

このwhois、何のために公開されているのかというと、

ドメイン名の申請時に同じドメインが存在しないかどうか確認したり、ドメイン名の期限管理に使ったり、障害が起きた時の連絡のため…などなどのため公開されています。

このようにwhoisは障害が起きたときにとても便利な機能です。しかし！やはり個人情報なので、プライバシーの問題があります。

しかし、whoisはトラブル解決のための連絡先なので非公開にはできません。

そのため、日本(JP)のドメインは公開連絡窓口というものを設置しています。

この公開連絡窓口の制度は、ドメイン所有者に連絡がつくならば、whoisで公開される個人情報をドメイン管理業者などの代替情報で登録し、公開することができるようにしています。

だけど、悪うささんのような悪い人がいなくなることが1番！ですよね。whoisを使う時は道徳的な判断をもって使いましょう！

digコマンドとレコード

08.10.10 / DNSって何？ / Author: aico / Comments: (5)

とうとう戻ってきましたDNS…わー！がんばりましょう！

今日はdigコマンドについて勉強しました。

…の前に！忘れちゃったあなたへ！DNSおさらいはこちら＊

人間にわかりやすいドメイン名(FQDN)とコンピュータにわかりやすいIPアドレスを対応付けしてくれるのがDNSで、この仕事を名前解決と呼ぶんでしたよね。

この名前解決を具体的にしてくれるDNSクライアントがdigコマンドです！

digとは、domarn information groperの略です。

ターミナルで、

$ dig [ドメイン名(FQDN)][レコードタイプ]と入れるとそのドメインに関するデータが調べられます。

そのデータの形がレコードです。

DNSレコードにはIPを指定するAレコードやメールサーバを指定するMXレコード…などなどたくさん種類のレコードタイプがあります。

試しに$ dig co-akuma.directorz.jp [レコードタイプ]と小悪魔ブログのドメイン名を入れてみると、

;; ANSWER SECTION:

co-akuma.directorz.jp. 3600 IN A 125.6.176.32

と出ます！

Aレコードは、ドメイン名(FQDN)からIPアドレスを調べる(正引き)レコードです。

ここでは、「coakuma.directorz.jpというドメイン名(FQDN)に対応するIPアドレスは125.6.176.32です。」と書いてあります。

レコードとして得られた情報はしばらくの間保存＝キャッシュされます。

キャッシュによって情報が保存されることで同じページを見るのに何度も問い合わせする必要がなくなります。

このレコードのキャッシュの有効期限を秒数で書いているのがTTLです。ここでは3600(秒)となっているので１時間キャッシュされます。

$ dig co-akuma.directorz.jpというようにレコードタイプを省略するとAレコードが検索されます。

$ dig

のようにターミナルでdigとだけ打つと

;; QUESTION SECTION:

;. IN NS

;; ANSWER SECTION:

. 518400 IN NS c.root-servers.net.

. 518400 IN NS i.root-servers.net.

. 518400 IN NS m.root-servers.net.

. 518400 IN NS h.root-servers.net.

. 518400 IN NS d.root-servers.net.

. 518400 IN NS g.root-servers.net.

. 518400 IN NS k.root-servers.net.

. 518400 IN NS b.root-servers.net.

. 518400 IN NS l.root-servers.net.

. 518400 IN NS f.root-servers.net.

. 518400 IN NS j.root-servers.net.

. 518400 IN NS e.root-servers.net.

. 518400 IN NS a.root-servers.net.

のように言われます。

NSレコードが登場しましたね。これは、ゾーン権限を持つDNSサーバを指定するレコードです。

ここでは、「ルートのゾーンを管理しているDNSサーバはこの13個です。」と書いてあります。

NSレコードはフルサービスリゾルバによる反復問い合わせの時に下位のゾーンの権限を持つDNSサーバを指定する時使われます。

DNSサーバは自分の直下と自分しか知らないので、名前解決は１つずつ下に下に反復して情報を聞いていきます。

うさこちゃんのひいおじいちゃんはうさこちゃんのじいちゃんにうさぱぱ(とその下)のことを権限委譲しているため、うさこちゃんのことを知りません。

そのため、「うさこちゃんは知らないけどうさじい(のゾーンのDNSサーバ)が知ってるかも」と言ってうさじいの情報をくれます。このとき渡される情報がうさじいのNSレコードです。

digコマンドでこの動作と同じことをすると

$ dig @m.root-servers.net co-akuma.directorz.jp

こんな感じです。

同じようにうさじいも権限委譲しているのでうさこちゃんのことを知りません。そのためうさぱぱのNSレコードをくれます。

コマンドでいうと

$ dig @a.dns.jp co-akuma.directorz.jp

うさぱぱはうさこちゃんのことを知っているのでIP（Aレコード）を渡します。

コマンドでいうと

$ dig @dns1.directorz.jp co-akuma.directorz.jp

このようにフルサービスリゾルバはどんな風に動いてるのかな？ってことをdigによって見てみたわけですが

$ dig co-akuma.directorz.jp としてもco-akuma.directorz.jpのIPは手に入れられましたよね？

なぜかというと問い合わせ先サーバが空欄になっていると/etc/resolv.confに書いてあるDNSサーバが反復問い合わせをしてくれるからです。これは自分のコンピュータが利用するDNSサーバの情報のファイルです。

つぎはMXレコードです。

$ dig directorz.jp mxと入力するとこのようにでます。

;; ANSWER SECTION:

directorz.jp. 1736 IN MX 3 mail.directorz.jp.

MXレコードはメールアドレスに利用するドメイン名(FQDN)を指定するレコードです。

ここでは「＠の後ろがdirectorz.jp となっているメールアドレスに送られたメールはmail.directorz.jpのメールサーバが受け取ります。」と書いてあります。

メールアドレスはユーザ名+ドメイン名(FQDN)で出来ています。

MXレコードはドメイン名とメールサーバのFQDNとを結びつけます。

そのため、もしうさおくんがうさこちゃんにお手紙を出すと、

MXレコードでうさこちゃんのドメイン名と結びつけられたFQDNのメールサーバに送られるのです。

MXレコードにはメールサーバの優先順位をつけるプリファレンス値というものがあります。

プレファレンス値はドメイン名に結びつけられたメールサーバが２つ以上の時どちらを優先的に使うかを表しています。

プレファレンス値がより低い方から順番に優先して使われます。

４つ目はSOAレコードです！

SOAレコードはゾーン権限を持っているDNSサーバとその詳細が書かれているレコードです。

$ dig directorz.jp soaと入力すると…

;; ANSWER SECTION:

directorz.jp. 2560 IN SOA　　 dns1.directorz.jp. hostmaster.directorz.jp.

1286337318 16384 2048 1048576 2560

数字がたくさん並んでますが、これはゾーン管理のための情報です。

DNSでは、複数のサーバでゾーン管理することによってDNSサーバの負担を軽減したり、障害が発生してもすぐ対策できるようになっています。

ネームサーバには管理者が設定するマスターサーバと、そのデータをコピーをもつスレーブサーバが存在します。

この、スレーブサーバによるマスターサーバのゾーン情報をコピーする作業をゾーン転送といいます。

スレーブサーバはrefreshの時間に沿ってマスターサーバのserialを確認して、自分の持っているものより大きいシリアルナンバーになっていたら、ゾーン転送を行います。

retryはゾーンファイル更新の確認が上手く出来なかった時、再確認を行うまでの時間を指定しています。

再確認が失敗し、expiryに指定された時間が経過してしまった時、スレーブサーバはそのゾーンのサーバとして動くことをやめます。

これは、トラブルが起きた時、誤った情報を流し続けないようにするため指定されています。

minimumはネガティブキャッシュのTTLです。

例えば、存在しないoo-akuma.directorz.jpというFQDNのレコードを尋ねても、ありませんってことがかえってくるだけです。

その、ありませんという返事をキャッシュするのがネガティブキャッシュです。

最後はTXTレコードです。

文章(テキスト)をドメイン名に関連づけられるのがTXTレコードです。

$ dig directorz.jp txtと入力すると…

;; ANSWER SECTION:

directorz.jp. 3600 IN TXT “v=spf1 ip4:125.6.176.0/24 ip4:211.125.109.73 ip4:219.94.152.26 ~all”

ここでは、「directorz.jpのテキストレコードはIPアドレスはIPv４で記述されていて、125.6.176.0/24(他2つ)以外のIPアドレスからdirectorz.jpとして送られてきたメールはなりすましの可能性があるためできるだけ受信しないでください。」と書いてあります。

TXTレコードはDNSの拡張用に用意されたレコードで、最近では主に、メールサーバのIPアドレスを確認して送信メールのなりすましを防ぐために使われます。

ルートサーバってなんだろうその２

27.05.10 / DNSって何？ / Author: aico / Comments: (13)

前回、ルートサーバは世界に１３個あり、日本では、その１つをWIDEプロジェクトが管理しているということがわかりました。

ルートサーバは名前空間の最も上に位置するサーバです。
なので、もし１３台すべてのルートサーバがアクセスできない状態になると、インターネットは使えなくなってしまいます。

２００２年、DDoS攻撃というルートサーバへの攻撃によって１３台のうち９台のルートサーバが影響をうけ、内７台は一時的にサービスが不能になった事件が起きました。

DNSではプロトコル上の制限によりルートサーバーとして指定可能なサーバーが最大13台までに制限されているため、通常の方法ではそれを超える数のサーバーを配置することはできません。

そこで、IP Anycastという、IPアドレスを複数のサーバで共有する技術によって、同じIPアドレスをもつDNSサーバーが世界各地に設置されました。IP Anycastでは、ユーザーはそのうち最も効率よくすばやく情報をおくってくれるサーバーに接続するようになっています。

なので、日本にもM.ROOT-SERVERS.NETの他に４つの海外の企業が管理するルートサーバと同じIPアドレスを持ったサーバが設置されています。

つまり、１３台というのは、ルートサーバの数ではなく、サーバを仕切るホストコンピュータの数なのです。

ルートサーバの管理するルートドメインはふだんドメイン名(FQDN)にかかれることはありません。しかし、このように管理されながら、インターネットの世界で重要な役割をはたしているのです！

ルートサーバーってなんだろう？

27.05.10 / DNSって何？ / Author: aico / Comments: (2)

今日は、DNSの途中ですが、DNSやインターネットにとってとっても重要な役割をはたしているルートサーバについて勉強しました！

ルートサーバはDNSのドメイン名前空間の頂点のサーバです。

下の絵は「サブドメインとルートドメインってなんだろう？」のときにでてきたイラストです。

このルートドメインの空間を管理しているのがルートサーバで、世界に13個存在しています。

ルートサーバ１３台のうちそのほとんどがアメリカで管理されています。日本で管理しているのは、１３台目でWIDEプロジェクトによって管理されています。

ルートサーバーは基本的に全てが同じデータを持っています。
ルートサーバーはドメインのトップレベルドメインを管理するDNSサーバーの一覧です。日本にあるサーバだから
日本を管理しているわけではなく、ルートサーバーはcomもnetもjpもtoもcnも全てのトップレベルドメインのDNSサーバーのIPアドレスを持っています。

すべてのルートサーバはa.root-servers.netからm.root-servers.netの正式名称を持っています。

日本のルートサーバは、WIDEプロジェクトが管理しているルートサーバのM.ROOT-SERVERS.NETで、

WIDEプロジェクトが管理しています。

WIDEプロジェクトは、慶応義塾大学の村井純教授らが中心になって1988年に設立された、インターネットに関する研究プロジェクトです。日本におけるインターネットの先駆け的存在の一つとなったことで知られています。

つづきます！

BINDの設定をしよう！

19.05.10 / DNSって何？ / Author: aico / Comments: (3)

今日は、レコードの勉強のため、BINDというフリーのDNSサーバソフトウェアを設定しました！
BINDを設定することで、IPアドレスとドメイン名の名前解決ができるようになります。

BINDとは、ソースコードが無料で公開されているフリーのソフトウェアで、世界でもっとも普及しているDNSサーバーです。

今回は、新しく作ったcoakuma.netというドメイン名を、小悪魔ブログのIPアドレスに対応付けして、http://coakuma.net/blog/でもこのブログが見れるようにしました。

今回はcoakuma.netというドメインを「お名前.com」さんで取得してもらい、BINDを設定する上で必要なインストールはできている状態なので、設定からスタートです＊


まず、$ ssh [サーバー名] 、パスワード入力でサーバーに入り、
$ sudo bashでroot権限を得ます。

設定ファイル/etc/name.confを設定して、coakuma.netのサーバーのゾーンを設定します。

$ vi /etc/named.confで編集画面にします。
named.confにzoneステートメントをかきます。

include”/etc/rndc.key”;のまえに、

zone “coakuma.net” IN {
type master ;
file “coakuma.net.zone” ;
};
とかきます！

ここまで、まちがいがないかチェックしましょう！
$ /usr/sbin/named-checkconf /etc/named.conf    と入力して、なにもでてこなければOKです！

$ ssh [サーバー名] でサーバーに
パスワード入力
$ sudo bashでroot権限に
$ vi /etc/named.confで設定ファイル編集
iで編集モードに
zone “[ゾーン名]” IN {
type master ;
file “[ゾーンファイル名]” ;
};
escで編集終了
$ /usr/sbin/named-checkconf /etc/named.conf で間違いがないか確認

つぎにゾーンファイルをつくりましょう！
ゾーンファイルは/var/named/chroot/var/named内につくります！

ところで、chrootとはなんでしょう？

chrootはファイルシステム内の特定のサブディレクトリを、仮想的なルートディレクトリとして見せかける機能です。/etcディレクトリと/var/namedディレクトリ以下にあるBINDの設定ファイルを、/var/named/chroot以下の/etcディレクトリと/var/namedディレクトリ以下に置くことによって、権限をとられた場合でも、その被害をchrootしたファイルシステム内にとどめることができる、セキュリティ維持の仕組みです。

まず、
$ cd /var/named/ でvar/namedに移動して、
$ ls -laで/var/named/の中身を確認します。

chrootディレクトリがないので、
$ mkdir -p chroot/var/namedで、/var/named/chroot/var/namedを作成します。

$ cd chroot/var/named/で /var/named/chroot/var/namedに移動して、ゾーンファイルcoakuma.net.zoneを作成します。
$ vi coakuma.net.zoneとして編集画面に入ります。

$TTL 10800
coakuma.net. 1D IN SOA co-akuma.directorz.jp. usako.usausa.usagi.jp (
2010051301 ; serial
43200 ; refresh
5400 ; retry
3600000 ; expiry
10800 ) ; minimum
coakuma.net. 1D IN NS co-akuma.directorz.jp.
coakuma.net. 1D IN A 125.6.176.32

…と記入します。
:wqで保存し、編集を終えます。

$ cd /var/named/ でvar/namedに移動
$ mkdir -p chroot/var/namedで、/var/named/chroot/var/namedを作成
$ cd chroot/var/named/で /var/named/chroot/var/namedに移動
$ vi coakuma.net.zoneとして編集画面に
$TTL 10800
[ドメイン名]. 1D IN SOA [サーバー名]. [メールアドレス] (
[年月日]01 ; serial
43200 ; refresh
5400 ; retry
3600000 ; expiry
10800 ) ; minimum
[ドメイン名]. 1D IN NS [サーバー名]
[ドメイン名].  1D IN A [IPアドレス]
$ usr/sbin/named-checkzone coakuma.net  /var/named/coakuma.net.zoneでまちがいがないかチェックします。

ファイルを作成したらシンボリックリンクをはります。
$ ln -s /var/named/chroot/var/named/coakuma.net.zone /var/named/

これで、/var/named/chroot/var/named/coakuma.net.zoneを/var/named/にリンクされます。
/var/named/内にcoakuma.net.zoneがあるような状態になったので、これで、起動スクリプト/etc/init.d/named/ でも呼び出すことができるのです。

設定が終わったのでBINDを起動させましょう！
$/etc/init.d/named/ start

これで、coakuma.netで小悪魔ブログがみれるようになりました！

$ ssh [サーバー名] でサーバーに
パスワード入力
$ sudo bashでroot権限に
$ vi /etc/named.confで設定ファイル編集
iで編集モードに
zone “[ゾーン名]” IN {
type master ;
file “[ゾーンファイル名]” ;
};
escで編集終了
$ /usr/sbin/named-checkconf /etc/named.conf で間違いがないか確認

$ cd /var/named/ でvar/namedに移動
$ mkdir -p chroot/var/namedで、/var/named/chroot/var/namedを作成
$ cd chroot/var/named/で /var/named/chroot/var/namedに移動
$ vi coakuma.net.zoneとして編集画面に
$TTL 10800
[ドメイン名]. 1D IN SOA [サーバー名]. [メールアドレス] (
[年月日]01 ; serial
43200 ; refresh
5400 ; retry
3600000 ; expiry
10800 ) ; minimum
[ドメイン名]. 1D IN NS [サーバー名]
[ドメイン名].  1D IN A [IPアドレス]
$ usr/sbin/named-checkzone coakuma.net  /var/named/coakuma.net.zoneでまちがいがないかチェックします。

$ ln -s /var/named/chroot/var/named/coakuma.net.zone /var/named/
$/etc/init.d/named/ start

DNSのお仕事　その２

30.04.10 / DNSって何？ / Author: aico / Comments: (5)

DNSのお仕事、つづきです。

DNSサーバーには３つの働きがあります。

コンテンツサーバー、スタブリゾルバ(一般にリゾルバとはこれのこと)、フルサービスリゾルバの３つです。

それぞれどのように働いているのでしょうか？

リゾルバ(スタブリゾルバ)がドメイン名に対応するIPアドレスがあるかを、
自分のDNSサーバー内のフルサービスリゾルバがキャッシュしてないか、コンテンツサーバーが情報を持っているかを尋ねます。
これを再帰問い合わせといいます。
対応付けができなければ、こんどはフルサービスリゾルバが他のDNSサーバーのコンテンツサーバーに尋ねていきます。
これは、対応付けができるまでつづけられるので、反復問い合わせといいます。
IPアドレスとの対応付けができるコンテンツサーバーに遭遇したら、
その情報をフルサービスリゾルバがキャッシュします。
そのはたらきにより、フルサービスリゾルバはキャッシュサーバーとも呼ばれます。
このようにして、DNSサーバーはIPアドレスとDNSの対応付けをしているのです。

まとめです！

ドメイン名とホスト名ってなんだろう？

30.04.10 / DNSって何？ / Author: aico / Comments: (1)

IPアドレスを簡単にまとめたところで、つぎはドメイン名について!です。

ドメイン名とはインターネット上の住所であるIPアドレスを人間がわかりやすいように表示したものということでしたが、その仕組みはどうなっているのでしょうか？

ドメインはもともと領土や範囲という意味の単語です。

このブログのドメイン名はdirectorz.jpです。

jpやdirectorzなど、組織や団体などの単位一つ一つドメインといい、そのドメインの名前をドメイン名といいます。

ドメイン名はIPアドレスを人間がわかりはやすいようにした形式で . で区切られた文字列ですが、それぞれの文字列には意味があります。

co-akuma.directorz.jpは、co-akumaというホスト.directorzというドメイン.日本(jp)のドメインという意味です。

つまり、うさおくんでいうとうさうさ村、うさぎ県というようにうさおくんの住む場所を表すように、
co-akuma.directorz.jpではjpで日本、directorzでディレクターズという会社といったようにco-akuma.directorz.jpが所属しているものをあらわしています。

つまり、ドメイン名とは、ホストがどこに所属しているのか、どこの領土・範囲にいる人なのかをあらわしているのです。

なので、おなじうさこちゃん(このブログでいえばco-akuma)というホスト名でも、所属(ドメイン)が違えばまったく別人ということになります。

ドメインには右側から順番にレベルがあります。

ドメイン名の一番右の文字列をトップレベルドメイン(TLD)といいます。
FQDNのco-akuma.directorz.jpでいうとjpの部分です。
トップレベルドメインには、jpが日本内のドメインというように国名を表すccTLD(country code TLD)と
、com(商用)やnet(ネットワークサービス提供組織)といった組織の種別を表すgTLD(generic TLD)があります。

FQDNのco-akuma.directorz.jpのdirectorzの部分をセカンドレベルドメイン(SLD)といいます。
セカンドレベルドメインには、ne(ネットワーク)やco(商用)といった組織別にわけるものが広く使われていましたが、
tokyo.jpのように地域型のドメインや、directorz.jpのように組織別のドメインをつかわないものも使えるようになりました。

そのあともサードレベルドメイン…のようにつづきます。

FQDNの一番左、co-akuma.directorz.jpではco-akumaの部分をホスト名といいます。

そして、ホスト名、トップレベルドメイン名、セカンドレベルドメイン名…すべてを記したものをFQDN(完全修飾ドメイン名)と呼びます。

ホスト名というのはネットワーク上のコンピューターの名前で、ドメイン名はホストが所属する所の名前です。
ドメイン名(ホスト名)なんてかいてあってどう違うの!?という質問をよく見ますが、ホスト名はホストに割り当てられるドメイン名なのです。

うさぎ国のうさうさ村のうさおくん(usao.usausa.usagi)におきかえて考えてみましょう。

うさぎ国うさうさ村というのはこのブログでいうとdirectorz.jpの部分ですが、これは、うさおくんが住んでいる(所属している)場所なのでドメイン名です。
usausa.usagiだけではうさうさ村の誰なのかわかりませんよね。だからこれはホスト名ではないことがわかります。

うさおくんというのは、うさおくんといううさぎ(ホスト)とわかるのでホスト名です。
また、うさおくんというホストにわりあてられたドメイン名でもあります。
これは、たとえば、うさぎ国うさうさ村のうさぎたちなら、このむらにはうさおくんはひとりしか存在しないので、うさおくんがどこにいるかわかりますよね。
だから、うさおくんのいる場所、ドメイン名といえるのです。

うさぎ国うさうさ村うさおくんというのはこのブログでいうco-akuma.directorz.jpの部分です。
これは、うさおくんのいる場所をあらわしているのでドメイン名であり、住所(ドメイン名)と名前(ホスト名)すべてを書いているのでFQDN(完全修飾ドメイン名)です。
また、誰あてであるか、つまり、ホストが誰であるのかもわかるので、ホスト名といえます。
また、よく、IPアドレスに対応するのはドメイン名とかかれていますが、この場合のドメイン名はFQDNのことをさしています。