Dns

通常我们为了防止自己域名邮箱被伪造，会通过配置SPF记录来限制域名邮箱可以外发的IP网段。SPF相关配置说明可以参考：https://support.google.com/a/answer/33786?hl=zh-Hans例如我个人的邮箱是托管在QQ企业邮箱，因此就设置了相关的SPF记录 SPF记录相对来说只是限制了外发邮件的IP段，但是当你的邮箱被人伪造后自己实际并不知道（虽然绝大部分邮件服务器都会把SPF检查不通过的邮件放入垃圾箱）。DMARC记录相对来说是SPF记录的一种加强，相关的说明见 https://dmarc.org/overview/ 。以个人邮箱的DMARC记录为例v：版本（纯文本；必要的）值为“DMARC1”，必须作为第一个标签。p：要求的邮件接收者策略（纯文本；必要的）表明接收者根据域名所有者的要求制定的策略。none：域名所有者要求不采取特定措施quarantine：域名所有者希望邮件接收者将DMARC验证失败的邮件标记为可疑的。reject：域名所有者希望邮件接收者将DMARC验证失败的邮件拒绝。rua：发送综合反馈的邮件地址（逗号分隔的DMARC URI纯文本列表；可选的）ruf：发送消息详细故障信息的邮件地址（逗号分隔的DMARC URI纯文本列表；可选的）sp：要求邮件接收者对所有子域使用的策略（纯文本；可选的），若缺省，则“p”指定的策略将应用到该域名和子域中。adkim：（纯文本；可选的；默认为“r”）表明域名所有者要求使用严格的或者宽松的DKIM身份校验模式，有效值如下：r: relaxed modes: strict modeaspf：（纯文本；可选的；默认为“r”）表明域名所有者要求使用严格的或者宽松的SPF身份校验模式，有效值如下：r: relaxed modes: strict modefo：故障报告选项（纯文本；可选的；默认为0），以冒号分隔的列表，如果没有指定“ruf”，那么该标签的内容将被忽略。0：如果所有身份验证机制都不能产生“pass”结果，那么生成一份DMARC故障报告；1：如果任一身份验证机制产生“pass”以外的结果，那么生成一份DMARC故障报告；d：如果消息的签名验证失败，那么生成一份DKIM故障报告；s：如果消息的SPF验证失败，那么生成一份SPF故障报告。那么我这个dmarc的作用就是，告诉收件服务器将dmarc检查失败的邮件标记为可疑，并将综合反馈邮件和详细的信息都发送到我的个人邮箱。 当配置了dmarc记录后，各邮件服务器会加强对邮件源的检查从邮件头，可以看到gmail有对dmarc记录做校验。

bind 9.11 实际已经发布很久了，之前是简单的做过测试,简单做个总结。从功能上说9.11的几个特点：1. 持续完善了9.10 开始有的prefetch 功能2. 相比9.10 RPZ 的性能得到提升。3. 支持了dnstap。4. 支持了Catalog zone，zone的增加删除更加方便。5. 终于支持了ECS（EDNS Client-Subnet）。 9.12在9.11的基础上主要是新增了1. stale-answer ，递归失败的时候使用历史记录做响应。2. 完善了dnstap的文件轮转。 实际做了一些测试，简单的总结如下:1. 9.11.2 默认开始了cookie，实测9.11.2在递归的时候失败率相比9.9版本明显增加，性能上有少量的提升。2. dnstap对性能的影响比较小，关闭query log后 dnstap 关闭/开启的性能对比大概是13W/S VS 10W/S。相比传统的querylog的性能影响实在好太多了。但是因为是二进制的文件，查看需要用dnstap-read还是非常不方便的。3. 9.12的stale-answer还很不完善，最主要的问题是还是会先尝试同步做一次递归，失败了再用历史记录响应，测试中也经常出现找不到历史缓存的情况。目前了解是的akamai收购了nominum，这个patch应该是nominum 提供的。4. bind 9.10/9.11/9.12都支持了 EDNS Client-Subnet扩展协议，不过实际配置是比较脑残的。估计再等一两个版本会好一点。5. bind 9.11/9.12目前用于生产环境的风险还是比较高，建议企业用户继续使用9.9。整体来说这两年bind的发展相比之前还是快了很多，只是dns这个领域目前国内厂商因为国内运营商的各种奇葩要求做的工作还是很多的，无论是从性能，管控的便捷程度来说国内的成熟度都是超过国外的（除了对新扩展协议的跟进支持）。

1. tshark的安装 CentOS6 YUM源内的wireshark安装后，不支持GeoIP，需要自己编译一下最新的版本。 yum install GeoIP GeoIP-devel geoipup date -y ./configure –with-geoip=/usr/share/GeoIP/ –enable-tshark=yes make rpm-package wireshark自身Makefile带了各发型版的打包功能，所以直接make rpm-package就能make出rpm包 2. 使用范例 抓取DNS请求 sudo /usr/local/bin/tshark -i eth0 -o "ip.use_geoip:TRUE" -Y "udp.dstport == 53" -T fields -E separator='|' -e ip.src -e ip.geoip.src_country -e ip.geoip.src_asnum -e dns.flags -e dns.id -e dns.qry.name -e dns.qry.type -e dns.count.answers -e dns.count.answers -e dns.flags.rcode -e ip.len 抓到的内容如下： 211.138.19.28|China,China|AS24445 Henan Mobile Communications Co.,Ltd,AS24445 Henan Mobile Communications Co.,Ltd|0x00000010|0x0000355f|fxxxx.com|28||0||82 221.204.186.218|China,China|AS4837 CNCGROUP China169 Backbone,AS4837 CNCGROUP China169 Backbone|0x00000000|0x00004111|xxxx.com|1||0||75 123.157.135.3|China,China|AS4837 CNCGROUP China169 Backbone,AS4837 CNCGROUP China169 Backbone|0x00000000|0x00001108|xxxx.com|1||0||85 58.30.131.56|China,China|AS9811 srit corp.,beijing.,AS9811 srit corp.,beijing.|0x00000000|0x00005901|xxxxx.com|28||0||82 101.226.66.17|China,China|AS4812 China Telecom (Group),AS4812 China Telecom (Group)|0x00000010|0x00008d2a|xxxx.com|1||0||92 60.31.184.168|China,China|AS4837 CNCGROUP China169 Backbone,AS4837 CNCGROUP China169 Backbone|0x00000000|0x00005b22|xxxxx.com|1||0||79 60.31.184.168|China,China|AS4837 CNCGROUP China169 Backbone,AS4837 CNCGROUP China169 Backbone|0x00000000|0x0000da7e|lxxxx.com|1||0||74 74.125.176.202|United States,United States|AS15169 Google Inc.,AS15169 Google Inc.|0x00000000|0x0000ca93|xxxx.com|1||0||79 ...

9.11 中增加了多EDNS Client Subnet（ECS）的支持。但是目前网上都还没有相关的测试，仅仅在邮件列表有点没配置成功的咨询。在9.11中需要开启ECS需要在编译的时候指定Geoip yum install -y GeoIP ./configure –with-geoip=–with-geoip=/usr/share/GeoIP/ 目前bind的ACL中是把ECS 带的Client地址作为一个独立的特征做匹配 单ECS本身还是做IP地址匹配，非常容易与现有的地址匹配混淆。最开始以为可以这样搞 acl zone1 { ecs 10.0.0.0/8 ; 10.0.0.0/8; }; acl zone2 { ecs 172.0.0.0/8; 172.0.0.0/8; }; view "zone1" { match-clients {zone1; }; zone "test.org" { type master; file "zone/test.org" ; }; }; view "zone2" { match-clients {zone2; }; zone "test.org" { type master; file "zone2/test.org" ; }; }; 发现走10.0.0.0/8内的源地址带172.0.0.0/8的subnet时始终命中zone1，无法到达预期的效果。目前测试OK的配置只能是把ECS的ACL做独立的view匹配。而且鉴于bind acl并非是最精确匹配，只是线性匹配，配置的时候必须要把ecs view写在最前面，否则即使请求带了ECS OPTION，也会因为源地址先匹配到其他view而达不到效果。。 acl zone1 { ecs 10.0.0.0/8; 10.0.0.0/8; }; acl zone2 { ecs 172.0.0.0/8;172.0.0.0/8; }; acl ecs-zone1 { ecs 10.0.0.0/8; }; acl ecs-zone2 { ecs 172.0.0.0/8;}; ...

前几天同事反馈有个2000多个域名指向了自己的一台服务器，但是查询对应机器的PTR记录时发现只有1700多个。dig -x 查询了一下发现确实只有1700多个，检查了对应的zone文件内PTR记录是有2000多个的。偶然发现dig返回的MSG SIZE到了65519 在RFC1035中提到了DNS的几个限制：labels 63 octets or lessnames 255 octets or lessTTL positive values of a signed 32 bit number.UDP messages 512 octets or less整个UDP的消息被限制在512，不过随着后来EDNS0扩展协议（rfc2671），UDP的报文是可以到4096的(最大可以到65535)。在查询同事提供的PTR记录时，请求本身被TC置位走了TCP，因次这个UDP的限制无关的。DNS的限制实际在协议上 All RRs have the same top level format shown below: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: NAME an owner name, i.e., the name of the node to which this re source record pertains. TYPE two octets containing one of the RR TYPE codes. CLASS two octets containing one of the RR CLASS codes. TTL a 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be ...

以一个阿里云VM上的输出为例 [root@CentOS ~]# ntpq -pn remote refid st t when poll reach delay off set jitter ============================================================================== 127.127.1.0 .LOCL. 10 l - 64 0 0.000 0.000 0.000 #2001:4860:4806: 71.79.79.71 2 u 1012 1024 357 280.158 -15.630 3.135 #2001:4860:4806: 71.79.79.71 2 u 816 1024 377 262.399 -24.971 2.702 #2001:4860:4806: 71.79.79.71 2 u 708 1024 377 364.687 -13.306 4.368 #2001:4860:4806: 71.79.79.71 2 u 606 1024 377 381.816 -28.115 3.897 *182.92.12.11 10.137.38.86 2 u 327 1024 377 0.245 0.810 0.792 ...

大家在维护DNS的时候会有一个烦恼，很难平衡几个点1. 域名的平均解析时间要很短– 因为网站访问的时候所有得请求都需要依赖DNS解析，如果网站的访问量小，用户每次请求时需要先等递归DNS递归，整体的时间会很长。2. 机房故障的时候切换要快– 有多IDC的人都会面临一个问题，单个IDC故障的时候希望能尽快通过DNS将流量切换到另外的一个IDC，这个时候需要TTL短。3. DNS的部署成本– 正常网站的dns其实都不大的，如果没有攻击，4个机器跑个bind也能支撑国内BAT的一起的DNS解析。– 如果我们希望DNS的解析效果好，就需要在部署位置、接入网络等各方面想办法优化，成本也是指数增加。 不同频率的DNS解析任务来统计DNS的解析时长,可以分析一下网站访问量，域名TTL和用户侧平均DNS解析耗时之间的一些关系。 上图是相同TTL的域名，在访问频率不同的场景下的对比，可以看出随着监控域名的解析频率从1分钟下降到5分钟一次后，DNS的解析时间从66ms增加到85ms。 再从相同监控频率，不同TTL的解析这个维度来看 随着TTL从60s提升到120s，DNS的平均解析时间从66ms下降到59ms。再看看当TTL提升到600s的时候，DNS的平均解析时间下降到 47ms左右。 基于以上场景对比，我们可以有结论：1. TTL适当增加，DNS的延迟可以大幅下降。2. 网站访问量的增加，DNS延迟也可以有大幅下降。 DNS在用户终端的平均解析时间其实很难对比，也不存在完美的最佳实践。对一般中小企业，建议：1. DNS的TTL 300-600S，如果访问量不是很大，不建议TTL下降到120以下。2. 机房切换的容忍时间5-10分钟。

需求 有时需要从zone文件里解析DNS的数据，做一些分析。可以利用dnspython库做zone的解析处理。简单写一个如下 #!/usr/bin/env python import dns.zone import dns.ipv4 import os.path import sys import os import string import re zonefile=sys.argv[1] name=sys.argv[2] class LOAD_ZONES: def __init__(self,zonefile,name): self.types=("A","CNAME","TXT","SOA","MX","NS","PTR") self.record=dict() self.zonefile=zonefile self.name=name for type in self.types: self.record[type]=dict() try: zoneload= dns.zone.from_file(f=self.zonefile,origin=self.name,check_origin=False,relativize=False) for type in self.types: for (name, ttl, rdata) in zoneload.iterate_rdatas(type): dname=str(name) l = self.record[type].get(dname) if l is None: self.record[type][dname] = set() if type == “A”: self.record[type][dname].add( ("%s-%s") % (ttl,rdata.address ) ) else: self.record[type][dname].add( ("%s-%s") % (ttl,rdata.to_text().lower()) ) except dns.zone.NoSOA: print “%s no soa” % self.zonefile except dns.zone.NoNS: print “%s no ns” % self.zonefile def dump_record(self): for type in self.types: for k in self.record[type].keys(): print k,type,self.record[type][k] def del(self): pass ...

近期内部的递归服务器上有大量的AAAA查询，因为一些非主流NS的不响应AAAA记录，使得递归服务器上递归量比较大。bind9内开始支持filter-aaaa-v4/v6，主要的作用其实只是对相应的报文里作删除AAAA记录（如有）。单独验证了一下 filter-aaaa-on-v41.1 默认为no如果有AAAA记录会全量返回 AAAA记录如果没AAAA记录返回NOERR＋SOA1.2 设置为yes（Client IP为IPV4）如果有AAAA记录会被删除返回返回NOERR＋SOA如果没AAAA记录返回NOERR＋SOA1.3 设置为yes（Client IP为IPV6）行为不受影响。2. filter-aaaa-on-v62.1 默认为no如果有AAAA记录会全量返回 AAAA记录如果没AAAA记录返回NOERR＋SOA2.2 设置为yes（Client IP为IPV4）行为不受影响。2.3 设置为yes（Client IP为IPV6）如果有AAAA记录会被删除返回返回NOERR＋SOA如果没AAAA记录返回NOERR＋SOA filter-aaaa即便打开，当用户查询AAAA的时候bind也会去递归查询AAAA记录，所以并不能解决bind递归量大的问题。虽然可以通过iptables丢掉AAAA的包，但是也会影响用户的体验。

bind rpz和rrl作为bind 10里默认包含的2个模块，为bind的安全提供了有力的支撑。但实际使用不当会事得其反。 [ response-policy { zone zone_name [ policy (given | disabled | passthru | drop | nxdomain | nodata | cname domain) ] [ recursive-only yes_or_no ] [ max-policy-ttl number ] ; [...] } [ recursive-only yes_or_no ] [ max-policy-ttl number ] [ break-dnssec yes_or_no ] [ min-ns-dots number ] [ qname-wait-recurse yes_or_no ] ; ] 在服务器上配置如下的rpz策略 response-policy { zone “rpz.zone” policy given; } zone "rpz.zone" { type master; file "master/rpz.zone"; }; zone "lala.com" { type forward; forwarders { 8.8.8.8; }; }; rpz.zone内配置如下的内容，请求www.test.fr和*.lala.com都会阻塞很久，因为虽然我们做了策略，实际bind还是会等着取回结果再去操作。 $TTL 30 ...