DNS服务-了解篇

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
云解析DNS,个人版 1个月
简介: 简介 DNS是用来名字解析的,名字解析成IP地址,IP地址解析成名字,正反操作,有服务器端和客户端即 S/C DNS是应用层协议,基于UDP/53、TCP/53端口,缺一不可 分为正向解析和反向解析/递归查询、迭代查询 注意:正反向解析是两个不同的名称空间,是两棵不同的解析树   ...

 

简介

DNS是用来名字解析的,名字解析成IP地址,IP地址解析成名字,正反操作,有服务器端和客户端即 S/C

DNS是应用层协议,基于UDP/53、TCP/53端口,缺一不可

分为正向解析和反向解析/递归查询、迭代查询

注意:正反向解析是两个不同的名称空间,是两棵不同的解析树

 

名称解析:主机名解析

把一种名称转换为另一种名称的过程

根据用户提供的名称,去查询解析库,以得到另一种名称

hosts:文本文件

用户自定义了对应的解析列表即要解析的FQDN与IP地址对应关系

有时候hosts很好的解决了DNS服务器访问不了的情况

如:某个域所在的权威DNS服务器出问题了,网站图片不显示等,这时候在hosts文本里写上对应的FQDN和IP地址就可。

备注:FQDN也就是我们所说的网址,如www.xxx.com

          如果在本机定义了hosts文本则优先本列表,本列表没有再去DNS库查询

 

递归查询

用户向第一个DNS服务发请求,DNS收到后,如果它这有直接的结果就直接给你,如果没有就会向根DNS服务询问,层层询问直到问道结果返回给你,负责到底

迭代查询

上述过程中去问根,根给你推荐别人,你去问它,这就是迭代查询,不会负责到底

DNS域结构图

image

备注:如 www.xxx.com 

         www:可以是主机或别名

         xxx.com:是域名

 

DNS服务器类型

主DNS服务器
从DNS服务器
缓存DNS服务器(转发器)

主DNS服务器:管理和维护所负责解析的域内解析库的服务器

从DNS服务器:从主服务器或从服务器“复制”(区域传输)解析库副本

序列号:解析库版本号,主服务器解析库变化时,其序列递增

刷新时间间隔:从服务器从主服务器请求同步解析的时间间隔

重试时间间隔:从服务器请求同步失败时,再次尝试时间间隔

过期时长:从服务器联系不到主服务器时,多久后停止服务

一次完整的查询请求经过的流程:

Client -->hosts文件 -->DNS Service Local Cache --> DNS Server (recursion) --> Server Cache --> iteration(迭代) --> 根--> 顶级域名DNS-->二级域名DNS…

解析答案:

肯定答案:

否定答案:请求的条目不存在等原因导致无法返回结果

权威答案:你请求的dns服务器正好是负责这个链接域的dns

非权威答案:dns服务器问别人,别人告诉它的,有时候会是假的,比如国外某些网站访问不了,就是dns告诉给你一个错误的答案,不让你访问(DNS的污染,信息篡改了)

备注:名字解析成不成功和能不能上网是两码事

 

资源记录

区域解析库:由众多RR组成:
资源记录:Resource Record, RR
记录类型:A, AAAA, PTR, SOA, NS, CNAME, MX


SOA:Start Of Authority,起始授权记录;一个区域解析库有且仅能有一个SOA记录,
必须位于解析库的第一条记录
A:internet Address,作用,FQDN --> IP
AAAA: FQDN --> IPv6
PTR:PoinTeR,IP --> FQDN
NS:Name Server,专用于标明当前区域的DNS服务器
CNAME:Canonical Name,别名记录
MX:Mail eXchanger,邮件交换器

 

资源记录定义的格式:

语法:

name(名称) [TTL](生命期) IN(intnet记录) rr_type(资源记录的类型)value(值)

   rr_type类型:有 A(ipv4)、 AAAA(ipv6)、SOA、NS(这两种最重要)

 

注意:

(1) TTL可从全局继承

(2) @可用于引用当前区域的名字

(3) 同一个名字可以通过多条记录定义多个不同的值;此时DNS服务器会以轮询

方式响应

(4) 同一个值也可能有多个不同的定义名字;通过多个不同的名字指向同一个值

进行定义;此仅表示通过多个不同的名字可以找到同一个主机

 

记录介绍

image

MX记录:邮件交换器

clipboard

注意:
(1) 对MX记录而言,任何一个MX记录后面的服务器名字,都应该在后续有一个A记录

 

DNS服务器 bind配置文件说明

clipboard

clipboard

named.conf主配置文件说明

//  
// named.conf  
//  
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS  
// server as a caching only nameserver (as a localhost DNS resolver only).  
//  
// See /usr/share/doc/bind*/sample/ for example named configuration files.  
//  
  
options {  // 定义全局变量  
        listen-on port 53 { 127.0.0.1; }; // ipv4 监听端口  
        listen-on-v6 port 53 { ::1; };    // ipv6 监听端口  
        directory       "/var/named";     // 制定装载zone区域文件的目录 
        dump-file       "/var/named/data/cache_dump.db";    // cache  
        statistics-file "/var/named/data/named_stats.txt";  // statistics  
        memstatistics-file "/var/named/data/named_mem_stats.txt";  
        allow-query     { localhost; };   // 允许访问列表  
        recursion yes; //递归查询 
  
        dnssec-enable yes;  //DNS确保应答报文的完整性
        dnssec-validation yes;  
        dnssec-lookaside auto;  
  
        /* Path to ISC DLV key */  
        bindkeys-file "/etc/named.iscdlv.key";  
}; // "}"后也得分号结束  
  
logging {  
        channel default_debug {  
                file "data/named.run";  
                severity dynamic;  
        };  
};  
  
zone "." IN {            // "."代表根区域  
        type hint;       // 根区域的类型就为hint  
        file "named.ca"; // 指定zone文件,默认已经生成  
};  
  
include "/etc/named.rfc1912.zones";  //存放自定义的区域文件

 

备注:配置文件总体来说分为三大块选项、日志、区域

 

目录
相关文章
|
2月前
|
监控 负载均衡 Cloud Native
ZooKeeper分布式协调服务详解:面试经验与必备知识点解析
【4月更文挑战第9天】本文深入剖析ZooKeeper分布式协调服务原理,涵盖核心概念如Server、Client、ZNode、ACL、Watcher,以及ZAB协议在一致性、会话管理、Leader选举中的作用。讨论ZooKeeper数据模型、操作、会话管理、集群部署与管理、性能调优和监控。同时,文章探讨了ZooKeeper在分布式锁、队列、服务注册与发现等场景的应用,并在面试方面分析了与其它服务的区别、实战挑战及解决方案。附带Java客户端实现分布式锁的代码示例,助力提升面试表现。
440 2
|
2月前
|
人工智能 NoSQL atlas
4大企业实例解析:为何MongoDB Atlas成为AI服务构建的首选
本文所提及的仅是MongoDB Atlas在AI领域可实现功能的冰山一角
1669 1
|
2月前
|
网络协议 应用服务中间件 nginx
【CKA模拟题】如何用Nslookup轻松检查集群服务名的DNS解析?
【CKA模拟题】如何用Nslookup轻松检查集群服务名的DNS解析?
128 2
|
2月前
|
域名解析 网络协议 安全
【域名解析DNS专栏】云服务中的DNS解析服务比较:阿里云、AWS、Azure大PK
【5月更文挑战第23天】此对比分析探讨了阿里云DNS、AWS Route 53和Azure DNS的服务特点。阿里云DNS以其智能解析和IPv6支持脱颖而出,适合中国地区用户;AWS Route 53凭借其强大的路由策略和与AWS生态的深度集成吸引高级用户;Azure DNS则以简洁管理和DNSSEC安全支持见长,与Azure平台集成良好。选择取决于具体需求,如功能、易用性、性能、安全性和成本。
【域名解析DNS专栏】云服务中的DNS解析服务比较:阿里云、AWS、Azure大PK
|
2月前
|
域名解析 网络协议 网络性能优化
如何提升自建DNS服务下的网络体验
网络质量和网络体验是通信过程中的两个不同层面,质量涉及设备上下行表现,而体验关乎端到端通信效果。衡量质量常用带宽、延迟、丢包率等指标;体验则关注可访问性,DNS解析速度和服务位置等。现代路由器能自动调整网络质量,普通用户无需过多干预。自建DNS服务时,选择权威DNS能解决可访问性,但可能不提供最优体验。AdguardHome和Clash等工具能进一步优化DNS解析,提升网络体验。
91 6
如何提升自建DNS服务下的网络体验
|
2月前
|
Linux 编译器 调度
xenomai内核解析--双核系统调用(二)--应用如何区分xenomai/linux系统调用或服务
本文介绍了如何将POSIX应用程序编译为在Xenomai实时内核上运行的程序。
97 1
xenomai内核解析--双核系统调用(二)--应用如何区分xenomai/linux系统调用或服务
|
2月前
|
域名解析 缓存 负载均衡
【域名解析DNS专栏】域名解析在CDN服务中的应用与优化
【5月更文挑战第30天】本文探讨了域名解析在CDN服务中的重要性,强调其对访问速度和稳定性的影响。文中提出了三种优化方法:使用智能解析以动态选择最佳节点,配置负载均衡保证服务稳定,以及利用DNS缓存提升访问速度。通过Python代码示例展示了基本的DNS解析过程,结论指出优化域名解析对于提升网站性能至关重要。
|
2月前
|
域名解析 Kubernetes 网络协议
【域名解析DNS专栏】云原生环境下的DNS服务:Kubernetes中的DNS解析
【5月更文挑战第29天】本文探讨了Kubernetes中的DNS解析机制,解释了DNS如何将服务名转换为网络地址,促进集群内服务通信。Kubernetes使用kube-dns或CoreDNS作为内置DNS服务器,每个Service自动分配Cluster IP和DNS条目。通过示例展示了创建Service和使用DNS访问的流程,并提出了优化DNS解析的策略,包括使用高性能DNS解析器、启用DNS缓存及监控日志,以实现更高效、可靠的DNS服务。
|
2月前
|
网络协议
阿里云服务器搭建DNS解析服务步骤
在阿里云搭建DNS解析服务,首先注册阿里云账号并购买适合的云服务器。获取服务器公网IP后,配置服务器并安装DNS软件如Bind9。接着设置DNS解析,包括定义顶级和子域名的指向。最后,通过ping测试或浏览器访问验证DNS解析功能是否正常。
114 5
|
2月前
|
存储 弹性计算 监控
【阿里云弹性计算】阿里云ECS全面解析:弹性计算服务的核心优势与应用场景
【5月更文挑战第20天】阿里云ECS是提供可伸缩计算能力的云服务,支持多种规格实例,满足不同需求。其核心优势包括灵活性、高性能、高可用性、安全性和易用性。适用场景包括网站托管、大数据处理、游戏多媒体应用及测试开发环境。通过Python示例代码展示了如何创建ECS实例,助力企业专注业务发展,简化基础设施管理。
103 5

相关产品

  • 云解析DNS
  • 推荐镜像

    更多