ラベル DNS の投稿を表示しています。 すべての投稿を表示
ラベル DNS の投稿を表示しています。 すべての投稿を表示

2022年2月10日木曜日

freenom(無料ドメイン)

freenomは、お試しに少しだけ利用する程度なら良いと思う。

ただ、freenomのDNSサーバで障害が起こっているのか分からないが
翌日になって、AWS Route53と紐付けしたのが認識できなかったりするので
利用できない場合は、翌日以降に放置が良いかと思う。。


digコマンドを投入すると以下の不具合になることがある。

1. 作成したドメインが設定以前のfreenomのDNSに戻ってたりする。
2. DNSのルート情報と紐付けされたりして、ドメインの登録自体が出来てない状況。



ちなみに、翌日になると回復していたりするが、無料で利用している物のなので
回復時期は期待しないほうが良い。


2021年10月27日水曜日

サービスディスカバリ for k8s(逆引き・正引き編)

サービスディスカバリー:
要は、クラスター内部のDNS内に各種Podが自動登録されるので
サービス間の連携時に、登録済みのAレコードなどを指定して利用する仕組み


1)以下の対象のPodで環境変数の値として、登録されてるか確認してみる。














2)サービス名を確認する(赤枠参照)
















3)サービス名(今回は、nginx)で、登録されているのか

curlコマンドで確認してみる。



















4)以下の指定方法で確認ができる。

サービス名.ネームスペース.svc.cluster.local



















5)以下、SRVレコードでも確認してみる。

dig web01-test.default.svc.cluster.local SRV






サービスディスカバリ for k8s(SRVレコード編)

SRVレコード:
ポート名+プロトコルを含めた状態でエンドポイントをDNSで名前解決する仕組みになる。


1)サンプルとして以下のマニュフェストを作成して、デプロイを行う。

例:

ポート名   (nginx)

プロトコル(TCP)



2)以下、SRVレコードでも確認してみる。


dig nginx.tcp.web01-test.default.svc.cluster.local SRV

  ->指定しているポート番号(8080)が確認できる












内部DNS for k8s

k8sのDNSに登録されているレコードは、*.cluster.localのみなので
それ以外のレコードについては、外部のDNSに”再帰問い合わせ”している。


Headless service(内部DNSによる、負荷分散) for k8s


Headless service:
DNS経由で、Nodeに配置している対象のPodにアクセスする仕組みを指す。
(DNSラウンドロビンと同じ仕組み)
要は、LoadBlancerによる負荷分散か内部DNSによる負荷分散なのかの違い




















手順:

1)マニュフェストを作成してみます。


ポイント:

以下にすることがポイント。

type: ClusterIP

cluster: Node













































2)digコマンドで確認してみます。


“web-001.default.svc.cluster.local”にアクセスすることで、以下の3台のどれかに

交互にアクセスされる仕組みになります。

(負荷分散がされている。)



















実験:

念の為、curlコマンドを投入して確認したところ、3台のPodに

http 200コードが表示されていることが把握できた。

(curl web-001.default.svc.cluster.local)


<Pod1台目>





















<pod2台目>



















<Pod3台目>



2020年5月20日水曜日

Route53(CNAME追記)

①レコード作成
  ->サブドメインを作成する。(例: api.xxxxx-test.com)
②タイプ:CNAME

③TTL:即反映させていので、時間短めで

④値に、OrginサーバーのIP又はELBのDNSを指定する。
(今回、Beanstalk作成時に作成されたURLを指定)

⑤レコードセットの保存を押す。

2019年8月6日火曜日

external-dns

KubernetesユーザがクラウドプロバイダのWebコンソールやCLIを使わずとも簡単にDNSレコードを作成・更新してサービスを公開するために利用します。

2019年2月3日日曜日

DNSサーバーの種類について

◻️DNSサーバは大きく2種類に分類できる。


・キャッシュサーバ:クライアントから再帰問い合わせを受け付け、名前解決を代行する。

自分自身はドメインを管理しない。

・コンテンツサーバ:自分の管理しているドメインについて、問い合わせの回答を行う。

2019年1月3日木曜日

レジストラ(DNS)用語

◻️レジストリのデータベースへ権威ネームサーバを登録
前回BINDでDNSサーバを構築しました。その際にルートネームサーバへ、構築したDNSサーバ(権威ネームサーバ)を登録すべく設定しましたが、これだけでは名前解決はできません。他にも、ドメインを管理する「レジストリ」と呼ばれる組織にも、権威ネームサーバの情報を登録する必要があります。

◻️レジストリとレジストラ・登録代理業者の役割
DNSにおける「レジストリ」とは、登録されたドメイン名を一元管理する組織で、「comやjp」など「TLD(トップレベルドメイン)」ごとに存在します。レジストリには国ごとにルールの異なる「ccTLD(jpなど)」と、世界中で利用できる共通ルールの「gTLD(comやnetなど)」があります。具体例をいえば、jpドメインはJPRS、comドメインはVeriSignが管理・運営しています。

「レジストリ」はドメイン名とそれに属する情報のデータベースを管理し、専用のDNSサーバで情報を提供しています。名前解決をするには、このデータベースとDNSサーバ(親の権威ネームサーバ)に、BINDで構築したDNSサーバ(子の権威ネームサーバ)の情報を登録する必要があります。

※レジストラとは、登録者からドメイン名の登録申請を受け付け、その登録データをレジストリのデータベースに登録する機関です。

2018年12月9日日曜日

bind(内部DNSの作成メモ)

◻️環境:
ドメイン:digihide.local
bindサーバー:192.168.1.111

◻️必要なファイル類:
/var/named/chroot/var/named/named.ca
/var/named/chroot/var/named/1.168.192.in-addr.arpa.zone
/var/named/chroot/var/named/digihide.local.zone


1)named.confを編集する。

vi /var/named/chroot/etc/named.conf
**********************************************************************************************
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// See the BIND Administrator's Reference Manual (ARM) for details about the
// configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html

options {
        listen-on port 53 { any; };
//      listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { localhost; };

        /*
         - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
         - If you are building a RECURSIVE (caching) DNS server, you need to enable
           recursion.
         - If your recursive DNS server has a public IP address, you MUST enable access
           control to limit queries to your legitimate users. Failing to do so will
           cause your server to become part of large scale DNS amplification
           attacks. Implementing BCP38 within your network would greatly
           reduce such attack surface
        */
        recursion yes;

//      dnssec-enable no;
//      dnssec-validation no;

        /* Path to ISC DLV key */
//      bindkeys-file "/etc/named.iscdlv.key";
//      managed-keys-directory "/var/named/dynamic";

        pid-file "/run/named/named.pid";
//      session-keyfile "/run/named/session.key";
};


logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};



zone "." IN {
        type hint;
        file "named.ca";
};

zone "digihide.local" IN {
        type master;
        file "digihide.local.zone";
        allow-query { any; };
};

zone "1.168.192.in-addr.arpa" IN {
        type master;
        file "1.168.192.in-addr.arpa.zone";
        allow-query { any; };
};


//include "/etc/named.rfc1912.zones";

include "/etc/named.root.key";
**********************************************


2)正引きファイルので作成を行う。

vi /var/named/chroot/var/named/1.168.192.in-addr.arpa.zone
***************** 1.168.192.in-addr.arpa.zone *************
$TTL 1D
@       IN SOA  digihide.local. root.digihide.local. (
                                        0       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
                NS      ns.digihide.local.
111     IN      PTR     digihide.local.
**********************************************************


3)逆引きファイルのを作成する。

vi /var/named/chroot/var/named/digihide.local.zone
************ digihide.local.zone *************************
$TTL 1D
@       IN SOA  digihide.local. root.digihide.local. (
                                        0       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
                NS      ns.digihide.local.
@       IN      A       192.168.1.111
ns      IN      A       192.168.1.111
**********************************************************


4)以下、フォルダーの作成を行っておくこと。

mkdir -p /var/named/chroot/var/named/data/
mkdir -p /var/named/chroot/var/named/dynamic/
mkdir -p /var/named/chroot/var/named/slaves/
chgrp named /var/named/chroot/var/named/data/
chgrp named /var/named/chroot/var/named/dynamic/
chgrp named /var/named/chroot/var/named/slaves/
chmod 770 /var/named/chroot/var/named/data/
chmod 770 /var/named/chroot/var/named/dynamic/
chmod 770 /var/named/chroot/var/named/slaves/



5)cd /var/named/に移動する。
6)以下、コピーを行う。
cp named.loopback /var/named/chroot/var/named
cp named.empty /var/named/chroot/var/named
cp named.localhost /var/named/chroot/var/named
cp -r data /var/named/chroot/var/named


7)resolv.confを編集

vi /etc/resolv.conf
************************
nameserver 192.168.1.111


************************


8)サービスを起動する。

systemctl start named-chroot

2018年1月16日火曜日

resolve.conf

「/etc/resolv.conf」は、自分のマシンが利用するDNSサーバの情報(IPアドレス)

2017年12月4日月曜日

DNS 逆引き & 正引き

例)正引き  www.example.com → 192.0.2.100 
例)逆引き 192.0.2.100 → www.example.com

2017年11月11日土曜日

DNSサーバーの種類について

◻️DNS サーバの種類


自分の管理している情報を教えてあげるのがお仕事のDNSサーバ
他のDNSサーバさんに答えを教えてもらいに行くDNSサーバ

DNSサーバーに仕組みについて



◻️概要
1)www.digihide.jpというドメインを想定。
2)巨大な分散型のデータベースがあるイメージ
3)問い合わせのイメージ:ルートサーバ ->digihide ->www
    問い合わせを行う場合、ルートサーバから下層のDNSへ情報が降りてくる。

◻️DNSの正引き、逆引き名前解決
  • 名前文字列を渡して、それに対応するIPアドレスを求める――正引き
  • IPアドレスを渡して、それに対応する名前を求める――逆引き

(a): 国別コードのDNSになる
(b): 自分が建てたDNS

(c)Webサーバなど

【AI×GitOps】Docker Composeから始めるRaspberry Pi 5 Kubernetesクラスタへの自動デプロイ設計

現在構築を進めている動画管理システム開発において、いきなりKubernetes(K8s)に展開するのではなく、 Docker Composeを中間地点に挟んで段階的にK8s+Argo CD(GitOps)へ移行するアーキテクチャ設計 をまとめました。 Bionic(AIアシスタン...