Master_DNS

DNSはrequestとresponseが同じ系形式のUDPパケットでやり取りされるプロトコルである。 で、実はdigがdnsプロトコルのパケット内容を忠実に再現しているのです。だから、これマスターするDNSがほぼ分かったということになります。 関連ドキュメント ハンズオンの ハンズオンを紹介しているやつ rfsの読み方を説明している資料 ルートDNSの場所 digコマンドでの遊び方 digでの遊び方 dnsの全体像 dig関連 digの基本的なオプション +noedns : tcpで問い合わせ +norec : 非再起問い合わせを強制する。 qr : queryレスポンス rd : recursion desired : 再起問い合わせ要求。(Set by the sender of the request if the server should attempt to resolve the query recursively if it does not have an answer readily available.) ra : recursion available : 再起問い合わせ対応が可能か?(Set by the server to indicate whether or not recursive queries are allowed.) 基本的に、名前解決と言ったら8.8.8.8などのDNSキャッシュサーバが再起問い合わが実行して返してくれる。 しかし、権威DNSは再起問い合わせができないからね。 rdがついてもraがなかったら非再起問い合わせができないということになります。いくつかみてみましょうか? いくつかDNSレコードを送ってみましょうか? dig @1.1.1.1 +norec blog.ingenboy.com ; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> @1.1.1.1 +norec blog.ingenboy.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21079 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;blog.ingenboy.com. IN A ;; Query time: 1 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) ;; WHEN: Thu Aug 22 09:05:47 JST 2024 ;; MSG SIZE rcvd: 46 +norecをつけたのでDNSサーバは非再起問い合わせで名前解決ができません。そのため、answer sectionがないわけですね。 つまり、名前解決できなかったわけです。それにもかかわらずGot answerって書いているのはタチが悪いよね。 ...

August 4, 2024 · 4 min · 757 words · Me

ルータ+DHCPサーバ+DNSサーバ+K8Sコントロールプレーン on Raspi 5 with 8GB RAM(下書き)

背景 ついにインフラエンジニアになった。インフラエンジニアになったのであれば、インフラ関係を一通りこなせないと話にならないだろう! というお話です。ということで、クラスタ作って、クラスタがいい感じに運用できるようにいろいろとインフラを構築していこうと思う。 さらに言うと、業務でansibleを使っているので、IaC(インフラストラクチャasコード)を実現したいと思っている。これができればいつでもそのインフラが再現可能になるからね。練習も込みで。 要件 完全に独立したネットワークを構築したいと思っている。そのため、 ルータ が必要。この時、内部ネットワークから外部にアクセスする必要がないよね。だから、natでいいわけだね。 次に、サブネット内でDHCPをしつつ、アドレスの固定を一括で管理したい。 それの実現方法がDHCPを使って、macアドレスとipを対応付けるという方法。 さらに、ネットワーク内で、ipアドレスではなく、ドメイン名でアクセスができるようにしたいので、DNSサーバも立てたい。 最後、K8Sのコントロールプレーンだね。これは作りたい。 K8Sサーバに何を立てるかだけど、とりあえずechoサーバを立てて負荷試験をやってみたい。そうだね。将来的には配信サーバなどを立てられるといいのだけれど 後は、prometheus + graphanaで、負荷を可視化できるとなおいいよね。時系列でどれくらい負荷がかかっているのかが見れると最高だと思います。 各サーバにいちいち入るのは面倒くさいので一括でsshしたいと思っています。これを可能にする方法を岡田さんが考えてくれました。 msshですね。 各物理サーバ(ラズパイ)のハードウェアスペック router : raspi 5. RAM 8G. Storage 128G beta : raspi 4. RAM 1G. Storage 32G delta: raspi4. RAM 4G Storage 64G phi (f): raspi4. RAM 8G. Storage 32G gamma: raspi4. RAM 8G Storage 128G omega: raspi4. RAM 1G storage 32G zeta: raspi4. RAM 8G ここから使える奴だけ選抜する。 router, delta, phi, gamma, zeta の5台。一台は、router + dhcp + dnsの役割を持たせる。 容量的にdeltaがよさそう。そのほかは、k8sクラスタになる。頑張ってくれ。 k8sちゃんと動いてくれ!! ちなみに、 ...

July 27, 2024 · 12 min · 2518 words · Me

GSLB_and_DNS

GSLBとは はい、GSLB(Global Server Load Balancing)について知っています。GSLBは、複数の地理的に分散したサーバー間でネットワークトラフィックを効果的に分散するための技術です。これにより、以下のような利点が得られます。 高可用性: サーバーの障害が発生した場合でも、トラフィックを他の健全なサーバーにリダイレクトすることでサービスの継続性を確保します。 負荷分散: トラフィックを複数のサーバーに分散することで、特定のサーバーに過負荷がかかるのを防ぎます。 低遅延: ユーザーに最も近いサーバーにトラフィックをルーティングすることで、応答時間を短縮します。 災害復旧: 地理的に分散したサーバーを利用することで、特定地域での災害や障害に対する耐性を向上させます。 GSLBは、DNSベースの方法や、アプリケーション層でのルーティングを使用して実現されることが一般的です。具体的な実装方法や製品には、以下のようなものがあります。 DNSラウンドロビン: 最も基本的なGSLBの方法で、DNSサーバーが複数のIPアドレスを順番に返すことで負荷を分散します。 Anycast: 同じIPアドレスを複数の地理的に分散したサーバーに割り当て、最も近いサーバーにトラフィックをルーティングします。 商用製品: F5 NetworksのBIG-IP、CitrixのNetScaler、Amazon Web ServicesのRoute 53など、さまざまな商用ソリューションがあります。 GSLBは、大規模なWebサービスやクラウドサービスでよく利用される技術です。 僕の質問 一般ユーザはDNSを介してどのサーバにアクセスするかがきいまると思います。また、DNSは裏でGSLBと繋がっていて、一般ユーザー>DNS -> GSLBという流れでリクエストが流れると思います。この認識は合っていますか? chatGPTの回答 基本的な認識は合っていますが、もう少し詳細に説明すると、DNSとGSLBの関係は次のようになります。 一般ユーザーのリクエスト: 一般ユーザーがウェブサイトにアクセスしようとすると、まずDNSリクエストが発生します。このリクエストは、ユーザーが入力したドメイン名をIPアドレスに変換するためのものです。 DNSサーバーの役割: DNSサーバーは、このドメイン名に対応するIPアドレスを返します。ここで、GSLBがDNSサーバーに組み込まれているか、もしくはGSLBがDNSサーバーと連携しています。 GSLBの動作: GSLBは、複数の地理的に分散したサーバーの中から最適なサーバーを選択し、そのサーバーのIPアドレスをDNSサーバーに返します。選択基準には、サーバーの負荷、地理的な距離、ネットワークの遅延などが含まれます。 DNSの応答: DNSサーバーは、GSLBから受け取った最適なサーバーのIPアドレスをユーザーに返します。 ユーザーのアクセス: 最終的に、ユーザーのブラウザは返されたIPアドレスを使って直接サーバーにアクセスします。 この流れを図にすると以下のようになります: mermaid sequenceDiagram participant User as 一般ユーザー participant DNS as DNSサーバー participant GSLB as GSLBシステム participant Server as 最適なサーバー User->>DNS: ドメイン名の解決リクエスト DNS->>GSLB: 最適なサーバーのIPアドレスを要求 GSLB->>DNS: 最適なサーバーのIPアドレスを返す DNS->>User: IPアドレスを返す User->>Server: サーバーにアクセス このように、一般ユーザーのリクエストは最終的にはDNSを介してGSLBによって選ばれた最適なサーバーに到達します。DNSはGSLBと連携して動作し、ユーザーに最適なサーバーのIPアドレスを提供します。 ...

July 9, 2024 · 2 min · 276 words · Me