curl は POST や PUT でリクエストボディの長さが長いなどの特定条件になると、まず Expect: 100-continue をつけてリクエストを送り、サーバ側の対応を待ってからリクエストボディを改めて送るという行儀が良い実装になっている。

しかし、特に IoT っぽい機器では Expect: 100-continue に対応していないものもあるので、抑制したい場合がでてくる。そういうときは以下のようにする。

curl -H "Expect:" -d ... url

空の Expect ヘッダを指定することで上記のような挙動をしなくなり、最初からリクエストをフルで送りつけるようになる。

  1. トップ
  2. tech
  3. curl の Expect: 100-continue を抑制する

結論からいうと CAT6 か CAT6A を使う。33m までなら CAT6 でも良いことになっているので家庭なら CAT6 でも十分ということになる。ただ伝送帯域に余裕がないので、取り回しに問題がないなら CAT6A を使うほうが良さそう。

8P8C (RJ45) コネクタを使う CAT7 CAT8 規格は存在しない

簡単にいうと CAT7 CAT8 のコネクタは CAT6A 以前とは互換性がない。

ケーブルにいくら CAT7 CAT8 適合なものを使っても、コネクタに 8P8C (RJ45) を使う場合には CAT6A と同等の扱いとなる。ただの硬い CAT6A ケーブル。

また、CAT7 以上では STP なので、機器側でアースがしっかりとれていなければならない。家庭用機器でアースをとるものはほとんどない (接地用端子・接地極がついたコンセントがそもそも普及してない) で、この点でもやはり意味がない。

  1. トップ
  2. tech
  3. 10GBASE-T LANケーブル CAT6 CAT6A CAT7 CAT8

LAN向けのDNSキャッシュサーバ

経緯としてRTX1200 の DNS 機能が TCP フォールバックに対応してないのでオフにした、というのがある。直接 8.8.8.8 8.8.4.4 を DHCP で広告するようにしてみたが、RTT が 8ms ぐらいあるので、やはり LAN 内にキャッシュサーバがあったほうがいいかなと思いはじめた。

LAN内には常時動いている Raspberry Pi のホストがいるので、ついでにこのホストにDNS機能もやらせることにしてみた。

unbound

unbound がキャッシュサーバ専用でよさそうなのでこれにする。

sudo apt-get install unbound
#/etc/unbound/unbound.conf.d/my.conf   
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
server:
        verbosity: 1
        num-threads: 4
        interface: 0.0.0.0
        interface: ::
        msg-cache-size: 64m
        msg-cache-slabs: 4
        rrset-roundrobin: yes
        rrset-cache-size: 64m
        rrset-cache-slabs: 4
        infra-cache-slabs: 4
        access-control: 192.168.0.0/16 allow
        key-cache-size: 64m
        key-cache-slabs: 4
        neg-cache-size: 64m
        prefetch: yes
forward-zone:
    name: "."
    forward-addr: 8.8.8.8
    forward-addr: 8.8.4.4
# 自動起動
sudo systemctl enable unbound
# 起動
sudo systemctl start unbound
# ステータス
sudo systemctl status unbound
# ログ
sudo journalctl -r

以下のようなコマンドでクエリ数やキャッシュヒット率が見れる。

unbound-control stats_noreset | grep total

今後

キャッシュヒット率を見つつ、あんまり意味がなさそうなら (数%ぐらいしかヒットしないとか) やめるつもり。

自宅は昼間は誰もいないので、このタイミングでTTLが短いほとんどのキャッシュは無効になってしまう。unbound の prefetch は TTL が残り10%になったときにクエリがくると再問合せする機能なので、クエリがこなければ一切 prefetch はされない。

さらには一番影響がでるブラウザでは、DNS prefetch が実装されているので、体感的にはネットワークの近くにDNSがあっても意味がないことが多い。

自分で DNS キャッシュサーバを運用するコストと釣り合わないかもしれない。

(備考)raspberry pi の ip アドレスを固定

raspi の IP アドレスを固定しておく

#/etc/dhcpcd.conf 
interface eth0
static ip_address=192.168.0.222/24
static routers=192.168.0.1
static domain_name_servers=127.0.0.1
sudo systemctl daemon-reload
sudo systemctl stop dhcpcd
sudo ip addr flush dev eth0 ; sudo systemctl start dhcpcd
sudo systemctl restart avahi-daemon.service 

確認

dig @192.168.0.222 example.com

同一ホストで

sudo unbound-control stats_noreset | grep total
sudo unbound-control dump_cache
  1. トップ
  2. tech
  3. RaspberryPi を家庭内 LAN の DNS キャッシュサーバーに

127.0.0.1 より localhost のほうが書きやすいし良さそう、と思って localhost と書いているとしばしばハマります。

というかなんとなく localhost = 127.0.0.1 と考えがちではないでしょうか? そんなことはないので気をつけましょう。

最近のシステムなら /etc/hosts を確認すると少なくとも2つの localhost エントリを見ることができるでしょう。

127.0.0.1       localhost
::1             localhost 

上は IPv4、下は IPv6 です。localhost はどちらのアドレスにも解決しうるホスト名となっています。

どういうときにハマるか

例えば同一サーバでリバースプロキシを行ってバックエンドサーバと繋ぎこみを行う場合、フロントのリバースプロキシで localhost:5000 と書くと IPv4 IPv6 どちらでアクセスされるか不定です。バックエンドサーバが IPv4 しか bind していないと IPv6 アドレスが選択されたとき接続不可になります。

正しい方法

すべてのサービスで IPv4 IPv6 ともに接続可能にし、ホスト名でアクセスできるようにすること。

非公開な内部向けサーバとかだと割と IPv4 しか使えないようにしがちではないかと思いますが、ちゃんとやったほうが無難です。

次善の策

ホスト名でひける IP アドレスの種類と実際に受けつけるプロトコルの種類をあわせること。

localhost の替わりに 127.0.0.1 か ::1 を使ってプロトコルを明示すること。

localhost に限らない

実際にところは localhost に限らず、ホスト名でアクセスするときには必ず気をつけるポイントです。DNS で IPv4 IPv6 いずれのアドレスも解決できるようにするなら、そのホスト上で待ち受けるサービスは全てデュアルスタックになっていないと、あらぬところでハマったりします。

  1. トップ
  2. tech
  3. localhost と書くと IPv6 対応したときに死ぬことがある