FPs

Articles with the dns tag

ANAME、CNAME、DNAME

CNAME 很常见,一般人都很熟悉,将一个域名映射到另外一个域名。但是CNAME 有个限制,顶级域名(apex domain)不建议设置CNAME,因为会和MX 记录冲突,详细解释:为什么裸域名不可以设置 CNAME?#26

RFC1912:2.4 CNAME records

A CNAME record is not allowed to coexist with any other data. In other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you can't also have an MX record for suzy.podunk.edu, or an A record, or even a TXT record...

所以就诞生了ANAME,有些DNS 服务商叫做ALIAS,可以在apex domain 上实现类似CNAME 效果。第一次见到这个,是在配置Github Pages

Continue ->

基于OpenResty 的whoami.akaimai.net 实现

上次收集整理Local DNS 地址 的时候看到akamai 的whoami.akamai.net,想起之前看到agentzh 基于OpenResty实现了一个权威DNS 服务器,感觉可以用openresty 简单快速的实现。

找到agentzh 当时的 gist,第一次学习OpenResty ,决定照猫画虎。看起来要在OpenResty 里面接受dns 数据包,并且返回,需要用到stream-lua-nginx-module这个模块,这里要注意的时候,截至目前(2017-08-30) master 分支还不支持 ngx.req.udp_socket ,agentzh 当时hack 的代码都在 bloody-dns-server 分支下面。

Continue ->

获取Local DNS 地址信息

在网页中获取local dns 不太方便,看看大家是怎么做的。

阿里云CDN 诊断工具

阿里云CDN提供的阿里昆仑用户诊断工具
alicdn_local_dns

获取到local dns 的这个请求:

https://123-66-35-57-122894414.dns-detect.alicdn.com/api/cdnDetectHttps?method=commitDetectHttps&detectId=122894414&cb=jQuery110102821084573750223_1503489263656&_=1503489263658

一个奇怪的域名,每次访问都不一样:
123-66-35-57-122894414.dns-detect.alicdn.com
设备ID :
detectId=122894414

用户访问一个域名,浏览器给按照分配的local dns 发起dns 迭代查询,最后向域名的权威服务器名查询,最后这一步的时候可以得到local dns 的地址。

Continue ->

监控所有NameServer的SOA 记录的序列号

使用Bind DLZ或者其他方式搭建了权威DNS,为了高可用的话,肯定会有多组NameServer。 除了常规的监控外,还需要监控所有SLave 的NS 的SOA 序列号(Serial Number)是否和Master 一致,如果落后的话需要报警,有时候也有可能Master NS生成的记录有错,无法同步到Slave NS,也有可能是权限方面出错等等,总之,这个监控非常有必要。

关于SOA 记录的介绍可以参考:DNS SOA 记录的结构

@   IN  SOA     nameserver.place.dom.  postmaster.place.dom. (
                           1            ; serial number
                           3600         ; refresh   [1h]
                           600          ; retry     [10m]
                           86400        ; expire    [1d]
                           3600 )       ; min TTL   [1h]

使用dig 命令向特定NameServer 查询特定域名的SOA 记录:

> dig @NS_IP domain soa
>>dig @114.114.114.114 google.com soa

> dig @NS_IP domain soa +short #返回简短的结果
>> dig @8.8.8.8 google soa +short
Continue ->

Bind DLZ With MySQL

前言

要做好运维自动化,内网域名的自动化管理不可少,得提供丰富的API 供其他内部系统调用。
之前在网易杭研实习,见过他们管理内部的域名,还是手工编辑bind 的zone 文件,苦不堪言,改一个得反复检查和找人Review,因为zone 如果出现一丝错误,会导致大量域名解析出错。一个方式是用DNSPod,CloudXNS等,这些服务商一般都有完善的API 支持,但是这样内网域名就暴露在公网,可被人暴力遍历,为渗透之类的提供信息,所以内网自己搭建一个权威DNS 服务器是更好的选择。

Name server 的选择上,有很多选择,如Bind, PowerDNS, NSD 等。PowerDNS 对MySQL 有原生支持, 性能上相对Bind DLZ MySQL 会强很多,并且有非常多开源的WebFrontend 支持。不过我最终还是选择了Bind DLZ,性能的问题可以通过后文提到的架构解决掉,并且还可以省去对 MySQL 之类的优化工作,另外自己写一个对数据库的CRUD 操作的Web 界面并不困难,工作量也并不大。

性能与架构

Bind DLZ 官方提供了一份Performance Tests,虽然是比较老的测试了,但是还是有不少参考价值。
bind-dlz-perf-tests

我自己使用queryperf 压测,结果与上图中类似,基本来说Bind DLZ MySQL 相比Bind 原生的方式,QPS 差20倍左右,因为MySQL 只能跑在单线程下。由于这个原因,建议采用Bind DLZ 作为Master,Bind 作为Slave的方式。多个Slave 结合LVS 做高可用和负载均衡, Master可以另外针对Bind DLZ 和MySQL 做高可用,这样的设计,可以发挥Bind 原生的高性能,也可以利用Bind DLZ 的灵活性。
但是这样会带来一个问题,在Master 上修改完记录之后,可能不会立即同步到Slave,会带来不一致的问题。不过这个问题可以通过自动发送Notify 来解决掉。
bind-dlz

另外可参考:

DNS 查询走UDP 协议,前端转发这块一般用LVS + Keepalived 之类的做高可用,当然用最近出的Nginx UDP Stream 也可以,不过性能上差很多。
同时也需要优化一下服务器网络UDP 相关的参数。

Continue ->