企业内部DNS跨国配置案例

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 背景介绍:总公司与北京分公司均由总公司进行统一管理。总公司的主从DNS担任解析总公司服务器与北京分公司的服务器解析任务。总公司DNS委派其他两个公司管理自己域下的服务器解析任务。要求任何一个节点都能解析到公司全部域名的结果。

img_14d6fc3b5ef12946eba4d2a6bb8d30a7.png

背景介绍:总公司与北京分公司均由总公司进行统一管理。总公司的主从DNS担任解析总公司服务器与北京分公司的服务器解析任务。总公司DNS委派其他两个公司管理自己域下的服务器解析任务。要求任何一个节点都能解析到公司全部域名的结果。这里仅仅是搭建DNS服务器,以解析的结果为验证。所以暂不考虑网络方面的事情,只要确保DNS能相互解析就算配置成功。

一、步骤梳理

  • 设定主从服务器的配置
  • 设定主服务器字节区域解析数据库
  • bj.jd.com子域分配给自己管理
  • yd.jd.comsh.jd.com分别委派给各自的服务器
  • 子域服务器设定各自的区域解析数据库
  • 子域服务器设定将jd.com域转发至主从服务器中

二、bind配置文件结构

本地解析文件
   /etc/hosts
主配置文件
   /etc/named.conf
   /etc/named.rfc1912.zones
   /etc/rndc.key
解析库文件
   /var/named
           \----slaves      #文件夹,当为slave,则在master同步的数据放在此文件
           \----named.ca        #互联网根的信息
           \----name            #自定义的数据文件放在此目录下

三、搭建过程

1.主DNS服务器

安装bind并配置DNS的主配置文件

//安装bind
yum install bind
//
//配置bind的主配置文件
vim /etc/named.conf
  listen-on port 53 { 10.0.0.57; };    //设置监听的IP
  allow-query     { any; };            //设置允许所有人访问DNS服务
  forwarders { 114.114.114.114; };     //设定转发,本机没有的记录全部转发至其他DNS
  dnssec-enable no;                    //关闭DNS安全认证
  dnssec-validation no;                //关闭DNS安全确认
  include "/etc/named.rfc1912.zones";  //引入外部区域配置文件

在区域配置文件/etc/named.rfc1912.zones创建新的解析区域

//修改区域配置文件
vim /etc/named.rfc1912.zones
  zone "jd.com" IN {                   //创建jd.com域
          type master;                 //在jd域为主DNS
          file "jd.com.zone";          //区域数据库的配置文件名称,默认路径在/var/named/.....
  }; 

  zone "bj.jd.com" IN {                //创建子域bj.jd.com
          type master;                 //在子域中为主DNS
          file "bj.jd.com.zone";       //区域数据库的配置文件名称,默认路径在/var/named/.....
  };

创建解析数据库文件,数据库默认全部在/var/named目录下,创建的区域数据库文件名一定要与上面配置的区域数据库名称一致。NS类型的记录为设置管理此域的服务器,因为配置了主从两个服务器所以要将两个服务器都创建NS记录。但是仅仅创建NS记录是不够的,因为客户端访问的时候不能知道到底谁是NS服务器,所以还需要给管理此域的服务器建立一条A记录,解析出管理此域的服务器。

vim /var/named/jd.com.zone
  $TTL 1D
  @       IN SOA  dns1 root.jd.com. (
                                        16      ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
          NS      dns1                  //NS指定管理此域的服务器
          NS      dns2                  //NS指定管理此域的服务器
  sh      NS      dns.sh                //将sh子域委派给sh.jd.com进行管理
  yd      NS      dns.yd                //将yd子域委派给sh.yd.com进行管理
  dns1    A       10.0.0.57             //为管理此域的服务器与子域服务器创建A记录
  dns2    A       10.0.0.56
  dns.sh  A       10.0.0.66
  dns.yd  A       10.0.0.67
  www     A       10.10.0.10            //为主服务器直接管理的解析记录创建A记录
  oa      A       10.10.0.11
  sql     A       10.10.0.12

因在/etc/named.rfc1912.zones文件中创建了两个区域,所以一共要对应两个区域解析数据库。上面创建的数据库时给jd.com创建的数据文件。现在需要创建的是bj.jd.com的数据库文件,也就是Master服务器自己管理的子域。因为总公司与北京分公司都在北京,所以主DNS直接自己管理自己的子域。

$TTL 1D
@       IN SOA   dns1 root.bj.jd.com. (
                                        5       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
        NS      dns1
        NS      dns2
dns1    A       10.0.0.57
dns2    A       10.0.0.56
ftp     A       10.20.0.12
oa      A       10.20.0.13

2.从服务器

修改从服务器的主配置文件

vim /etc/named.conf
options {
        listen-on port 53 { 10.0.0.56; };
        allow-query     { any; };
        recursion yes;
        dnssec-enable no; 
        dnssec-validation no; 
};
 include "/etc/named.rfc1912.zones";

创建区域文件,因为从服务器只是同步主服务器的数据,所以不需要解析的数据库文件,只需要设定好谁是主服务器即可。

zone "jd.com" IN {                       //设定需要同步的区域,主从是相对于区域而言的所以要设定区域。
        type slave;                      //设定服务器类型为slave从
        masters { 10.0.0.57 ;};          //设定主服务器的IP地址
        file "slaves/jd.com.zone";       //主服务配置文件都会在/var/named/slaves目录下,设定同步回来的数据库文件名
};

zone "bj.jd.com" IN {                    //含义与上面类似,这里设置同步自己管理的子域
        type slave;
        masters { 10.0.0.57 ;}; 
        file "slaves/bj.jd.com.zone";
};

3.印度

后面印度分公司与上海分公司的配置除了设定一下需要转发的区域,其他的跟之前的主服务器配置都是大同小异。所以下面的仅仅对不通配置进行标注。

options {
        listen-on port 53 { 10.0.0.67; };
//      listen-on-v6 port 53 { ::1; };
        allow-query     { any; };
        recursion yes;
        dnssec-enable no;
        dnssec-validation no;
};
 include "/etc/named.rfc1912.zones";

设定转发区域。由于子公司仅仅管理自己的yd.jd.com域,那公司内部需要访问总公司的域名,就需要将其转发至上游的总公司。

zone "yd.jd.com" IN {
        type master;
        file "yd.jd.com.zone";
};

zone "jd.com" IN {                        //设定转发,客户端访问jd.com域时全部转发至指定的服务器
        type forward;
        forward first;
        forwarders {10.0.0.57;};         //设定转发至10.0.0.57服务器。
};

创建印度分公司的区域解析文件

$TTL 1D
@       IN SOA  dns root.yd.jd.com. (
                                        1       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
        NS      dns 
dns     A       10.0.0.67
oa      A       10.40.0.13
ftp     A       10.40.0.12

4.上海

修改主配置文件

options {
        listen-on port 53 { 10.0.0.66; };
        listen-on-v6 port 53 { ::1; };
        allow-query     { any; };
        recursion yes;
        dnssec-enable no;
        dnssec-validation no;
};
 include "/etc/named.rfc1912.zones";

创建区域记录,设定转发

zone "sh.jd.com" IN {
        type master;
        file "sh.jd.com.zone";
};

zone "jd.com" IN {                        //设定转发,客户端访问jd.com域时全部转发至指定的服务器
        type forward;
        forward first;
        forwarders {10.0.0.57;};         //设定转发至10.0.0.57服务器。
};

创建上海分公司自己管理的区域解析文件。

$TTL 1D
@       IN SOA  dns root.sh.jd.com. (
                                        0       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
        NS      dns
dns     A       10.0.0.66
ftp     A       10.30.0.12
oa      A       10.30.0.1

四、结果测试

将windwos的DNS设置为10.0.0.66,然后尝试解析10.0.0.67管理的域。成功得到解析结果。
img_2fd161b74842fc55878cee15af5c33b0.png

五、测试工具

dig [-t type] name [@SERVER] [query options]
dig只用于测试dns系统,不会查询hosts文件进行解析
#常用组合
dig www.taobao.com @10.0.0.10                #指定以10.0.0.10为DNS进行解析
 dig +trace taobao.com                       #跟踪解析的过程

六、注意事项

  • 权限:BIND安装时会创建一个用户,BIND运行也是用此用户的身份运行的。所以在解析的时候要确保创建的namde用户拥有对数据可的读权限。
  • 端口:在bind的主配置文件named.conf确保监听的端口已经设置、确保可以对所有人提供DNS服务。
  • 主从更新机制:当Master的版本号变大时,Slave才会同步Master上的数据。
  • SELinux:SELinux安全的可能让自己也无法访问服务,索性直接关闭
  • Iptables:当任何配置都没有错误的时候注意防火墙是否配置正确
  • 创建委派:创建委派一定要将主主配置文件dnssec-enablednssec-validation设置为no
  • 其他疑问:鸟哥的文章或许能解开你的疑惑鸟哥官网

七、安全相关

在全局配置文件中/etc/named.conf可以配置与安全相关的选项

  • allow-query {}: 允许查询的主机;白名单
  • allow-transfer {}:允许区域传送的主机;白名单
  • allow-recursion {}: 允许递归的主机,建议全局使用
  • allow-update {}: 允许更新区域数据库中的内容

七、实验中遇到的坑

  • 启动服务时提示:Failed to start Berkeley Internet Name Domain (DNS).
    解决办法:多半是因为配置文件写错,根据systemclt status named 查看报警的具体配置
  • rndc reload同步配置rndc: neither /etc/rndc.conf nor /etc/rndc.key was found
    解决办法:这个是由于key的问题,可以忽略不管付传送门
  • 添加域后重启服务提示 loading from master file sh.jd.com.zone; failed: file not found
    解决办法:检查主配置文件与数据库文件的名字是否相符
  • 创建委派后提示:zone jd.com/IN: sh.jd.com/NS 'sh.jd.com' (out of zone) has no addresses records (A or AAAA)配置文件检查无误,返回但是解析无返回结果
    解决办法:在父域中创建委派,然后通过named-checkzone命令检查区域配置文件,一直提示A记录不存在。检查父域到子域能否ping通,检查子域防火墙是否关闭
目录
相关文章
|
2月前
|
安全 虚拟化
在数字化时代,网络项目的重要性日益凸显。本文从前期准备、方案内容和注意事项三个方面,详细解析了如何撰写一个优质高效的网络项目实施方案,帮助企业和用户实现更好的体验和竞争力
在数字化时代,网络项目的重要性日益凸显。本文从前期准备、方案内容和注意事项三个方面,详细解析了如何撰写一个优质高效的网络项目实施方案,帮助企业和用户实现更好的体验和竞争力。通过具体案例,展示了方案的制定和实施过程,强调了目标明确、技术先进、计划周密、风险可控和预算合理的重要性。
46 5
|
3天前
|
供应链 监控 搜索推荐
企业销售管理利器:销售易、飞鱼和800客CRM深度解析
- **销售易**:集营销、销售和服务于一体,提供全渠道获客、潜客识别、线索转化等功能,适合中大型企业,尤其适用于快消品、汽车等行业。 - **飞鱼**:由巨量引擎推出,专注于广告主的销售线索管理,实现自动获取、同步及跟进,适合各类规模企业,广泛应用于电商、金融等领域。 - **800客**:功能全面,涵盖市场、客户、销售、服务等管理模块,适合中小型到大型企业,提供定制化服务,满足个性化需求。 通过对比各产品的功能与适用场景,企业可根据自身需求选择最合适的CRM解决方案,以优化销售流程并深化客户关系。
|
10天前
|
NoSQL Java Linux
《docker高级篇(大厂进阶):2.DockerFile解析》包括:是什么、DockerFile构建过程解析、DockerFile常用保留字指令、案例、小总结
《docker高级篇(大厂进阶):2.DockerFile解析》包括:是什么、DockerFile构建过程解析、DockerFile常用保留字指令、案例、小总结
160 75
|
9天前
|
存储 设计模式 算法
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务,它涉及算法与对象间职责的分配。行为型模式分为类行为模式和对象行为模式,前者采用继承机制来在类间分派行为,后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象行为模式比类行为模式具有更大的灵活性。 行为型模式分为: • 模板方法模式 • 策略模式 • 命令模式 • 职责链模式 • 状态模式 • 观察者模式 • 中介者模式 • 迭代器模式 • 访问者模式 • 备忘录模式 • 解释器模式
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
|
6天前
|
存储 监控 算法
企业内网监控系统中基于哈希表的 C# 算法解析
在企业内网监控系统中,哈希表作为一种高效的数据结构,能够快速处理大量网络连接和用户操作记录,确保网络安全与效率。通过C#代码示例展示了如何使用哈希表存储和管理用户的登录时间、访问IP及操作行为等信息,实现快速的查找、插入和删除操作。哈希表的应用显著提升了系统的实时性和准确性,尽管存在哈希冲突等问题,但通过合理设计哈希函数和冲突解决策略,可以确保系统稳定运行,为企业提供有力的安全保障。
|
27天前
|
存储 监控 调度
云服务器成本优化深度解析与实战案例
本文深入探讨了云服务器成本优化的策略与实践,涵盖基本原则、具体策略及案例分析。基本原则包括以实际需求为导向、动态调整资源、成本控制为核心。具体策略涉及选择合适计费模式、优化资源配置、存储与网络配置、实施资源监控与审计、应用性能优化、利用优惠政策及考虑多云策略。文章还通过电商、制造企业和初创团队的实际案例,展示了云服务器成本优化的有效性,最后展望了未来的发展趋势,包括智能化优化、多云管理和绿色节能。
|
28天前
|
搜索推荐 数据挖掘
CRM系统解析:企业高效管理与未来发展的关键
在全球化和技术快速变革的背景下,客户关系管理(CRM)系统已成为企业不可或缺的战略工具。本指南将深入剖析CRM系统的选型、应用及其对企业未来发展的重要影响。
46 5
|
2月前
|
Kubernetes Cloud Native 云计算
云原生技术深度解析:重塑企业IT架构的未来####
本文深入探讨了云原生技术的核心理念、关键技术组件及其对企业IT架构转型的深远影响。通过剖析Kubernetes、微服务、容器化等核心技术,本文揭示了云原生如何提升应用的灵活性、可扩展性和可维护性,助力企业在数字化转型中保持领先地位。 ####
|
2月前
|
存储 人工智能 自然语言处理
高效档案管理案例介绍:文档内容批量结构化解决方案解析
档案文件内容丰富多样,传统人工管理耗时低效。思通数科AI平台通过自动布局分析、段落与标题检测、表格结构识别、嵌套内容还原及元数据生成等功能,实现档案的高精度分块处理和结构化存储,大幅提升管理和检索效率。某历史档案馆通过该平台完成了500万页档案的数字化,信息检索效率提升60%。
|
2月前
|
Prometheus 监控 Cloud Native
实战经验:成功的DevOps实施案例解析
实战经验:成功的DevOps实施案例解析
76 6

相关产品

  • 云解析DNS
  • 推荐镜像

    更多