f78fk的博客

2026年8月23日星期日

dig → drill 对照表

用途	dig	drill
A 记录	`dig example.com A @1.1.1.1 +tcp`	`./drill -t example.com A @1.1.1.1`
AAAA 记录	`dig example.com AAAA @1.1.1.1 +tcp`	`./drill -t example.com AAAA @1.1.1.1`
MX 邮件服务器	`dig example.com MX @1.1.1.1 +tcp`	`./drill -t example.com MX @1.1.1.1`
NS 权威 DNS	`dig example.com NS @1.1.1.1 +tcp`	`./drill -t example.com NS @1.1.1.1`
TXT	`dig example.com TXT @1.1.1.1 +tcp`	`./drill -t example.com TXT @1.1.1.1`
CNAME	`dig example.com CNAME @1.1.1.1 +tcp`	`./drill -t example.com CNAME @1.1.1.1`
SOA	`dig example.com SOA @1.1.1.1 +tcp`	`./drill -t example.com SOA @1.1.1.1`
PTR 反向解析	`dig -x 8.8.8.8 @1.1.1.1 +tcp`	`./drill -t -x 8.8.8.8 @1.1.1.1`
DNSSEC / RRSIG	`dig example.com A @1.1.1.1 +dnssec +tcp`	`./drill -t -D example.com A @1.1.1.1`
DS	`dig example.com DS @1.1.1.1 +tcp`	`./drill -t example.com DS @1.1.1.1`
DNSKEY	`dig example.com DNSKEY @1.1.1.1 +dnssec +tcp`	`./drill -t -D example.com DNSKEY @1.1.1.1`
查看版本	`dig -v`	`./drill -v`
查看帮助	`dig -h`	`./drill -h`

2026年8月12日星期三

RT Linux + ARM GPIO PPS 实现纳秒级 GPS 授时（Chrony RMS Offset 40ns）

在 Zynq-7000 ARM SoC 上，通过 GPS M8N 输出 PPS 信号，经 Zynq EMIO GPIO 接入 Linux PPS Framework，使用 Chrony 驯服系统时钟。

在 PREEMPT_RT 内核和 OpenWrt Snapshot 环境下，最终 RMS Offset 稳定在 40ns 左右。

Reference ID : 47505300 (GPS)
Stratum : 1
Ref time (UTC) : Thu Jun 25 22:11:38 2026
System time : 0.000000042 seconds slow of NTP time
Last offset : -0.000000018 seconds
RMS offset : 0.000000040 seconds
Frequency : 12.248 ppm slow
Residual freq : -0.000 ppm
Skew : 0.001 ppm
Root delay : 0.000000001 seconds
Root dispersion : 0.000017178 seconds
Update interval : 16.0 seconds
Leap status : Normal
root@OpenWrt:~#

RMS offset = 0.000000040 seconds

换成纳秒：= 40 ns

也就是 0.040微秒

硬件设备：MYS-7Z020-V2-0E1D-766-C

Linux kernel :7.0.1 为了尽可能减少抖动，编译了 PREEMPT_RT 模式

RootFS: OpenWrt Snapshot

GPS模组 u-blox NEO-M8N

PPS ：GPS PPS -> Zynq EMIO -> GPIO IRQ -> Linux PPS

Chrony:
Stratum-1

将 PPS 中断处理线程调整为 SCHED_FIFO 高优先级，
以降低系统负载下的调度抖动。

2026年8月3日星期一

TL-XDR5480 WPA2/WPA3混合模式存在WPA3 SAE认证异常

平时经常遇到手机一开始连接正常，但是用了一段时间，比如用了2天，iphone会提示无法加入网络。

重启iPhone无法恢复
修改iPhone私有Wi-Fi地址(更换一个MAC地址)后立即恢复

终端 iphone8 iphone15pro ipad9代都遇到过。

无线设置: 关闭双频合一，5GHZ 149信道 80MHZ 加密方式：WPA2/WPA3混合

固件版本：TL-XDR5480易展Turbo版 1.0.46 Build 251121 Rel.51162

抓包发现失败时，iPhone8持续发送WPA3 SAE Commit认证请求：

tshark -r debug-01.cap -Y "wlan.addr == ca:a5:3e:4e:bd:47"

└─# tshark -r debug-01.cap -Y "wlan.fc.type_subtype in {0x0000, 0x0001, 0x000a, 0x000b, 0x000c} || eapol"
Running as user "root" and group "root". This could be dangerous.
  172    9.117803 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=1083, FN=0, Flags=........
  221   10.117926 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=1084, FN=0, Flags=........
  252   11.118445 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=1085, FN=0, Flags=........
  263   12.118627 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=1086, FN=0, Flags=........
  281   13.306160 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3905, FN=0, Flags=........
  311   14.306508 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3906, FN=0, Flags=........
  320   15.306614 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3907, FN=0, Flags=........
  327   16.306629 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3908, FN=0, Flags=........
  369   23.068550 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3559, FN=0, Flags=........
  372   24.068452 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3560, FN=0, Flags=........
  395   25.068732 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3561, FN=0, Flags=........
  452   26.069101 Apple_4e:bd:47 → TpLinkTechno_a8:70:bf 802.11 128 Authentication, SN=3562, FN=0, Flags=........
                                                                                                                         
┌──(root㉿kali)-[/home/kali]
└─#

┌──(root㉿kali)-[/home/kali]
└─# tshark -r debug-01.cap -Y "frame.number == 172" -V
Running as user "root" and group "root". This could be dangerous.
Frame 172: Packet, 128 bytes on wire (1024 bits), 128 bytes captured (1024 bits)
    Encapsulation type: IEEE 802.11 Wireless LAN (20)
    Arrival Time: Aug  3, 2026 15:56:12.129792000 UTC
    UTC Arrival Time: Aug  3, 2026 15:56:12.129792000 UTC
    Epoch Arrival Time: 1785772572.129792000
    [Time shift for this packet: 0.000000000 seconds]
    [Time delta from previous captured frame: 22.581000 milliseconds]
    [Time since reference or first frame: 9.117803000 seconds]
    Frame Number: 172
    Frame Length: 128 bytes (1024 bits)
    Capture Length: 128 bytes (1024 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wlan]
    Character encoding: ASCII (0)
IEEE 802.11 Authentication, Flags: ........
    Type/Subtype: Authentication (0x000b)
    Frame Control Field: 0xb000
        .... ..00 = Version: 0
        .... 00.. = Type: Management frame (0)
        1011 .... = Subtype: 11
        Flags: 0x00
            .... ..00 = DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x0)
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = +HTC/Order flag: Not strictly ordered
    .000 0000 0011 1100 = Duration: 60 microseconds
    Receiver address: TpLinkTechno_a8:70:bf (f8:6f:b0:a8:70:bf)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Destination address: TpLinkTechno_a8:70:bf (f8:6f:b0:a8:70:bf)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Transmitter address: Apple_4e:bd:47 (c0:a5:3e:4e:bd:47)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source address: Apple_4e:bd:47 (c0:a5:3e:4e:bd:47)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    BSS Id: TpLinkTechno_a8:70:bf (f8:6f:b0:a8:70:bf)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    .... .... .... 0000 = Fragment number: 0
    0100 0011 1011 .... = Sequence number: 1083
    [WLAN Flags: ........]
IEEE 802.11 Wireless Management
    Fixed parameters (104 bytes)
        Authentication Algorithm: Simultaneous Authentication of Equals (SAE) (3)
        Authentication SEQ: 0x0001
        Status code: Successful (0x0000)
        SAE Message Type: Commit (1)
        Group Id: 256-bit random ECP group (19)
        Scalar: 65913c740176dfc6121118ee5676fd87f6c155fc2ac5e640ed682d82e9c8d2fc
        Finite Field Element: 21f1187582cfd2b7ca85884b982e53f31b4b48c32046e7a5fb6e85ba0145197ce3912f50df200cbb8af7dd35aea65b62f0d60bde75086d26b6442d8f1a29c8a6

                                                                                                                         
┌──(root㉿kali)-[/home/kali]
└─#

抓包中未发现5480回复对应的SAE Commit/Confirm帧。

可能的原因：
WPA2/WPA3混合模式下，AP侧WPA3 SAE认证状态机或相关缓存释放异常，导致该STA MAC后续SAE认证流程无法继续。

解决方法：
由于TPLINK 没有提供 WPA2 Only 或 WPA3 Only 模式，
所以妥协的方案，使用WPA-PSK / WPA2-PSK 混合模式。(我自己是更换了其他支持 WPA2 Only 和 WPA3 Only 的无线路由器)。

从极简工程与减少驱动 Bug 的角度来看，更合理的界面加密选项其实只需保留 3 种：

 1. WPA2-PSK (AES)
   默认模式，兼容性最好，适合 2006年至今绝大多数 Wi-Fi 设备，
   包括大量旧款智能家居设备（IoT摄像头、扫地机器人、打印机等）。
 
2. WPA3-SAE
   新一代个人无线安全标准，2019年至今的新款主流设备普遍支持，
   提供更强的密码安全保护。
 
3. Open
   无密码开放网络，适用于访客或公共访问场景。

要99.999%的兼容性+安全选择WPA2-PSK(AES)，家里没有老设备，想要更安全的选择WPA3-SAE。

2026年6月27日星期六

中兴F7015TV3光猫删除TR069

// 查看TR069的数字

sendcmd 1 DB p WANC

// 删除TR069

sendcmd 1 DB delr WANC 0

2026年4月30日星期四

CVE-2026-31431 漏洞验证和临时修复方案

昨天披露了一个漏洞，CVE-2026-31431。

简单说就是普通用户一旦拿到shell，就可以利用该漏洞直接提权到root。

漏洞验证：

git clone https://github.com/rootsecdev/cve_2026_31431.git

cd cve_2026_31431

python3 test_cve_2026_31431.py

echo $?

返回 0 ：无漏洞，安全的。

返回 2：有漏洞

返回 1：测试错误

目前 Ubuntu 官方还没有推送补丁，

临时解决方案:

sudo tee /etc/modprobe.d/disable-algif-aead.conf <<<'install algif_aead /bin/false'

sudo rmmod algif_aead 2>/dev/null

官方推送新内核后，恢复模块:

sudo rm /etc/modprobe.d/disable-algif-aead.conf

sudo modprobe algif_aead

2026年4月29日星期三

ARM Cortex-A53 (无AES)平台加密网络转发性能测试与对比分析

1. 测试背景

本文基于 XG-140G-TF 设备（ARM Cortex-A53 四核，无AES硬件加密加速单元），测试其在不同网络数据转发架构实现方式的性能表现，用于评估其在局域网数据转发场景下的性能表现。

2. 测试环境

设备：XG-140G-TF
CPU：ARM Cortex-A53(1.2Ghz) ×4
加密能力：ARMv8 无 AES 硬件指令扩展
网络环境：千兆局域网
TLS加密套件：TLS_AES_128_GCM_SHA256（TLS 1.3）

3. 测试方案说明

方案A：内核级透明转发架构

基于操作系统网络栈的透明转发机制，实现数据包在内核层处理与转发。

方案B：用户态虚拟网络接口架构

基于用户态网络虚拟化技术，通过虚拟网卡进行数据封装与转发。

4. 性能测试结果

转发架构	吞吐性能
内核级透明转发架构	≈ 170 Mbps
用户态虚拟网络接口架构	≈ 120 Mbps

2026年4月22日星期三

固件发布 XG-140G-TF 极简 OpenWrt | 修复2.5G | NPU硬件加速

20260422：

【设备信息】

设备型号：Nokia Bell XG-140G-TF
系统版本：OpenWrt
Linux 内核：6.12.80

【固件简介】

本固件基于 OpenWrt 6.12 内核，针对 Nokia XG-140G-TF 进行 2.5G PHY 修复与 NPU 硬件 NAT 加速优化，可实现千兆满速下极低的 CPU 占用转发，系统结构保持极致精简。

【核心特性】

1. 完美修复 2.5G 网口
LAN1 默认作为 WAN (2.5GbE)
LAN2 / LAN3 / LAN4 为正常千兆 LAN
解决了市面部分固件 2.5G 网口无法驱动的问题，驱动已手工修复，测速稳定正常工作。

2. NPU 硬件 NAT 加速
可启用 nft flowtable + hw offload，支持 NPU 硬件加速转发。
固件已集成最新驱动：en7581-npu-firmware (20260410-r1) 与 en8811h-firmware (20260410-r1)。
实测 WAN → LAN NAT 满速 1Gbps 时，CPU 占用极低（不超过10%）。

3. 极致精简，纯净稳定
保留基础路由功能，拒绝臃肿。
仅内置：LuCI 中文界面、htop、iperf3。

4. 官方软件源支持
全面支持 apk update / apk add，实测官方软件源正常可用。

5. 性能与并发优化
默认连接数优化至 131072，大幅提升 NAT 并发连接能力。

6. 内存占用极低
开机仅占用约 100MB，空闲 RAM ≥ 200MB，极度适合做主路由长时间稳定运行。

【刷机方法】

1. 原始固件备份（非常重要）
官方固件开启 Telnet 后，请务必备份 mtd0-mtd17。由于该设备无 USB 口，需使用 TFTP 方式备份。
注意：请勿只备份 mtd18，实测因分区过大备份后的 MD5 校验不通过，必须逐个备份 mtd0-17。

# 备份命令示例（192.168.1.2 为你的 TFTP 服务器地址）

dd if=/dev/mtd0 | tftp -p -l - -r mtd0.bin 192.168.1.2

dd if=/dev/mtd1 | tftp -p -l - -r mtd1.bin 192.168.1.2

# 依此类推备份至 mtd17

2. 刷入 uboot
具体操作流程可参考：https://nwrt.kuroneko.host/flashdocs/XG-040G-MD.html

3. 刷入固件
设备通电等待 2 秒，用卡针长按 Reset 键不松手。
观察 LED 闪烁 5 次后松手，浏览器访问 192.168.1.1 进入刷机页面。
上传 openwrt...factory.bin 固件进行刷写。
后期更新：直接在 OpenWrt 管理后台“备份与更新”中上传 sysupgrade.bin 即可。

【使用说明：开启硬件 NAT】
注意：为保持系统初始纯净，默认未开启硬件 NAT 转发。
请在 OpenWrt 管理页面依次点击：网络 -> 防火墙 -> 路由/NAT 卸载，在“流量卸载类型”中选择“硬件流量卸载”即可生效。

【固件下载地址】

https://mbd.pub/o/bread/mbd-YZWcmJxpZg==

2025年10月8日星期三

分享一下 XG-140G-TF 光猫的使用教程

我主要分享的是解决思路，亲测最终实现了固化telnet和拥有了超密权限。

本帖隐藏的内容

0 拿到手的货首先自己手动复位一下，这样超级用户名和密码变成了 telecomadmin 和 nE7jA%5m
复位方法：

光猫启动完成后，用取卡针捅复位按钮5秒，直到光猫所有信号灯闪烁，说明光猫复位成功。

1 超密登录后改地区改成你所在的地区，比如山东。

http://192.168.1.1:8080/opid_setting.cg

2 超密登录后开启telnet 功能。

http://192.168.1.1:8080/system.cgi?telnet

3 超密登录后下载日志，搜索 SuPassword,val=后面的就是telnet的su密码，不用解密，明文密码就是密码。具体操作参考 https://www.right.com.cn/forum/thread-8403197-1-1.html或者参考下面的图片

http://192.168.1.1:8080/upgrade.cgi

4 telnet root 用户登录，密码就是上面读取到的SuPassword明文

5 插上光纤逻辑ID认证设置里填写ID注册

6 设置桥接路由器里拨号，或者光猫里手动填写PPPOE用户名密码拨号让其成功

7 telnet命令欺骗ITMS 让其显示注册成功，不然会拨号成功但是无法上网

cfgcli -s InternetGatewayDevice.X_CT-COM_UserInfo.Status 0
cfgcli -s InternetGatewayDevice.X_CT-COM_UserInfo.Result 1

8 因为注册后超密会被电信更改，所以 telnet里用命令重新设置超级密码改回nE7jA%5m

cfgcli -s InternetGatewayDevice.DeviceInfo.X_CT-COM_TeleComAccount.Password nE7jA%5m

此时就OK了，超级用户名和密码是 telecomadmin 和 nE7jA%5m
telnet用户名是：root 密码是：上文日志中获取到的SuPassword,val=后面的值。
其他可选命令：
关闭虚拟机

cfgcli -s InternetGatewayDevice.SoftwareModules.ExecEnv.1.Enable false
cfgcli -s InternetGatewayDevice.SoftwareModules.ExecEnv.2.Enable false

查看当前最大连接数设置

cat /proc/sys/net/netfilter/nf_conntrack_max

修改最大连接数为65535

echo 65535 > /proc/sys/net/netfilter/nf_conntrack_max

查看当前连接数

cat /proc/sys/net/netfilter/nf_conntrack_count

关闭环路检测

cfgcli -s InternetGatewayDevice.LANDevice.1.X_CT-COM_LoopbackDetection.LoopbackEnable false

关闭LED

oflt led off

教程适用于固件版本 V01.00.P00.X140TF

2025年8月6日星期三

XG-040G-XX SuPassword 解密工具

买了新光猫 XG-140G-TF , 所以写了一个 SuPassword 解密工具, 以备不时之需 .

适用于XG-140G-TF和XG-040G-MD.

点击下载

2025年8月1日星期五

Nginx Support for QUIC and HTTP/3

首先确保:

1 nginx 升级到 1.28.0 或者更新 .

2 防火墙放行 udp 443.

配置文件修改:

第一个 server 增加:

listen 443 quic reuseport;
listen [::]:443 quic reuseport;

ssl_protocols TLSv1.2 TLSv1.3;

http2 on;
http3 on;
add_header Alt-Svc 'h3=":443"; ma=86400';

完整示例:

server {
    listen 443 ssl ;
    listen [::]:443 ssl ;
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;
    server_name example.com;
    ssl_certificate /path/fullchain.pem;
    ssl_certificate_key /path/key.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';

    http2 on;
    http3 on;
    add_header Alt-Svc 'h3=":443"; ma=86400';

    root /var/www/html;
    index index.html index.htm index.php;
...
}

如果有多个 server 的话不允许再次

listen 443 quic reuseport;

否则会端口冲突。所以其余的 server 使用:

listen 443 quic;

例如:

第二个 server 增加:

listen 443 quic;
listen [::]:443 quic;
ssl_protocols TLSv1.2 TLSv1.3;
http2 on;
http3 on;
add_header  Alt-Svc 'h3=":443"; ma=86400';

更多的 server 同上。

BIND 9 CVE-2025-40777 漏洞分析与修复建议

最近关注到 BIND 9 中的一个较严重漏洞，编号为 CVE-2025-40777。
通过查阅文档，这个漏洞主要在递归服务器中出现，在特定配置下，遇到某些 CNAME 解析请求时，named 进程因断言失败崩溃，造成 DNS 服务不可用。

漏洞背景

漏洞出现在 BIND 的 serve-stale 功能上。serve-stale 作用是当上游服务器响应失败时，
允许使用过期缓存应答，从而保证解析的连续性和稳定性。

然而当配置文件中设置了 stale-answer-client-timeout 为 0，同时启用了 serve-stale，
遇到某些特殊的 CNAME 链解析请求时，named 进程会触发断言失败崩溃。

影响范围

BIND 9.20.0 到 9.20.10
BIND 9.21.0 到 9.21.9
BIND 9.20.9-S1 到 BIND 9.20.10-S1
9.18.0之前和9.18.11-S1之前的版本官方没有测试

默认情况下，serve-stale 是关闭的，且 stale-answer-client-timeout 也不是 0，
因此如果没有手动设置，一般不会受到影响。

如果没有开启递归，纯权威服务器不会受此漏洞的影响。

漏洞等级与风险

CVSS v3.1 基础分数：7.5（高危）
攻击者无需认证即可远程触发 DoS 攻击
攻击结果为 DNS 服务进程崩溃，导致解析中断
影响依赖该服务的系统和应用，可能造成网站访问失败、邮件中断、微服务不可用

漏洞原理简述

在处理递归查询时，serve-stale 允许返回过期的缓存答案以提高容错性。
但当 stale-answer-client-timeout 设置为 0，表示客户端不等待任何上游响应，
这与内部对 CNAME 链的处理逻辑发生冲突，最终导致断言失败。

临时解决办法

如果暂时无法升级，建议修改配置关闭此功能，避免崩溃：

options {  
  stale-answer-client-timeout off;  
  // 或者直接关闭 serve-stale  
  stale-answer-enable no;  
};

改完后请重启 named 服务生效。

漏洞来源

该漏洞最初由 ISC 官方披露，相关安全咨询也已提交至 GitHub Advisory 数据库，
详情见：https://github.com/advisories/GHSA-4x4c-8qp9-8ggh

2025年7月17日星期四

F7015TV3光猫固化Telnet

临时得到 Telnet 权限后，执行下面的命令来固化。

sendcmd 1 DB p TelnetCfg

sendcmd 1 DB set TelnetCfg 0 Lan_Enable 1

sendcmd 1 DB set TelnetCfg 0 TS_UName root

sendcmd 1 DB set TelnetCfg 0 TSLan_UName root

sendcmd 1 DB set TelnetCfg 0 TS_UPwd Zte521

sendcmd 1 DB set TelnetCfg 0 TSLan_UPwd Zte521

sendcmd 1 DB set TelnetCfg 0 Max_Con_Num 99

sendcmd 1 DB set TelnetCfg 0 ExitTime 999999

sendcmd 1 DB set TelnetCfg 0 InitSecLvl 3

sendcmd 1 DB set TelnetCfg 0 CloseServerTime 9999999

sendcmd 1 DB set TelnetCfg 0 Lan_EnableAfterOlt 1

sendcmd 1 DB save

F7015TV3光猫复位方法

开机时看到红灯在闪，就立刻按住复位键不要松，一直等到所有灯都亮了再松开，这样光猫就会自动恢复出厂设置了。

2025年7月14日星期一

手动修改 dynamic zone

# 冻结 zone（变为静态 zone，允许手动修改文件）

rndc freeze example.com

# 手动修改

vim /etc/bind/zones/example.com.zone

# 重新加载

rndc reload example.com

# 解冻（恢复 DDNS）

rndc thaw example.com

2025年7月13日星期日

Replace OpenWrt DHCP and DNS Servers with Kea DHCP4 and BIND9

This guide explains how to replace the default OpenWrt DHCP and DNS servers with Kea DHCP4 and BIND9.

1. Install BIND and Kea DHCP4

opkg update
opkg install bind-server bind-check bind-dnssec bind-tools kea-dhcp4

2. Remove OpenWrt's default dnsmasq and odhcpd-ipv6only

opkg remove dnsmasq odhcpd-ipv6only
uci -q delete dhcp.@dnsmasq[0]
uci commit dhcp

3. Install and Configure Kea DHCP4

Copy init script and configuration file:

cp ./kea-dhcp4/etc/init/kea-dhcp4 /etc/init/
cp ./kea-dhcp4/etc/kea/kea-dhcp4.conf /etc/kea/

Edit the DHCP server configuration:

vim /etc/kea/kea-dhcp4.conf

Start and enable Kea DHCP4 service:

/etc/init.d/kea-dhcp4 start
/etc/init.d/kea-dhcp4 enable

4. Configure BIND9 DNS Server

Edit the main configuration:

cp ./bind/etc/bind/named.conf /etc/bind/
vim /etc/bind/named.conf

(Optional) Edit zone files:

vim /etc/bind/db.liuyu.dns
vim /etc/bind/db.192.168.1

5. Configure OpenWrt to use local BIND DNS Server

Set WAN DNS to localhost:

uci set network.wan.dns='127.0.0.1'
uci commit network

6. Start and enable BIND service

/etc/init.d/named start
/etc/init.d/named enable

7. Other useful commands

Restart services if needed:

service kea-dhcp4 restart
service named restart

This setup replaces the default dnsmasq with a more flexible and robust Kea DHCP4 and BIND9 combination.

GitHub Repository: https://github.com/liuyuf78fk/isc-openwrt

2025年7月6日星期日

更新 PowerShell 7

winget install --id Microsoft.PowerShell --source winget

2025年6月22日星期日

验证递归DNS 是否支持DNSSEC

UDP:

dig +dnssec +multi nic.cz A

dig +dnssec dnssec-failed.org A

------------------------------------------------------------------------------------

DoH:

curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=nic.cz&type=A' --insecure

curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=nic.cz&type=RRSIG' --insecure

curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=dnssec-failed.org&type=A' --insecure

curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=dnssec-failed.org&type=RRSIG' --insecure

上面示例中测试的是 cloudflare的 dns 是否支持dnssec，所以测试自己的服务器需要替换成自己的DoH地址。

--------------------------------------------------------------------------------------

nic.cz 是配置了有效的 DNSSEC 签名，dnssec-failed.org 是故意配置了错误的DNSSEC 签名。

如果本地的DNS解析器支持DNSSEC的话，会返回下面的预期数据。

nic.cz 会返回 :
AD:true 代表已验证数据
type:46 代表返回了RRSIG
type:1 代表返回了正确的 IP 地址。

dnssec-failed.org 会返回 :
AD:false 代表没有通过DNSSEC验证，因为是伪造的签名
Status:2 代表 SERVFAIL
Answer:缺失没有返回 IP 地址的结果是预期的。

--------------------------------------------------------------------------------------

不是以上的预期数据的话,比如 dig +dnssec dnssec-failed.org A 结果依然返回了 IP 地址,没有返回SERVFAIL, 那就认为 DNSSEC 验证链路不完整。

在线自动验证 DNSSEC : https://ip.f78fk.com/dnssec

Ubuntu 24.04 导入自签证书到受信任的根证书颁发机构

1：

cp my.crt /usr/local/share/ca-certificates/

2:

sudo update-ca-certificates

3:

openssl s_client -connect ipaddr -servername your-domain

如果输出中显示:

Verify return code: 0 (ok)

就说明系统已经完全信任这个证书了。

2025年6月21日星期六

BIND 9.20.9 配置 DDNS 实现动态更新记录

这次例子为 home.example.com 动态更新 A 记录

主权威DNS：

首先增加home子域

vim /etc/bind/zones/example.com.zone

# 增加下面 2 行

$TTL 600 ; 10 minutes
home.example.com.     A    1.2.3.4

序列号记得加 1

# 使此 zone 增加的记录生效

rndc reload example.com

# 生成 SHA512 key

tsig-keygen -a HMAC-SHA512 ddnskey > /etc/bind/keys/ddnskey.key

# 配置文件里载入 key

vim /etc/bind/named.conf.local

# 包含刚刚的 key 文件

include "/etc/bind/keys/ddnskey.key";

# 修改 zone 策略, 允许使用 key 动态更新

zone "example.com" {
    type master;
    file "/etc/bind/zones/example.com.zone";
    allow-transfer {
        x.x.x.x;
    };
    also-notify {
        x.x.x.x;
    }; 
    allow-update { key ddnskey; };     // 增加这一句,表示允许使用 ddnskey.key 动态更新
};

# 使配置生效

rndc reconfig

然后把 /etc/bind/keys/ddnskey .key 文件拷贝到没有固定IP的主机

动态IP的主机：

# 测试更新 A记录是否能成功

nsupdate -k ./ddnskey .key <<EOF
server ns1.f78fk.net
zone example.com
update  delete  home.example.com.   A
update  add home.example.com.   600   A   6.6.6.6
send
EOF

# 验证

dig home.example.com

A 记录看到已经变成 6.6.6.6 了

全自动化:

git clone https://github.com/liuyuf78fk/F78FK-DDNS.git

cd F78FK-DDNS

根据 README 去做。

# 修改 auto_ddns_update.sh

ZONE="zone 名,在本例中此值为 example.com"
FQDN="需要更新的完整域名 (  本例中此值为 home.example.com.  )"
KEY="ddnskey.key 的绝对路径"
TYPE="A 记录或者 AAAA 记录"
TTL="TTL 值，DDNS 一般设置为 600 也就是10分钟"
DDNS_SCRIPT="f78fk.ddns_update.sh 的路径"
GET_IP_SCRIPT="getip.sh 的路径"
LOG=true 或 false 调试期间设置为 true，测试稳定后设置为 false

# 添加定时任务（每 15 分钟执行一次）

crontab -e

添加以下内容（路径根据实际修改）：

*/15 * * * * /home/<your_username>/F78FK-DDNS/auto_ddns_update.sh

之后系统会每隔15分钟检查IP如果有变化的话会自动更新 A记录到 DNS 服务器。

2025年6月19日星期四

BIND 9.20.9 配置 TSIG

主权威DNS

# 生成共享密钥

tsig-keygen sync-key

# 加载新密钥
vim named.conf

key "sync-key" {
    algorithm hmac-sha256; 
    secret               "DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY="; 
};

# 指示服务器使用密钥
vim named.conf.local

# 指示从 DNS1 更新zone需要共享密钥

server x.x.x.1 {    
     keys { sync-key ;}; 
};

# 指示从 DNS2 更新zone需要共享密钥

server x.x.x.2 { 
     keys { sync-key ;}; 
};

 zone "f78fk.net" { 
     type master; file "/etc/bind/zones/f78fk.net.zone"; 
     allow-transfer { 
            x.x.x.1;           //允许从 DNS1 更新zone
            x.x.x.2;           //允许从 DNS2 更新zone
         }; 
         also-notify {
             x.x.x.1;          //rndc reload后主动通知一次 DNS1 更新zone
             x.x.x.2;          //rndc reload后主动通知一次 DNS2 更新zone
         }; 
 };

从权威DNS 1

# 加载新密钥
vim named.conf

key "sync-key" {
    algorithm hmac-sha256; 
    secret               "DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY="; 
};

# 指示服务器使用密钥
vim named.conf.local

# 指定向主 DNS 更新 zone 时使用的共享密钥

server x.x.x.m {    
     keys { sync-key ;}; 
};

zone "f78fk.net" { 
     type slave; masters {
             x.x.x.m;    // 主 DNS 的 IP 地址
}; 
     file "/etc/bind/zones/f78fk.net.zone"; 
};

从权威DNS 2

# 加载新密钥
vim named.conf

key "sync-key" {
    algorithm hmac-sha256; 
    secret               "DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY="; 
};

# 指示服务器使用密钥
vim named.conf.local

# 指定向主 DNS 更新 zone 时使用的共享密钥

server x.x.x.m {    
     keys { sync-key ;}; 
};

zone "f78fk.net" { 
     type slave; masters {
                 x.x.x.m;    // 主 DNS 的 IP 地址
}; 
     file "/etc/bind/zones/f78fk.net.zone"; 
};

官网文档:

https://downloads.isc.org/isc/bind9/9.20.10/doc/arm/html/chapter7.html#generating-a-shared-key

订阅：博文 (Atom)

2026年8月23日星期日

2026年8月12日星期三

2026年8月3日星期一

2026年6月27日星期六

2026年4月30日星期四

2026年4月29日星期三

1. 测试背景

2. 测试环境

3. 测试方案说明

方案A：内核级透明转发架构

方案B：用户态虚拟网络接口架构

4. 性能测试结果

2026年4月22日星期三

【设备信息】

【固件简介】

【核心特性】

【刷机方法】

【固件下载地址】

2025年10月8日星期三

本帖隐藏的内容

2025年8月6日星期三

买了新光猫 XG-140G-TF , 所以写了一个 SuPassword 解密工具, 以备不时之需 .

2025年8月1日星期五

2025年7月19日星期六

漏洞背景

影响范围

漏洞等级与风险

漏洞原理简述

临时解决办法

推荐修复方案

漏洞来源

2025年7月17日星期四

2025年7月14日星期一

2025年7月13日星期日

1. Install BIND and Kea DHCP4

2. Remove OpenWrt's default dnsmasq and odhcpd-ipv6only

3. Install and Configure Kea DHCP4

4. Configure BIND9 DNS Server

5. Configure OpenWrt to use local BIND DNS Server

6. Start and enable BIND service

7. Other useful commands

2025年7月6日星期日

2025年6月22日星期日

1：

2:

3:

2025年6月21日星期六

主权威DNS：

动态IP的主机：

全自动化:

2025年6月19日星期四

主权威DNS

从权威DNS 1

从权威DNS 2