用户在浏览器输入www.baidu.com时，DNS域名解析大致分为以下几个过程: 浏览器客户端检查自身有没有该域名的缓存：  如果浏览器有命中，直接返回该域名对应的IP地址，解析结束;  (这个缓存可以设置TTL来控制有效时间，有点像APR协议在本地保存的的目的IP与主机MAC地址的缓存) 如下图:  如果浏览器未命中，浏览器会去检查检查操作系统缓存中有没有对应的已解析过的结果，原理同上;  如果浏览器和OS中都找不到该域名对应的缓存,**那么会请求 本地域名服务器（LDNS）**来解析这个域名，这台服务器一般在距离你的主机比较近的位置，一般情况都会缓存着你要解析域名的结果，大约80%的域名在这里就能解析完成了。  如果LDNS仍然没有命中，就直接跳到Root Server（ 根域名服务器 ）请求解析  根域名服务器返回给LDNS一个所查询域的主域名服务器（gTLD Server，国际顶尖域名服务器，如.com .cn .org等）的地址;  此时LDNS再发送请求给上一步返回的gTLD Server主域名服务器  接受请求的gTLD查找并返回给LDNS注册这个域名时候的Name Server （注册该域名的服务器） 的地址;  LDNS再向Name Server发起解析请求，Name Server会根据映射关系表直接找到目标ip，返回给LDNS  LDNS会缓存这个域名和对应的ip，然后把解析的结果返回给用户;  用户根据TTL值缓存到本地系统缓存中，域名解析过程至此结束;  简单总结DNS域名解析过程: 浏览器首先在自己的缓存找，没有就去系统的缓存，还没就去请求本地域名服务器LDNS(一般到这里就有了) 如果LDNS还没有解析结果，那它就去Root Server根域名服务器请求，Root Server会返回给LDNS一个查询主域名(.com .cn等)的主域名服务器gTLD Server LDNS发起请求gTLD Server，gTLD Server查找并返回给LDNS注册这个域名时候的Name Server地址; LDNS发起请求Name Server，Name Server会根据映射关系表直接找到目标ip，最终返回给LDNS 之后向下交付的过程，这个解析结果会还存在LDNS，本地OS，和浏览器缓存中，方便下次解析;   理解要点: 极端情况下，LDNS扮演者核心中转角色，与ROOT DNS Server 根域名服务器，gTLD Server .xxx对应的主域名服务器 ，Name Server 注册待解析域名的服务器 进行了三次一去一回的循环式交付，最终拿到结果; ———————————————— 版权声明：本文为CSDN博主「魏天乐大帅哥」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/wtl666_6/article/details/128539806 

一  旁站介绍：旁站是攻击目标在同一服务器上的不同网站，在攻击目标没有漏洞的情况下，可以通过查找旁站的漏洞攻击旁站，然后再通过提权拿到服务器的最高权限，拿到服务器的最高权限后攻击目标也就拿到了。二  旁站攻击方法：1 Nmap扫描获取旁站信息使用 nmap -sV -p 1-65535 ip 对目标IP进行全端口扫描。确保每个开放的端口服务都能识别到。命令：nmap -sV -p 1-65535 192.168.88.21扫描效果会出现一些端口的信息通过命令nmap -sV -p 1-65535 ip对ip地址的1-65535端口都进行一次扫描并进行服务识别，发现除了80端口运行了apache的网站外，再800端口还运行了iis服务的网站，800段偶的网站就是80的旁站。再80 端口没有漏洞下，就可以通过800端口运行IIS服务的旁站进行攻击，通过iis服务的漏洞获取到了ip服务器的最高权限，那么运行再ip的服务器80端口的apache服务的所有权限也就拿到了。2 第三方服务获取旁站信息（1）旁站信息可以通过第三方服务进行收集，比较常见的有站长工具 bing搜索、zoomeeye、shodan等站长工具可以进行同ip网站查询，网站为：https://s.tool.chinaz.com/sname.通过查询 www.***.net网站后发现此服务器一共出现三个网站  共有俩个旁站。（2）通过Bing搜索，链接为：https://cn.bing.com/search?q=ip:x.x.x.x.通过Bing搜索对x.x.x.x进行搜索后发现此IP服务器一共开启了3个WEB网站，与站长工具 查询的结果相同。因为 家里网络原因就没做截图的说明 大家可以自己试一下 只做技术交流哦！！！

一 介绍：网络攻防是大学期间必修的课程，在毕业之后也随之要面临着各种网络工程师应该做到的责任，比如保护网络不受非法侵犯，在有能力保护的前提下就需要了解怎么去让网络不受到侵害，而且又是怎么在这个虚拟世界复杂多变情况下获取到真实的ip地址呢？为了保证网络的稳定和快速的传输，网站服务商会在网络的不同位置设置节点服务器，通过CDN的方式和技术，将网络请求分发到最有的节点服务器上面。如果网站开启了CDN加速，就无法通过网站的域名信息获取到真实的IP，要对目标的IP资源进行收集，就需要绕过CDN查询到真实的IP信息才可以。二：如何判断是不是CDN？在对目标的IP信息收集之前呢，首先要判断目标网络是否开启了CDN，一般通过不同地方的主机ping域名的方式和nslookup的方式俩种方法来解析，通过查看发挥的ip是否多个的方式来判断网站是否开启了CDN，如果返回的IP地址信息是多个不同的IP，那么就需要CDN的技术了。1）使用不同zhujiping域名判断是否有CDN如果是自己在多地都有主机可以ping域名，就可以根据返回的IP地址来进行判断，如果使用的俩地主机ping域名是 ***.com的形式 返回的IP信息是39.156.**.79等俩个不同的IP地址，说明这个网站使用了CDN。互联网的很多公开服务都可以进行多地的ping来判断是否开启了CDN，比较常用的有以下几个工具：战场工具：http://ping.chinaz.com/。爱站网：https://ping.aizhan.com/。随便打开一个工具，用一个网站来测试 如果输出的结果是俩个截然不同的ip说明使用了 CDN的方式2）使用nslookup域名解析判断是否有CDN通过系统自带的 nslookup 命令对域名进行解析，发现会有俩个不同的IP地址，说明该域名网站使用了CDN进行了保护。如何绕过CDN获取真实的IP地址呢？1）查询子域名由于CDN加速需要一定的支付费用，很多网站支队主站进行了CDN加速，子网站没有做CDN加速的使用，子域名和主站也很有可能在同一个服务器或则同一个C段网络中，可以通过子域名探测的方式，来手机目标的子域名信息，通过查询子域名的IP信息来辅助判断主站的真实IP地址信息。子域名查询有枚举发现子域名，搜索引擎发现子域名、第三方聚合服务发现子域名、证书透明性信息发现子域名、DNS域传送漏洞会发现子域名等多种方式。2）查询CDN历史记录通过查询DNS和IP绑定的历史记录就有可能发现之前的IP地址的真实信息。一般都是通过第三方的服务网站进行查询常见的查询网站有：dnsdb:https://dnsdb.io/zh-cn微步在线：https://x.threatbook.cn/。以上便是对网络攻防的概念叙述 只做技术交流。

【摘要】 无论你域名怎么解析，最终我还是要用IP和别人通信的。域名只是你的皮囊，IP才是你的灵魂。本文分享自华为云社区《《跟唐老师学习云网络》 - DNS电话簿》，作者： tsjsdbd 。由于TCP/IP网络协议在通信的时候，双方都是用IP地址的。所以整个报文来回过程中，并没有DNS什么事情的。只要双方IP都知道，那么系统中有没有DNS都无所谓的。DNS的最大作用就是把：“名字”==》翻译为==》“IP地址”。 手机地址簿DNS等于是一个大号版的“地址簿”。跟你手机打电话一样，你最终拨打出去的肯定是手机号。   而你查找联系人，只是为了获得对方手机号码而已。假如你脑袋里已经默记了号码，那是可以直接拨号通话的，并不需要先打开“联系人or地址簿”的。      DNS域名解析，是我们在网络中很容易接触到的通信过程。有时候网络不通，并不是你和对方无法连通，只是你无法根据名字“翻译”为对方的实际IP地址，千万不要被主次问题给困惑了。很多时候，如果可以查询到实际IP，实际网络则是通的。（当然，知道了IP，网络还是不通的话，可以复习下唐老师之前的网络课程）。 域名的来源  两台电脑在通信的时候，是使用之前介绍过的网络协议栈（即TCP/IP）的。但是，有时候，IP地址属实不好记忆。别说是IPV4了，后面IPV6地址，根本就不是给人记的。就跟电话号码一样，多了就是不好记，必须得把号码关联到一个“人名”上，用来助记。于是，这个世界上就有了“域名”一词，用来助记IP地址。 你想：github.com 总比 20.205.243.166 好记吧？所以大家都爱记名字，然后在通信之前，不闲麻烦的先翻译一次。怎么把名字变成IP，就是DNS解析过程了。这个时候就得有个“专门记录名字=>IP”的服务器。DNS服务器搞协议的那帮人，为了解决名字==》IP的问题。引入了一个叫做域名服务器的东西。这个DNS服务器，就是一个 key-value 的大号map表。大概就是 ：Key[名字] --> Value（IP地址）所以DNS服务器，都挺小巧的。它的复杂是在于DNS服务器之间可以级联， 这个后面再细说。总之它就是一台很小的 key-value的Server。 本地快速解析有时候，局域网里面，还得自己搭建一台DNS服务器，也挺麻烦。 那有没有简单点的 ，直接把key-value先写死顶着用一下先的办法？答案是有的，就是咱们的 /etc/hosts 文件啦。（windows则是C:\Windows\System32\drivers\etc\hosts文件）它的内容是长这样的：# value(IP)  key(域名)192.168.1.11  www.google.com你可以试着增加一行，然后看看在浏览器里面，访问这个网站是不是变了。我这里直接ping这个网址# ping google.comPING google.com (192.168.1.11) 56(84) bytes of data.你看，地址就变成文件中指定的IP了。 查询DNS的命令行一般我就用2个， nslookup 和 digapt-get install dnsutils安装之后，这2个命令行，就都有了。 nslookup命令这个是用的最多的，格式是：nslookup 目标域名比如：上面的Server地址，是指问了“哪个DNS服务器”。而下面标红线的IP，则是它给你的答复：“google.com的IP是 93.46.8.90”域名找不到IP，则是这样： dig命令行这个dig比nslookup好的地方在于，它可以指定DNS服务器，来帮你解析域名。格式：dig  目标域名dig  @特定DNS服务器  目标域名中间的 @参数，是可选的。能不能解析，看红圈那个 ANSWER，如果是0，那说明解析不了这个域名。最后试下指定 DNS服务器来解析域名。 上图里指定，用10.129.54.132 这台DNS服务器来帮我们解析域名。DNS协议这个DNS协议非常的简单，就是一问一答的格式，没什么握手过程。客户端问：“请问zz的ip是多少”服务端答：“哦，是xx.xx.xx.xx”。 或者“我不知道”。 协议默认端口是53.  所以在定位问题的时候，可以试着抓端口53的报文，看看你和DNS服务器之间是否还和谐。绝大多数时候使用的是UDP协议，但也可以用TCP（很少）。 指定DNS服务器系统默认的DNS服务器，（即默认应该去哪个DNS服务器查询IP），一般都是管理员帮我们配置好的。但是我们也可以自己修改，在 /etc/resolv.conf 文件中。cat /etc/resolv.confnameserver 10.129.2.34nameserver这一行，可以copy多行，当第一个DNS服务器不可用时，会自动去问第2个DNS服务器。如：cat /etc/resolv.confnameserver 10.129.2.34nameserver 100.79.1.250nameserver 100.79.1.46这样有配置3台DNS服务器高级配置参数这个 /etc/resolv.conf文件中，还可以配置一些高级参数。search：查询DNS域名时，会往你查询的域名尾部，额外补全的内容。ndots：控制补全的最大长度。这个会在Kubernetes的Service特性里面用到，等需要的时候，可以自己去深入研究下。平时用不到这些高级参数。DNS级联DNS有个级联机制，即：当我（DNS服务器）这里的key找不到value时，我可以问我的上级。上级不懂再问上级，全球有几台顶级的根域名服务器。 所以你想要拥有全球知名的网址（域名），都都是被收割的对象，因为取名权，被他们垄断了。想取一个“大家都认得”的名字，得老贵了。除非咱们自己不联网，局域网内自己玩，那么爱取什么名字就用什么名。回到你本地机器，查询DNS域名的时候，整个过程大致如下： 如果问了一圈还找不到，就会告诉你，这个域名确实解析不了（要么就是根本不存在这个域名，要么就是你的DNS服务器里没这条记录，并且也得不到上级的答案）。ps，无论你域名怎么解析，最终我还是要用IP和别人通信的。域名只是你的皮囊，IP才是你的灵魂。

【功能模块】网络连接【操作步骤&问题现象】1. 在容器中没有域名解析功能，ping 8.8.8.8 可以通， ping www.baidu.com 不通，如何使得容器具有域名解析功能？2. 容器中的串口通过手动设置后，程序可以访问串口，但每次重启容器后，串口用户和分组自动更变为 nobody, 造成程序无权限访问，该如何解决呢？3. 当AR502H同时连接有线网络和4G网络时，如何获取有线网络状态、4G网络状态，是不是网络在线的呢？如果使用C/C++程序可以获取在线状态吗？【截图信息】【日志信息】（可选，上传日志内容或者附件）

【功能模块】【操作步骤&问题现象】1、教程和软件指令属性网元类型中一个是DNS，一个DSN？2、【截图信息】【日志信息】（可选，上传日志内容或者附件）

目前，业界已达成共识：IPv6技术是当前可行的解决IP地址短缺唯一根本的解决方案。但是由于IPv6与IPv4技术不兼容，而且现网中有大量的IPv4设备和用户存在，需要在网络演进过程中解决异构网络的共存与互通问题。现今IP网络仍然是以IPv4为主体，IPv6网络只是得到小范围的部署和商用，因此必然会在很长的一个时期内，IPv4及IPv6网络必然会有共存的场景，那就需要考虑V4V6并存的策略和技术。从技术本质上讲，解决IPv4地址短缺，可以采用两种不同的技术路线，一种是多级NAT(如NAT444)技术，另一种是IPv6技术，这两种技术是完全对立的。从长远来看，NAT技术并不能从根本上解决地址短缺的问题，而且会增加网络结构的复杂性。目前，业界已达成共识：IPv6技术是当前可行的解决IP地址短缺唯一根本的解决方案。但是由于IPv6与IPv4技术不兼容，而且现网中有大量的IPv4设备和用户存在，需要在网络演进过程中解决异构网络的共存与互通问题。 IPv4向IPv6过渡的3个阶段当前，大量的网络是IPv4网络，随着IPv6的部署，很长一段时间是IPv4与IPv6共存的过渡阶段。通常将IPv4向IPv6过渡分为3个阶段：初始阶段IPv4网络占绝对的主导地位，IPv4网络中出现若干IPv6孤岛，这些孤岛通过IPv4网络连接到一起。共存阶段随着IPv6网络的部署，IPv6得到较大规模的应用，出现若干骨干IPv6网络，IPv6平台中的业务也不断增加。但不同的IPv6网络之间需要通过IPv4网络连接到一起，以及IPv4主机与IPv6主机的互通。这阶段不但要使用双栈技术、隧道技术，还需要网络协议转换技术主导阶段IPv6网络和主机占主导地位。当IPv6发展到后来，骨干网全部是IPv6，而IPv4网络成了孤岛。类似于发展初级阶段，主要采取隧道技术来部署，但现在隧道互联的是IPv4网络了。IPv4和IPv6共存互通的三个技术双栈所谓的双栈就是主机或者网络设备同时支持IPv4及IPv6双协议栈，如果节点支持双栈，那么它能够同时使用V4和V6的协议栈、同时处理IPv4及IPv6的数据。在双栈设备上，上层应用会优先选择IPv6协议栈，而不是IPv4。 比如，一个同时支持v4和v6的应用请求通过DNS请求地址，会先请求AAAA记录，如果没有，则再请求A记录。双栈是V4、V6并存及IPv6过渡技术的基础。隧道技术隧道技术是一种非常经典的解决方案，被应用在各种场景中解决数据通信问题。核心思想其实就是在两个通信孤岛之间搭建一条点到点的虚拟通道，使得此二者能够通过这条点到点隧道穿越中间的网络进行通信。NAT64NAT64技术实际上是一种协议转换技术，能够将分组在V4及V6格式之间灵活转换。当IPv4网络的节点需要直接与IPv6网络的节点进行通信时，默认情况下当然是行不通的，因为两个协议栈无法兼容。但是借助一台设备，由该设备来实现IPv6与IPv4的互转，那么上述通信需求就可以实现了。智能云网智能云网社区是华为专为开发者打造的“学习、开发、验证、交流”一站式支持与服务平台，该平台涵盖多领域知识。目前承载了云园区网络，云广域网络，数通网络开放可编程，超融合数据中心网络，数通网络设备开放社区共五个场景。为了响应广大开发者需求，还提供了开发者交流、API 体验中心、多媒体课件、SDK工具包、开发者工具以及远程实验室共六大工具，让开发者轻松开发。欢迎各位前来体验。>>戳我了解更多<<

据悉，uClibc库域名系统（DNS）组件中的一个漏洞影响了数百万的物联网设备。全球工业网络安全领域领导者Nozomi Networks警告说，大量物联网产品使用的uClibc库域名系统（DNS）组件中存在漏洞，被追踪为CVE-2022-05-02。该漏洞还影响所有版本的uClibc-ng库的域名系统（DNS），uClibc-ng库是专门为关键基础设施部门路由器的通用操作系统OpenWRT设计的分支。攻击者可以利用该漏洞发起DNS缓存中毒或DNS欺骗的网络攻击，并将受害者重定向到恶意网站而不是合法网站。Nozomi Networks在公告中表示，该漏洞是由库生成的DNS请求中包含的事务ID可预测性引起的，这使得攻击者能够对目标设备发起DNS中毒攻击。uClibc库被主要的供应商使用，包括Linksys、Netgear和Axis，以及Embedded Gentoo等Linux发行版。因为供应商尚未解决该问题，所以安全专家没有透露该漏洞的细节。Nozomi的研究人员通过查看物联网设备在其测试环境中执行DNS请求的过程发现了这个问题。他们能够从Wireshark的输出中确定执行DNS请求的模式，事务ID首先是递增的，然后重置为0x2值，然后再次递增。请求的事务ID是可预测的，这种情况可能允许攻击者在某些情况下发起DNS中毒攻击。研究人员分析了该可执行文件，发现创建DNS请求的问题存在于C标准库uClibc的0.9.33.2版本中。Nozomi Networks还表示：“源代码审查显示，uClibc库通过调用位于源文件"/libc/inet/resolv.c "中的内部"__dns_lookup "函数来实现DNS请求。鉴于事务ID现在是可预测的，要利用该漏洞，攻击者需要制作包含正确源端口的DNS响应，并赢得它与合法DNS响应之间的竞争。该漏洞的可利用性完全取决于这些因素。由于该功能没有应用任何明确的源端口随机化，如果操作系统被配置为使用固定或可预测的源端口，它就很可能被轻松地利用。”如果操作系统使用源端口的随机化，则利用该问题的唯一方法是通过发送多个DNS响应来暴力破解16位源端口号，同时赢得与合法响应之间的竞争。Nozomi Networks总结道：“正如预期的那样，截至本博客发布时，该漏洞仍未被修补。维护者无法为该漏洞开发修复程序，他们希望能够获得帮助。自2022年1月以来，计算机紧急事件响应小组协调中心已向200多家受邀参与VINCE案例的供应商披露了该漏洞。”转载自http://www.iotworld.com.cn/html/News/202205/17d8a538337f315d.shtml

按照以上说明配置yum源，一直报错Failed to synchronize cache for repo 'base', ignoring this repo.ping不通 ping: http://repo.huaweicloud.com/euler/2.8/os/aarch64/: Name or service not known已自查下面三个原因均不是，请问是否是源失效了？/etc/resolv.conf未配置DNS地址或者DNS地址错误导致。/etc/nsswitch.conf文件删除DNS解析记录导致。/lib64/libnss_dns.so.2库文件丢失导致无法解析域名。

【功能模块】您好，我现在roma里api调第三方接口时报第三方接口的域名解析失败，请问这个要怎么解决？【操作步骤&问题现象】1、2、【截图信息】【日志信息】（可选，上传日志内容或者附件）

我现在有一个上传obs日志的需求，在需要用从obs服务器获取的地址来上传，但是本地无法解析获取到的地址，因此想指定dns ip来上传。有谁知道obs的dns ip一般是什么吗

DNS污染，又称为域名服务器缓存污染(DNS cache pollution)或者域名服务器快照侵害(DNS cache poisoning)DNS污染，又称为域名服务器缓存污染(DNS cache pollution)或者域名服务器快照侵害(DNS cache poisoning)。DNS污染是指一些刻意制造或无意中制造出来的域名服务器分组，把域名指往不正确的IP地址。一般来说，网站在互联网上一般都有可信赖的域名服务器，但为减免网络上的交通，一般的域名都会把外间的域名服务器数据暂存起来，待下次有其他机器要求解析域名时，可以立即提供服务。一旦有相关网域的局域域名服务器的缓存受到污染，就会把网域内的电脑导引往错误的服务器或服务器的网址。某些网络运营商为了某些目的，对DNS进行了某些操作，导致使用ISP的正常上网设置无法通过域名取得正确的IP地址。某些国家或地区为出于某些目的防止某网站被访问，而且其又掌握部分国际DNS根目录服务器或镜像，也可以利用此方法进行屏蔽。这和某些运营商利用DNS劫持域名发些小广告不同，DNS污染则让域名直接无法访问了，非得修改DNS服务器不可。如果你想检测网络时候收到DNS的污染所影响，可以通过以下三个步骤：1、点“开始”-“运行”-输入CMD，再输入 ipconfig /all ，在下“DNS SERVER”（中文：DNS服务器）里找到你使用的DNS服务器地址。2、再输入 nslookup www.xxxxxxx.com（你的域名）+【空格】+【你的DNS服务器IP 】，来查看是否能解析。3、再输入 nslookup www.xxxxxxx.com 8.8.8.8 使用Google的DNS服务器验证。

CoreDNS用于集群内部Service名称解析。coreDNS服务监视kubernetes api , 为每一个service创建dns记录,用于域名解析;这样访问pod资源时只需要访问service名即可，而不需要关心pod容器的ip地址的变化。[root@master ~]# cat coredns.yamlapiVersion: v1kind: ServiceAccountmetadata:  name: coredns  namespace: kube-system  labels:      kubernetes.io/cluster-service: "true"      addonmanager.kubernetes.io/mode: Reconcile---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:  labels:    kubernetes.io/bootstrapping: rbac-defaults    addonmanager.kubernetes.io/mode: Reconcile  name: system:corednsrules:- apiGroups:  - ""  resources:  - endpoints  - services  - pods  - namespaces  verbs:  - list  - watch---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  annotations:    rbac.authorization.kubernetes.io/autoupdate: "true"  labels:    kubernetes.io/bootstrapping: rbac-defaults    addonmanager.kubernetes.io/mode: EnsureExists  name: system:corednsroleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: system:corednssubjects:- kind: ServiceAccount  name: coredns  namespace: kube-system---apiVersion: v1kind: ConfigMapmetadata:  name: coredns  namespace: kube-system  labels:      addonmanager.kubernetes.io/mode: EnsureExistsdata:  Corefile: |    .:53 {        errors        health        kubernetes cluster.local in-addr.arpa ip6.arpa {            pods insecure            upstream            fallthrough in-addr.arpa ip6.arpa        }        prometheus :9153        proxy . /etc/resolv.conf        cache 30        loop        reload        loadbalance    }---apiVersion: apps/v1kind: Deploymentmetadata:  name: coredns  namespace: kube-system  labels:    k8s-app: kube-dns    kubernetes.io/cluster-service: "true"    addonmanager.kubernetes.io/mode: Reconcile    kubernetes.io/name: "CoreDNS"spec:  # replicas: not specified here:  # 1. In order to make Addon Manager do not reconcile this replicas parameter.  # 2. Default is 1.  # 3. Will be tuned in real time if DNS horizontal auto-scaling is turned on.  strategy:    type: RollingUpdate    rollingUpdate:      maxUnavailable: 1  selector:    matchLabels:      k8s-app: kube-dns  template:    metadata:      labels:        k8s-app: kube-dns      annotations:        seccomp.security.alpha.kubernetes.io/pod: 'docker/default'    spec:      serviceAccountName: coredns      tolerations:        - key: node-role.kubernetes.io/master          effect: NoSchedule        - key: "CriticalAddonsOnly"          operator: "Exists"      containers:      - name: coredns        image: lizhenliang/coredns:1.2.2        imagePullPolicy: IfNotPresent        resources:          limits:            memory: 170Mi          requests:            cpu: 100m            memory: 70Mi        args: [ "-conf", "/etc/coredns/Corefile" ]        volumeMounts:        - name: config-volume          mountPath: /etc/coredns          readOnly: true        ports:        - containerPort: 53          name: dns          protocol: UDP        - containerPort: 53          name: dns-tcp          protocol: TCP        - containerPort: 9153          name: metrics          protocol: TCP        livenessProbe:          httpGet:            path: /health            port: 8080            scheme: HTTP          initialDelaySeconds: 60          timeoutSeconds: 5          successThreshold: 1          failureThreshold: 5        securityContext:          allowPrivilegeEscalation: false          capabilities:            add:            - NET_BIND_SERVICE            drop:            - all          readOnlyRootFilesystem: true      dnsPolicy: Default      volumes:        - name: config-volume          configMap:            name: coredns            items:            - key: Corefile              path: Corefile---apiVersion: v1kind: Servicemetadata:  name: kube-dns  namespace: kube-system  annotations:    prometheus.io/port: "9153"    prometheus.io/scrape: "true"  labels:    k8s-app: kube-dns    kubernetes.io/cluster-service: "true"    addonmanager.kubernetes.io/mode: Reconcile    kubernetes.io/name: "CoreDNS"spec:  selector:    k8s-app: kube-dns  clusterIP: 10.0.0.2   ports:  - name: dns    port: 53    protocol: UDP  - name: dns-tcp    port: 53    protocol: TCP[root@master ~]# [root@master ~]# kubectl apply -f coredns.yamlserviceaccount/coredns createdclusterrole.rbac.authorization.k8s.io/system:coredns createdclusterrolebinding.rbac.authorization.k8s.io/system:coredns createdconfigmap/coredns createddeployment.apps/coredns createdservice/kube-dns created查看生成的pod:kubectl get pods -n kube-system NAME                          READY   STATUS    RESTARTS   AGEcoredns-5ffbfd976d-j6shb      1/1     Running   0          32sDNS解析测试：kubectl run -it --rm dns-test --image=busybox:1.28.4 shIf you don't see a command prompt, try pressing enter./ # nslookup kubernetesServer:10.0.0.2Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.localName:kubernetesAddress 1: 10.0.0.1 kubernetes.default.svc.cluster.local地址解析没有问题。

【关 键 词】：登录报错账户或密码错误，排查正常【问题现象】：局点无法远程，客户登录虚拟机时，提示6009报错，用户名或密码错误，在客户AD上修改了密码之后登录还是报错，VNC可以登录。出现报错后，重启虚拟机，可以概率性成功登陆。【问题分析】：1、查看日志，提示用户名或密码错误。2、查看FA上配置的主备AD，在主备AD上执行repadmin /showreps检查主备AD的同步状态，同步均正常。3、从VNC登陆进去之后，使用nslookup解析域名，发现域名对应有四个IP，而FA上只配置了两个IP。4、出排查指导文档，让一线按照指导检查，检查SRV记录正常，但发现客户的DNS记录里面，配置有条件转发，且转发的域名和该域的域名一致，导致用户登录鉴权时，概率性的被转发了，关闭该条件转发后，登录正常。

【故障类型】：DNS解析概率性失败【关 键 词】： AD【适用版本】：所有AD、DNS版本【问题现象】：客户搭建环境时在备AD的管理网卡中勾选了管理网卡的“在DNS中注册此连接的地址（R）”，然后去掉勾选，并删除DNS中对应记录，但是告警还会是不是的出现【告警信息】：虚拟机随机性脱域【问题分析】：检查ITA到AD的网络及端口，正常检查主备DNS中的记录，同时删除多余的记录，主备AD同步正常检查主备DNS的网卡配置，配置正常使用ipconfig /renew更新本地的DNS记录，过段时间还会出现删除” C:\Windows\System32\dns\CACHE.DNS”的DNS缓存【解决方法】：删除DNS的缓存文件” C:\Windows\System32\dns\CACHE.DNS”【总结&建议】：删除DNS的缓存文件” C:\Windows\System32\dns\CACHE.DNS”