知行小马哥
探索云世界
知行小马哥
行走江湖知行马。
在K8S集群中，默认每Worker节点最大可创建110个Pod，实际可以根据节点资源情况调整范围。在Woker节点上，可创建的Pod数量是作为Kubelet的参数出现的，因此修改Kubelet服务的配置文件增加 --max-pod 参数即可。在/usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf文件中增加环境配置 Environment="KUBELET_NODE_MAX_PODS=--max-pods=600" 并在启动命令尾部添加变量 $KUBELET_NODE_MAX_PODS 如下： ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS $KUBELET_NODE_MAX_PODS 然后执行 #systemctl daemon-reload #systemctl restart kubelet 检查配置是否生效 #ps aux|grep kubelet root 21659 30.6 2.7 5145384 221520 ? Ssl 10:26 124:23 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.2 --max-pods=6000
0x1 Spam定义 国内没有特别明确的垃圾邮件定义和相关法律条文，因此同其他网络术语一样需要参考国外的定义。垃圾邮件的英文为Spam或者Junk mail，通常分为包括UCE、UBE等几大类，之前还会明确包括URE和UPE，不过目前已从各大组织的定义中删除，这里主要介绍前两者。UCE(Unsolicited Commercial Mail)和UBE(Unsolicited Bunk Mail)都采用了Unsolicited这个单词，指“未经要求自动发出的”，在邮件环境中理解为“未经收件人主动订阅或浪费收件人时间的”，简单理解就是未经收件人主动订阅的、与收件人非直接相关的、或批量发送的商业邮件。 0x2 Anti-spam法规 邮件诞生于“网络平等可信”的那个年代，在其产生之初并没有足够的安全和垃圾信息防护的技术理论和实现。随着互联网的发展邮件服务受众越来越多，在20世纪90年代垃圾邮件出现了，Spammer(指垃圾邮件制造者)通过向互联网采集/购买到邮件地址发送大量(十万，甚至百万以上数量级)各类内容的垃圾邮件，来获取少量中招用户的经济或其他利益。Spammer收集邮件地址的行为逐渐催生来一类黑产，就是售卖可信收件人地址的交易，和传统通过工具在互联网漫无目的的搜索网页爬取邮件地址方式不同，这类黑产以黑客入侵服务系统、企业内部人员泄露、业务中介泄露、行业会议采集等等行为以更能够获取到真实有效的邮件地址数据，因此对于Spammer来讲是有足够的诱惑力的，有诱惑就产生了价值，进而有了市场交易。Spammer向收件人列表发出邮件中，虽然只有极少量的收件人查看、回复或产生购买等行为，但相比于发送邮件的低到可以忽略不计的成本收益还是相对巨大的。欧美国家在20世纪90年代逐渐发布了垃圾邮件相关法律，比如美国的CAN-SPAN ACT等，我国没有针对垃圾邮件的专门法律法规，个人理解相关的应该是网络安全法或者信息安全法规。 0x3 Spam分类 垃圾邮件跟进信息来源和类型大致可以分为几大类：商业广告类、欺诈类、钓鱼类、病毒类等。商业广告类邮件数量随着Anti-spam技术发展近些年已逐渐大幅降低，这类垃圾邮件以来自可信发信人(可追踪、可验证、真实存在的)的商业信息推广为主，例如网站推广、企业推广、EDM(不要以为EDM就不是垃圾邮件，呵呵)等；欺诈类邮件可以以十余年前的遗产诈骗类邮件为代表，收件人收到一封来自国外的E文邮件，发件人声称有一笔数额巨大的遗产因受限于法律等因素无法领取，希望以收件人的身份共同接收这笔巨额遗产，惊喜吧？真实情况是这只是在网络上诈骗手续费的早期模型；钓鱼类邮件相对来说具有较高的技术含量，发件人伪装成银行或商业机构，以邮件方式向收件人推送价格极具诱惑性的产品广告，诱使有户在线支付或订阅服务，通常会使用同银行或商业机构相近的域名或雷同的页面设计，且为了提高可信度邮件中的链接都是可以直接验证的，其目标客户就是那些能够使用网络但又没有足够防范意识的用户；病毒类邮件是通过邮件正文或附件中脚本或病毒文件在用户打开或执行附件的过程中感染用户本地文件系统，完成病毒传播工作，并在后续执行既定或按需任务，以实现利益最大化。可见，垃圾邮件这几大类型，从商业广告类到病毒类，随着技术含量的增加给收件人带来的风险也越来越大，从低成本的时间浪费，一直到成本不可控的金钱和个人信息损失。 0x4 Why Anti-Spam 垃圾邮件对社会、企业、家庭、个人等各类主体都存在非常高的风险，即包括商业推广类垃圾邮件带来的时间、存储空间浪费，也包括欺诈类、钓鱼类垃圾邮件带来的财务风险(如身份信息泄露、银行卡信息泄露等)，还包括如CAN-SPANACT关注的可能给未成年人带来的风险等。 0x5 SMB Anti-Spam 国内Anti-spam工作从管理角度大致可分为两方面，一是国家层面采用简单粗暴的网络管理方法，企业可采购的网络接入、服务托管、云主机等服务默认全部禁用TCP PORT 25，使得在国内自行架设邮件服务器的流程极其复杂，同时采用合法租赁的网络发送垃圾邮件无异于自投罗网，由此很大程度上降低了Spammer的生存空间；二是行业内没有可信的RBL也无法提供RBL解除等服务，各大运营商如腾讯、网易等可能有自己的RBL但不向公众开放，导致自建邮件服务的企业在IP地址被列入RBL后，除了申诉很难有其他途径处理，而向国外RBL(如Spamhaus等)部分商业列表申诉则要求申诉方必须是IP地址所有者，在国内企业用户只能是IP地址租用/使用者，且大部分企业对商业信息安全和保密等要求不高，因此企业自建并运维邮件服务的意愿较低。综上，对于购买邮件服务的企业来说，所有Anti-spam功能全部依赖于服务商，受限于国情和企业需求情况，国内并没有产生诸如Barracuda等Anti-spam方案的厂商。
0x1 ACL与Options BIND的主配置文件支持丰富的配置参数，这里简单介绍下Options和ACL，至于View等配置我不准做更多说明，熟悉基础配置后参考配置文档即可完成相关配置，参考文档可以直接执行以下命令查看： #man 5 named.conf 1、ACL访问控制列表 ACL用于控制客户端对DNS服务的访问权限，可选参数包括any、localhost、localnet、none及以CIDR表示的网络地址； acl allow-query-net { 192.168.2.0/24; }; 这里的allow-query-net是ACL的名称； 2、Options选项 Options用于Statement中，用以对Statement进行全局或可选配置，可选参数包括： allow-query 允许客户端访问，默认允许所有 allow-query-cache 允许查询缓存，more允许localhost和localnet blackhole 黑洞，拒绝客户端访问，默认none disable-empty-zone 禁用默认的空域配置，企业环境用不到，除非管理员打算自找烦恼 dnssec-enable 启用DNSSEC相关RR，默认启用 dnssec-validatiom 通过DNSSEC验证RR权威性，默认启用 forwarders 请求转发服务器列表，即将本服务器无法解析的请求转发给指定服务器，比如配置Google或DNSPOD等DNS Server forward 控制forwarders请求顺序，有2个值，frist先到转发服务器列表查询，失败后再在本地服务器查询，only表示仅在转发服务器列表查询 listen-on named服务监听端口，不能也不需要修改 max-cache-size 服务缓存最大可用内容容量，默认32M，在多View配置中可以为每个View单独配置 notify 当zone更新后主动通知Slave，有4个值，yes主动通知，no不主动通知，master-only仅通知master，explicit仅通知zone中also-notify的Salve recursion 递归查询，默认yes，在没有外部网络连接或特殊需求中可以配置为no，以将本服务器无法解析的请求做失败响应 参考示例： acl allow-query-net { 192.168.2.0/24; }; acl deny-query-net { 192.168.1.0/24; }; options { listen-on port 53 { any; }; max-cache-size 64M; directory "/var/named"; statistics-file "/var/named/data/named_stats.txt"; forwarders {8.8.8.8; 8.8.4.4; }; recursion yes; blackhole { deny-query-net; }; allow-query { allow-query-net; }; allow-query-cache { allow-query-net; }; }; 0x2 协议与端口 DNS服务通用服务端口包括UDP53和TCP53，前者用于请求解析，后者用于Master/Slave间ZoneTransfer数据同步，在配置iptables规则时必须注意。 0x3 Master/Slave ZoneTransfer DNS服务器之间数据同步分为两种AXFR (Asynchronous Transfer Full Range)全域传输和IXFR(Increment Zone Transfer)增量域传输，BIND9这两种协议默认都开启。为保证Slave Server上缓存记录的权威性，Slave需要周期性从Master Server同步Zone数据，因此AXFR全域传统比较容量理解，而IXFR则在域中RR数据比较多且更新频繁的情况下(比如DDNS等)可以比AXFR更具优势，能够更加快速完成数据同步。除了Slave Server周期性项Master Server被动同步外，Master Server也可以主动向Slave Server发出更新通知，就是Notify。 配置示例： options { listen-on port 53 { any; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { localhost; 192.168.2.0/24; }; forwarders { 8.8.8.8; }; recursion yes; notify yes; dnssec-enable yes; dnssec-validation yes; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; }; 当Master Server数据更新后可在Slave Server日志中看到其从收到更新通知到执行zone-transfer结束的完整流程(隐去了时间参数)： slave named[6489]: client 192.168.2.250#50982: received notify for zone '2.168.192.in-addr.arpa' slave named[6489]: zone 2.168.192.in-addr.arpa/IN: Transfer started. slave named[6489]: transfer of '2.168.192.in-addr.arpa/IN' from 192.168.2.250#53: connected using 192.168.2.251#47133 slave named[6489]: zone 2.168.192.in-addr.arpa/IN: transferred serial 2018061807 slave named[6489]: transfer of '2.168.192.in-addr.arpa/IN' from 192.168.2.250#53: Transfer completed: 1 messages, 14 records, 397 bytes, 0.001 secs (397000 bytes/sec) slave named[6489]: zone 2.168.192.in-addr.arpa/IN: sending notifies (serial 2018061807) slave named[6489]: client 192.168.2.250#23267: received notify for zone 'homelab.pub' slave named[6489]: zone homelab.pub/IN: Transfer started. slave named[6489]: transfer of 'homelab.pub/IN' from 192.168.2.250#53: connected using 192.168.2.251#53086 slave named[6489]: zone homelab.pub/IN: transferred serial 2018061807 slave named[6489]: transfer of 'homelab.pub/IN' from 192.168.2.250#53: Transfer completed: 1 messages, 16 records, 389 bytes, 0.001 secs (389000 bytes/sec) 0x4 日志分析 默认named通过rsyslog将日志写到/var/log/messages中，以下将日志中常见疑难消息做简要说明。 1、[namedxxxx]: error (networkunreachable) resolving 'baidu.com/A/IN': 2001:503:bb3e::2:30#53 服务器没有配置IPv6网络，但named默认同时运行在IPv4和IPv6协议栈，因此需要在服务配置文件/etc/named.conf中将以下内容注释或删除掉 listen-on-v6 port 53 { ::1; }; 并在named服务的配置文件/etc/sysconfig/named中加入仅支持IPv4的选项 #echo -e 'OPTIONS="-4"' >> /etc/sysconfig/named #systemctl restart named-chroot 2、日志未记录DNS查询详细信息 在服务器打开querylog即可记录详细日志，再次执行此命令关闭该功能 3、slave named[xxxx]: client 192.168.2.205:39085 (mirror.zju.edu.cn): query (cache) "mirror.zju.edu.cn/A/IN" denied DNS服务器关闭了递归查询，不允许查询缓存，仅允许查询本域权威记录 4、slave named[xxxx]: transfer of '2.168.192.in-addr.arpa/IN' from 192.168.2.250#53: failed to connect: host unreachable 无法连接到masterserver进行zone-transfer，推测masterserver系统防火墙iptables没有放行来自slaveserver对TCP53端口的访问 5、slave named[xxxx]: dumping master file: tmp-XXXXXX: open: permission denied 这个问题在网络上有多种不靠谱的观点，这里仅对前三甲做介绍。排在第一位的观点认为是SElinux某个Boolean配置问题，但在homelab.pub中SElinux是Disabled；排在第二位的观点认为是目录属组权限问题，虽然log中有提示permission denied但经验表明服务系统文件权限配置错误基本无法正常运行；排在第三位的观点认为是服务参数配置问题，建议在/etc/sysconfig/named文件增加“ENABLE_ZONE_WRITE=yes” 参数，但BIND9已不正常参数。经深入研究，发现是Salve服务Zone配置文件路径错误，导致服务读取Zone文件时无法读取而报错，但从Master同步过来的缓存数据是可以用于解析服务的，因此Client端并没有感知到Slave Server工作状态有问题。 在前一篇文章SMB - DNS Server 域名服务器配置与管理(三) 0x2 Slave Server部署章节谈到创建homelab.pub域的服务配置named.homelab.pub.zones文件如下： zone "homelab.pub" IN { type slave; masters { 192.168.2.250; }; file "homelab.pub.zone"; allow-update { none; }; }; zone "2.168.192.in-addr.arpa" IN { type slave; masters { 192.168.2.250; }; file "homelab.pub.rr.zone"; allow-update { none; }; }; 仔细分析得知文件位置是错误的，当前路径没有这个文件，Slave Server读取的应该是从Master Server同步过来的文件信息，检查服务目录结构发现应该写如到/var/named/chroot/var/named/data/目录中，修改named.homelab.pub.zones文件如下： zone "homelab.pub" IN { type slave; masters { 192.168.2.250; }; file "data/homelab.pub.zone"; allow-update { none; }; }; zone "2.168.192.in-addr.arpa" IN { type slave; masters { 192.168.2.250; }; file "data/homelab.pub.rr.zone"; allow-update { none; }; }; 然后重启named-chroot服务，检查/var/log/messages发现相关错误日志信息消失，并在/var/named/chroot/var/named/data/目录发现homelab.pub.rr.zone和homelab.pub.zone两个新数据文件： [root@slave ~]# ll /var/named/chroot/var/named/data/ 总用量 220 -rw-r--r-- 1 named named 862 6月 26 23:29 homelab.pub.rr.zone -rw-r--r-- 1 named named 740 6月 26 23:29 homelab.pub.zone -rw-r--r-- 1 named named 94525 6月 26 23:29 named.run -rw-r--r--. 1 named named 116828 6月 24 03:21 named.run-20180624 [root@slave ~]# file /var/named/chroot/var/named/data/homelab.pub.zone /var/named/chroot/var/named/data/homelab.pub.zone: data
BIND是互联网各大DNS服务机构广泛使用的域名服务应用，当前版本为9.9，除了*nix外还能够支持Windows等多种操作系统平台，在homelab.pub中我将在CentOS7.5上部署BIND并为本地局域网配置域名解析服务。和其他各类服务应用一样，BIND也采用Master/Slave两种角色构建集群提高服务的可靠性，本文将简要介绍两种角色的部署配置和调试验证。为保证服务安全性，BIND将运行在Chroot环境中。 0x0 背景工作 本文核心在于验证DNS服务，并不关注网络和安全等可能影响服务配置部署的因素，因此在此文假设已将IPv6、SELinux等服务关闭，iptables可根据需要自行配置。 0x1 Master Server部署 BIND默认配置文件包含一组名为empty zones的空域配置文件，用以避免递归查询服务向外部发送无效DNS请求。其配置文件位于/etc/目录下，在chroot环境中服务主配置文件/etc/named.conf等仍在原始文件中修改，Zone配置文件则存放着/var/named/目录下。BIND服务在CentOS中默认的服务名为为named，在chroot环境中服务名称为named-chroot。 安装BIND和相关辅助软件 #yum -y install bind bind-utils bind-chroot 启用named-chroot服务 #systemctl enable chroot-named #systemctl start chroot-named #systemctl mask named //mask掉named，避免误操作 创建homelab.pub正向解析文件/var/named/homelab.pub.zone ;Author:Haichen ;Date:20180625 $ORIGIN homelab.pub. $TTL 86400 @ IN SOA master.homelab.pub. xiaomage.homelab.pub. ( 2018061802 21600 3600 604800 86400 ) ; ; IN NS master.homelab.pub. IN NS slave.homelab.pub. master IN A 192.168.2.250 slave IN A 192.168.2.251 ; ; IN MX 10 mail1.homelab.pub. IN MX 20 mail2.homelab.pub. mail1 IN A 192.168.2.200 mail2 IN A 192.168.2.201 www IN A 192.168.2.205 ; ; ftp IN CNAME www ; ;Exsi Server In Homelab esxi01 IN A 192.168.2.210 esxi02 IN A 192.168.2.211 esxi03 IN A 192.168.2.212 esxi04 IN A 192.168.2.213 创建homelab.pub反向解析文件/var/named/homelab.pub.rr.zone ;Author:Haichen ;Date:20180625 $ORIGIN 2.168.192.in-addr.arpa. $TTL 86400 @ IN SOA master.homelab.pub. xiaomage.homelab.pub. ( 2018061802 21600 3600 604800 86400 ) ; ; @ IN NS master.homelab.pub. IN NS slave.homelab.pub. ; ; 250 IN PTR master.homelab.pub. 251 IN PTR slave.homelab.pub. ; ; 200 IN PTR mail1.homelab.pub. 201 IN PTR mail2.homelab.pub. 205 IN PTR www.homelab.pub. ; ; 205 IN PTR ftp.homelab.pub. ; ; 210 IN PTR esxi01.homelab.pub. 211 IN PTR esxi02.homelab.pub. 212 IN PTR esxi03.homelab.pub. 213 IN PTR esxi04.homelab.pub. 为便于管理为以上两个zone创建独立的引用文件，当然也可以将以下内容直接写入到/etc/named.conf中，但还是建议为其创建相对独立的引用文件/var/named/chroot/etc/named.homelab.pub.zones zone "homelab.pub" IN { type master; file "homelab.pub.zone"; allow-transfer { 192.168.2.251; }; allow-update { none; }; }; zone "2.168.192.in-addr.arpa" IN { type master; file "homelab.pub.rr.zone"; allow-transfer { 192.168.2.251; }; allow-update { none; }; }; 然后在主配置文件/etc/named.conf中引用以上文件 #echo -e 'include "/etc/named.homelab.pub.zones";' >> /etc/named.conf 启动named-chroot服务 #systemctl restart named-chroot 向iptables INPUT链插入一条允许本地网络访问UDP 53端口的规则； #iptables -I INPUT -s 192.168.2.0/24 -p udp --dport 53 -j ACCEPT0x2 Slave Server部署 和其他Master/Slave架构的服务一样，需要首先保证两台服务器时间同步，否则无法同步数据，NTP Server配置参考SMB TimeServer 时间服务器配置与管理。 Slave Server仅需配置服务配置文件，zone配置将从master同步，基础服务配置如下： #yum -y install bind bind-utils bind-chroot //安装服务软件包 #systemctl enable chroot-named #systemctl start chroot-named #systemctl mask named //mask掉named，避免误操作 创建homelab.pub域的服务配置文件/var/named/chroot/etc/named.homelab.pub.zones zone "homelab.pub" IN { type slave; masters { 192.168.2.250; }; file "homelab.pub.zone"; allow-update { none; }; }; zone "2.168.192.in-addr.arpa" IN { type slave; masters { 192.168.2.250; }; file "homelab.pub.rr.zone"; allow-update { none; }; }; Tips:注意在此配置文件和master上配置文件的差异，此处通过type slave声明该服务器角色为slave，通过masters声明了master服务器位置。 然后在主配置文件/etc/named.conf中引用以上文件 #echo -e 'include "/etc/named.homelab.pub.zones";' >> /etc/named.conf 启用named-chroot服务 #systemctl restart named-chroot 向iptables INPUT链插入一条允许本地网络访问UDP 53端口的规则；#iptables -I INPUT -s 192.168.2.0/24 -p udp --dport 53 -j ACCEPT0x3 DNS服务验证 完成以上配置，本地DNS Server已可以提供解析服务了，在Slave Server上通过日志文件/var/log/messages中named服务相关内容可以看到DNS数据同步信息。 在本地任意客户端通过nslookup或dig命令可以对DNS是否生效进行验证，在此我通过dig查询所有RR资源，参考如下： 当然其他如ping/nslookup等命令都能进行域名查询验证，但如果你是管理员建议还是要熟悉dig的使用。
DNS Server根据提供服务内容，可以分为Authoritative授权服务器和Recursive递归服务器两种。前者在本地保存了授权域名的Zone文件能够提供针对授权域的权威应答，服务器角色可以是Master或Slave Server；后者仅对客户端请求做递归查询并提供缓存服务，通常也称为CacheOnly Server。 我们在 homelab.pub中构建的DNS Server将会同时配置为授权服务器和递归服务器，满足企业内部私有域名解析和外部域名缓存需求。但这种配置在生产环境中可能会因为缓存服务器向运营商DNS Server频繁发出DNS请求而触发服务侧的安全机制导致被暂时性列入RBL，影响内部用户正常访问，因此建议为本地DNS Server配置多个参考DNS Server，条件允许的话建议配置谷歌或DNSPOD等机构的DNS Server，可以避免此类问题且可以在一定程度上免受DNS污染影响。 本文将介绍DNS服务关键术语，区域Zone和资源记录ResourceRecords(下文简称RR)。 0x1 Zone和RR Zone和Domain虽然都有“区域”的意思，但在IT语境中却是两个不同的术语。Domain是DNS层次化结构中的一个分支，而Zone是DNS结构中的一段连续的名称空间，即Zone是可以包含多个连续的Domain的，而不连续的Domain是无法构成Zone的。在Zone配置文件中通过资源记录RR描述这段连续的名称空间中授权和地址解析情况。Zone配置文件格式通过RFC1035定义，因此大多数DNS Server无论其架构和平台都能够相互兼容。 Zone配置文件示例参考： $ORIGIN homelab.pub. ;声明域名空间，必须以点号结尾 $TTL 86400 ;RR生存周期，即可被缓存时间，全局 @ IN SOA master.homelab.pub. xiaomage.homelab.pub. ( ;SOA记录 2018061801 ;序列号 21600 ;更新时间间隔，也可采用6H表示 3600 ;更新失败重试时间间隔，也可采用1H表示 604800 ;失效时间，也可采用1W表示 86400 ;TTL生存周期，也可采用1D表示 ) ; IN NS master.homelab.pub. ;NS记录 IN NS slave.homelab.pub. ;NS记录 master IN A 192.168.2.250 ;A记录 slave IN A 192.168.2.251 ;A记录 Zone配置文件中的每条记录(如SOA/NS/A/MX等)就称为RR资源记录。 0x2 RR资源记录类型 根据IETF相关文档定义，RR可以有多种，本文仅介绍我们日常工作经常用到的几种类型。 1、SOA记录，Start of Authority Record 用途：用于委派授权，即表明当前DNS Server作为指定域的授权服务器。SOA是Zone文件的第一条RR，包含多个参数，默认时间单位为秒，也支持H/D/W等便捷表示法； 示例： $ORIGIN homelab.pub. ;声明域名空间，必须以点号结尾 $TTL 86400 ;RR生存周期，即可被缓存时间，全局 @ IN SOA master.homelab.pub. xiaomage.homelab.pub. ( 2018061801 21600 3600 604800 86400 ) SOA记录内容说明： @ 在Zone文件中“@”符号表示引用#ORIGIN命令，即homelab.pub IN 表示Internet SOA 记录类型 master.homelab.pub. 授权DNS服务器主机名 xiaomage.homelab.com. 管理员Email地址，因在Zone文件中“@”符号有其他用途，这里有件地址中用“.”代替 2018061801 数字格式序列号，用于配置版本控制，slave根据序列号判断master是否有更新 21600 salve向master请求更新的时间间隔(也可以采用6H表示) 3600 salve向master请求更新失败后重试时间间隔，如果在过期时间之内master始终没有响应slave的更新请求，则slave在过期时间后不能再为homelab.pub域提供权威解析(也可以采用1H表示) 604800 过期时间(也可以采用1W表示) 86400 TTL生存周期，即RR可以呗其他服务器缓存的时间周期(也可以用1D表示) 2、NS记录，Name Server Record 用途：声明当前域使用的DNS服务器的FQDN； 示例： @ IN NS master.homelab.pub. IN NS slave.homepab.pub. 说明：如果一条RR的第一个字段为空则使用上一条RR的第一个字段补齐； 3、A记录，IPv4 Address Record 用途：将域名映射到IPv4地址 示例： www IN A 192.168.2.205 IN A 192.168.2.206 说明：在正向解析域(即从域名解析IP地址)，FQDN域名要以“.”点号表示名称结束，否则DNS Server会自动将$ORIGIN的值追加到域名后作为FQDN。示例中“www”没有使用“.”号结束，系统会自动将其补充为“www.homelab.pub.”，如果写为“www.”就错了。 4、MX记录，Mail Exchange Record 用途：声明当前域使用的邮件服务器的FQDN 示例： @ IN MX 10 mail1.homelab.pub. IN MX 20 mail2.homelab.pub. 说明：同一域名可以设置多条同类型的RR以实现负载均摊，MX型RR中增加了优先级列来区分负载均摊的参考权重，权重值越大优先级越低。 5、CNAME记录，Canonical Name Record 用途：别名记录，将域名映射到另一个域名，但不能映射到另一个别名(防止环路冲突)，其他指向FQDN的记录(NS、MX、PTR)不能指向CNAME记录； 示例： portal IN CNAME www 说明：这条RR中portal和www都没有以“.”点号结尾，因此系统会自动将其补充为“portal.homelab.pub. IN CNAME www.homelab.pub.”。 6、PTR记录，Pointer Resource Record 用途：反向解析记录，用于反向解析域(即从IP地址解析域名)，将IP地址映射到域名。 示例： 250 IN PTR master.homelab.pub. 说明：反向解析域Zone文件中IP地址部分仅需填写最后一组数字，以上示例表示“192.168.2.250是域名master.homelab.pub的IP地址”。 7、TXT记录，Text Record 用途：文本型记录，多用于垃圾邮件防范的SPF和DKIM，这两种RR不能视为anti-spam的能力，但可以作为整体方案的组成部分； 示例： homelab.pub. IN TXT "v=spf1 mx ptr -all" mail1.homelab.pub. IN TXT "v=spf1 mx ptr -all" mail2.homelab.pub. IN TXT "v=spf1 mx ptr -all" homelab.pub. IN TXT "v=spf1 ip4:192.168.2.200/24 ip4:192.168.2.201/24 -all" 说明1：SPF Sender Policy Framework发送方策略框架，用以声明当前域有哪些合法邮件服务器。SPF记录可以配置到整个域和域内的每台MX RR，其中“v=spf1”表示版本1，目前只有版本1，“mx”表示本域对外发送邮件，“ptr”表示本域邮件服务器具有ptr记录，“ip4:192.168.2.200/24”表示本域邮件服务器IPv4地址，有多个邮件服务器则都要写全，“-all”表示拒绝其他地址。具体采用哪种写法要根据DNS Server支持情况来确认，国内的DNS服务商多采用最后一种方式。TXT记录在企业内部的DNS Server上几乎用不到，后续如果谈到MailServer再详细解释。 说明2：DKIM DomainKeys Identified Mail 域名密钥识别邮件(标准)，用以验证发送方服务器合法性。大体流程是MailServer创建了非对称密钥对，并将共钥信息添加到了DNS服务器的TXT记录中，发件方服务器在发送邮件时会在邮件头中加入基于私钥的签名信息，收件服务器在接收到邮件请求后会向DNS服务器请求发件服务器域名TXT记录中的公钥信息用以验证签名是否有效，若有效则进入邮件接收流程，否则则进入垃圾邮件处理流程。 一句话简单理解SPF和DKIM：SPF声明了当前域合法的MailServer的IP地址，而收件方MailServer则可以通过DKIM对这些地址进行验证。 8、SRV记录，Service Location Record 用途：服务定位记录，用以标识指定服务器提供了哪些服务，常用于Windows活动目录中。 示例： _http._tcp.homelab.pub. IN SRV 0 5 8081 www.homelab.pub. 说明：SRV记录字段构成：srvce.prot.name. IN SRV pri weight port target srvce:服务类型，以下横行开头，如：_http表示WEB服务，_ftp表示FTP服务，_ldap表示LDAP服务等； prot:协议类型，以下横行开头，如：_tcp表示TCP协议，_udp表示UDP协议； name:本域域名； SRV:记录类型； pri：优先级，同MX记录中优先级功能相同，数值越小优先级越高； weight:权重，用于在具有相同优先级的多条SRV记录之间实现负载均摊，数值越大被负载的几率越高； port:服务端口，此处可以填写自定义端口，比如运行于8081端口的WEB服务； target目标服务器，提供该服务的服务器FQDN。
DomainNameService域名服务，提供域名到IP地址的双向映射，是维持互联网可用性和可靠性的关键基础设施。互联网的可用性除了网络可达之外还应包括用户能够正常访问他需要访问的公开合法信息，DNS服务为便捷的信息查询提供了核心技术支持；而互联网的可靠性除了网络服务的在线状态之外还应包括用户能够准确访问他需要访问的公开合法信息，即域名解析数据不应受到中间人或第三方的恶意修改。本文将主要介绍DNS相关基础知识，包括域和委派授权，以及DNS查询流程。 0x1 域和委派授权 DNS采用树状层次化结构进行组织和管理，由ICANN进行规划和委派授权，我国的域名管理机构CNNIC是经由IANA授权的国家级域名管理机构，其他国内域名服务商都需要CNNIC授权才能提供权威解析服务。域名空间结构如下图所示： 树根的点号.称为根域；一级分支称为TLD顶级域名，分为两类，一类是.com、.net、.org及新生代的.xyz、.cc等通用域名，一类是.uk、.us、.cn、.jp等表明受管国家的域名；二级分支称为SLD二级域名，例如homelab.pub、bing.com等；三级分支称为三级域名，例如www.homelab.pub、cn.bing.com等，以此类推。通常域名的级别不会超过四级，太长或复杂度太高的域名设计违背了DNS系统的设计初衷，因此又出现了新的短域名方案，如z.cn等。目前互联网上共有13台根域服务器，域名为a~m.root-servers.net，分布在美国(10台)、英国(1)、瑞典(1)和日本(1)。 域名的管理由授权委派机制实现，从根域开始各层级之间通过授权委派实现对子域域名的注册管理和地址解析，例如.com由根域授权给多个大型运营商或国家级管理机构进行管理，因此我们可以在us、uk或国内注册.com域名，但.cn仅授权给了CNNIC，因此是不可能在us或者uk的域名服务机构注册一个.cn域名的。二级及以下层级域名的授权委派由二级域名所有组织自行定义和管理，也就是说homelab.pub要在互联网上使用必须向CNNIC或其他同样获得.pub域名管理授权的服务机构缴费注册，但bj.homelab.pub则不在需要向这些结构注册，由企业内部管理员自行决定即可。授权委派机制会在后续内容介绍，此处大致理解就可以。 0x2 DNS查询 DNS服务的作用就是响应来自互联网的域名或IP解析请求，通常DNS请求可以分为三类：递归查询(RecursiveQuery)、迭代查询(IterativeQuery)和反向查询(InverseQuery)，其中反向查询目前已基本被淘汰因此不做介绍。这里需要说明的是反向查询(Inverse)和反向地址解析不是一个概念，反向地址解析是采用in-addr.arpa这个特殊的域通过递归查询和迭代查询相结合的方式完成了从IP地址向域名的解析。 递归查询(Recursive Query) 在递归查询中DNS解析器将代表客户端以递归方式向其他DNS服务器发出完整查询请求直到得到查询结果。在得到查询结果的过程中途经的所有服务器都会保存本次查询的缓存信息，因此会占用途径服务器部分内存资源，这在互联网中并不是最优方案。递归查询详细流程示意如下： 在浏览器地址栏输入www.aliyun.com，DNS解析流程如下： 1、查询本地DNSCache，有www.aliyun.com记录缓存则将结果反馈给浏览器，本次查询结束，否则继续； 2、向本地配置的DNSServer进行查询，如4.4.4.4，若4.4.4.4有相关记录缓存则将结果反馈给浏览器，本次查询记录，否则继续； 3、因DNSServer4.4.4.4没有相关域名记录缓存，因此向根域服务器进行查询； 4、根域服务器角色决定其不会缓存此类记录，故代替4.4.4.4向.comTLDDNS查询； 5、因.comTLD也不会缓存此类记录，因此.com TLD代替根域服务器向aliyun.com授权DNS服务器进行查询； 6、aliyun.com授权DNS服务器将www.aliyun.com的解析结果返回给.com TLD; 7、.com TLD将www.aliyun.com的解析结果返回给根域服务器; 8、根域服务器将www.aliyun.com的解析结果返回给主机配置的DNS服务器，即4.4.4.4; 9、4.4.4.4将www.aliyun.com的解析结果返回给主机浏览器，本次查询结束。 迭代查询(IterativeQuery) 在迭代查询中是按照域名从右到左的顺序逐域查询，即按照DNS的树状结构从根逐渐向下级分支进行查询，直到找到授权服务器得到查询结果。迭代查询详细流程示意如下： 在浏览器地址栏输入www.aliyun.com，DNS解析流程如下： 1、查询本地DNSCache，有www.aliyun.com记录缓存则将结果反馈给浏览器，本次查询结束，否则继续；2、向本地配置的DNSServer进行查询，如4.4.4.4，若4.4.4.4有相关记录缓存则将结果反馈给浏览器，本次查询记录，否则继续；3、因DNS Server4.4.4.4没有相关域名记录缓存，因此向根域服务器进行查询；4、根域返回.com TLD服务器的地址；5、4.4.4.4向.com TLD服务器查询www.aliyun.com；6、.com TLD服务器返回aliyun.com授权服务器地址；7、4.4.4.4项aliyun.com授权服务器查询www.aliyun.com;8、aliyun.com授权服务器将www.aliyun.com解析结果返回给4.4.4.4;9、4.4.4.4将www.aliyun.com的解析结果返回给主机浏览器，本次查询结束。 小结： 以上两种查询类型只是理论流程说明，在实际应用中是结合使用的，在客户端和本地配置的DNS服务器(如上文的4.4.4.4)之间采用递归查询，而本地DNS服务器向其他DNS服务器查询则使用迭代查询，即使本地DNS服务器向其他服务器做递归查询，也只会返回迭代结果。因为迭代查询在DNS树状结构的分布式数据库中查询速度更快，DNS服务器之间的交互更少，因此在根域和顶级域服务器都仅提供迭代查询。
引子：在企业网络中，时间服务可能是最不受重视却又非常重要的服务，说其不受重视一则是因为时间服务难以像OA/CRM/Mail等业务系统为企业带来直接收益，二是各类业务系统在使用系统时钟作为时间源表面上也能工作的很好；说其重要一则是因为时间的同步会直接影响业务系统数据的准确性和业务系统稳定性，二是在业务数据分析、系统运维或故障排查中一致的时钟能够极大降低工作复杂度。本文将简要说明基于CnetOS7.5的时间服务器和客户端基础配置操作，高阶操作后续有闲心在写。 0x1 设置时区 时区的产生和由来参考初中地理课本，在国内我们统一采用Asia/Shanghai或Asia/Chongqing进行配置。 #timedatectl set-timezone Asia/Shanghai 0x2 认识chrony 在基于Redhat的Linux发行版中，ntpd曾是默认的时间服务器，自RHEL7/CentOS7开始软件仓库开始提供替代应用---chrony。同ntpd一样基于C/S架构，但chrony具备更多的功能和使用场景，它可以将系统时钟、硬件时钟或手动输入作为参考时间，因此能够在间断性网络连接的场景中提供准确的时钟服务。chrony提供了两个命令，分别是管理命令chronyc和服务进程chronyd。 0x3 部署chrony #yum -y install chrony 配置文件为/etc/chrony.conf,简要参考关键配置如下： #参考时间源配置，可以使用默认的由pool.ntp.org提供的时间源，也可以使用国家授时中心或清华大学等国内靠谱的时间服务器，在homelab.pub中我将使用默认时间源； server 0.centos.pool.ntp.org iburst server 1.centos.pool.ntp.org iburst server 2.centos.pool.ntp.org iburst server 3.centos.pool.ntp.org iburst #允许指定网络通过本服务器同步时间，如果是服务于分支机构的中央服务器，还需额外增加防火墙安全策略； allow 192.168.0.0/16 #该配置表示即使向以上指定的参考时间源同步失败，仍然提供时钟服务，比如为企业提供互联网接入服务的ISP网络故障时企业内部网络仍需正常授时； local stratum 10 仅需修改以上三条配置即可满足基本要求，通过以下命令启动服务： #systemctl enable chronyd #systemctl start chronyd 0x4 客户端配置 chrony虽然是C/S架构，但在Server端和Client端部署的软件没啥区别，只是Client端配置更简单些，仅需指定参考时间源即可。 #yum -y install chrony 配置文件为/etc/chrony.conf，简要参考关键配置如下： #参考时间源配置，在homelab.pub中时间服务器192.168.2.251 server 192.168.2.251 iburst 有几台的话就填写几条，然后通过以下命令启动服务： #systemctl enable chronyd #systemctl start chronyd 0x5 管理与运维 chrony提供的工具只有chronyc，可用于日常管理运维操作，常用基础操作命令参考： A、查看时间源统计信息 [root@master ~]# chronyc sources 210 Number of sources = 4 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^- 24.2.59.108.in-addr.arpa 2 10 77 384 -13ms[ -11ms] +/- 351ms ^+ static-5-103-139-163.ip.> 1 10 167 23m +15ms[ +18ms] +/- 162ms ^+ 4.197.134.185.in-addr.ar> 2 10 177 48m -5524us[-2571us] +/- 146ms ^* 85.199.214.101 1 10 363 163 +32ms[ +34ms] +/- 171ms 输出中M列表明时间源的类型，^号表示服务器，=号表示对等体，#号表示本地参考时钟； 输出中S列表明时间源的状态，*号表示当前正在同步，+表示可选/备用时间源，-号表示已排除在可选项之外，?号表示连接丢失或时间源状态没有通过验证； 在客户端运行以上命令，查看同步时间源信息示例输出： B、查看时间源活动状态 [root@master ~]# chronyc activity 200 OK 4 sources online 0 sources offline 0 sources doing burst (return to online) 0 sources doing burst (return to offline) 0 sources with unknown address C、查看系统时钟性能信息 [root@master ~]# chronyc tracking Reference ID : 55C7D665 (85.199.214.101) Stratum : 2 Ref time (UTC) : Thu Jun 21 00:14:25 2018 System time : 0.002271435 seconds fast of NTP time Last offset : +0.000506308 seconds RMS offset : 0.001562944 seconds Frequency : 14.963 ppm slow Residual freq : +0.003 ppm Skew : 0.046 ppm Root delay : 0.256618977 seconds Root dispersion : 0.003374373 seconds Update interval : 1044.2 seconds Leap status : Normal Reference ID：时间源ID(域名)，如果ID为7F7F0101且域名为空，则表示未与外部时间源同步； Stratum：层级，表示本级到时间源的距离hop； Ref time：上一次同步的UTC参考时间； System time：系统时钟步进状态，为避免对应用程序影响，系统时钟采用步进方式进行同步； Last offset：上次同步时间时本地时钟偏移量； RMS offset：较长一段时间内偏移量均值； Frequency：如果chronyd不介入系统时钟发生错误的速率，以ppm(百万分之一)为单位。例如1ppm表示系统时钟认为自己快了1秒，实际相对于真实时间快了1.000001秒； Root delay：当前服务器到达层级为1的时间源的网络总延迟； Update interval：更新周期； D、查看服务日志 默认chonyd通过rsyslog将日志消息发送到/var/log/messages： [root@master ～]#cat /var/log/messages | grep chrony
发表了文章
2020-05-15
发表了文章
2018-08-19
发表了文章
2018-06-27
发表了文章
2018-06-25
发表了文章
2018-06-24
发表了文章
2018-06-23
发表了文章
2018-06-21
