记一次惊心动魄的 DNS 缓存引发的惨案

记一次惊心动魄的 DNS 缓存引发的惨案,第1张

记一次惊心动魄的DNS缓存引发的惨案

2015年的一个周六凌晨5点,企业官网QQ群有用户反馈。官网打不开,但部分用户反馈可以打开。在线客服站起来用电脑试了一下,没有问题,就给客户反馈可能是自己互联网的问题。请再试一次。

然而,早上8点多,越来越多的用户反馈官网打不开,有的用户一开始打不开反馈App。在线客服打电话给还在做梦的我。

剖析精准定位

被在线客服叫起来后,我一脸迷茫,不知道为什么。然后回复在线客服,知道了,马上去查,之后马上和信息沟通。

我用冷水洗了把脸保持清醒,马上根据工作经验回忆起这几天生产生产的状态:XX控制模块上线,无伤大雅;修复XXBug应该是无害的;服务器刚配了https,好像有点关系。但是App暂时还没有建成投产,不容易出问题。清除它。

打开电脑查看近期的竣工调试记录,应该不会出现这么严重的问题。带着对互联网层面是否有问题的怀疑,马上打电话给运维管理主管及其相关人员,让他们去查一查。

在清理互联网和运维管理问题的同时,我们重新检查了Web服务器、数据库查询服务器、业务流程系统日志、数据库查询系统日志,以及其他监管数据信息,均正常。

我试着ping这个设备上的域名,真的被屏蔽了。我甚至怀疑是网络问题。我试着马上申请外网接入,但是打开没有问题。我基本可以确认服务项目没有问题。但运维管理部门反馈显示,电脑设备一切正常。肯定是大家都完成投产了,编码出了问题。多方咬着牙,正在再次核查。

9 点,群内用户反馈的官网和App,刚开始有较大规模,打不开,部分用户煽风点火,XXX企业主跑路(2015年很多P2P 企业主跑路,导致用户成为惊弓之鸟。有问题就担心企业主跑路,都锻炼成监管大神,天天看高清,瞬间刷,早上。

在再次检查问题的同时,向主管和企业管理层反映,向在线客服提出,向用户明示。IDC主机房网络抖动,技术已紧急处理,对资产和数据信息没有伤害,请冷静。

10点,经过开发设计和运维管理的不断检查,我开始怀疑DNS解析有问题,但实际问题还是不清楚。

因此,首席技术官决定:

  • 大家打车去企业,来企业集团处理。

  • 在各种QQ群、微信聊天群给用户发消息,表达xxx问题,安慰客户。

    在车上,我把用户的所有浏览步骤整理了一遍,如下图:

    到了企业后,我们都按照这个思路一起认证。企业所有服务项目按照外网地址IP和内网IP浏览都是正常的,但是按照域名浏览就不好了。况且监控服务器、服务器防火墙、计算机设备系统日志都正常,所以判断DNS解析有问题。

    行动难题

    也就是确实是DNS解析问题,那么问题出在哪里呢?为什么DNS解析很难?如何处理这个问题?

    在给王湾下订单的同时,我们还测试了电信网、移动和联通在不同运营商下的浏览状态,发现仅在联通的自然环境下无法实现DNS解析。

    根据在线客服的反馈,也验证了这种情况。电信和移动用户反馈很小,联通用户反馈最大。

    所以,大家刚开始给联通打电话。一开始联通没有听到你的要求,只是开始以用户真实身份呼叫联通立即处理无法上网的问题。

    于是,王湾和中国联通的对决拉开了序幕。王湾说向他们询问DNS解析时一切正常,所有指标都正常。大家又打电话给联通,联通说大家已经知道了,技术专业人员会让我们稍后回复。

    过了一会,联通的软件设计师回应说,这样的情况都是域名解析的问题。从上午10点半到企业开工后短短6个小时,大家给联通打了近五六十次电话,给王湾下了n单,接了n个电话。

    这期间领导干部刚开始动用各种人脉,联通内部的盆友和网络维护界都帮了大忙,准确定位处理。大家也尝试了很多方法。

    比如使用ipconfig/flushdns命令擦除设备的dns缓存文件,在王湾官网升级DNS解析,删除后重新添加,都不是完全丢失。

    大家一直在想办法检测各个地区和运营商的网络。最后,在多方强烈推荐和检索的情况下,他们找到了17ce和360云起两个网站,觉得很有用。

    之后在互联网的精准定位上,成为了我必须应用的特殊工具,可以非常方便的监督各个运营商、各个区域网站浏览受阻、浏览速度变快、不满意等问题。截图如下:

    还发现企业其他域名均正常浏览,即该域名及官网相关子域名被屏蔽。

    期间很多人问大家是不是忘了交域名。一开始大家也问运维管理。据说没有这个问题。直到中午12点半,大家反复催他,他还能说8点多登录那几万个网站时域名显示信息是扣费,但他已经马上把费用补上了。

    哎哟!几乎让所有人都疯了。域名过期不是有提醒吗?只是最后一个运维经理走后,他们没有马上升级王湾的电话和邮箱,导致没有提醒邮件和短信。

    根据与王湾、联通、领导干部朋友的交流,以及他们的考察观察,我们基本了解了其中的原因:王湾的DNS解析终止是因为域名忘记付费,用户的设备或DNS服务器有缓存文件,所以有的用户可以浏览,有的用户不能。

    付费后,王湾的DNS早已升级推送。但是很多级别的DNS解析都要一级一级的推到后面,有的级别没有升级,导致DNS服务商下面的一些没有升级到的用户无法浏览官网。

    我与王湾进行了沟通,并询问了最新的延迟。所有DNS都被升级到新的时间。得到的回应是48小时内就没事了,但是大家都等不起。

    随着时间的变化,越来越多的用户发现了问题,QQ群和微信聊天群早已沸腾,老板才刚刚开始关心这个问题。有客户马上在群里说大家技术太差了(像这样还委婉,有的马上电话骂人)…

    临时性解决方法

    根据连续的17ce检测,大部分地区的互联网早就被修复了,只剩下北京联通和部分地区联通网络在自然环境下受阻,这也说明很多地区的DNS解析记录没有升级。

    然后,由于每个人都已经准确地找到了问题所在,并知道发生了什么,他们想知道是否应该尝试更改DNS解析服务器。所以大家可以把本地DNS详细地址改成8.8.8.8(Google的DNS服务项目解析)就知道了!所以,写一个治疗指南,发给焦虑的客户申请。

    官网用户可以根据更换DNS来处理浏览问题。App呢?没办法让大家都等。立即要求开发者临时将手机客户端的详细地址由域名改为外网地址的IP详细地址并键入一个版本号供用户临时申请。

    安卓还是找国企,让用户即时安装下载应用就可以了。但是当时iOS的审批至少要一个星期,金百合凉了。

    其实iPhone是可以独立设置DNS的。经过设置和测试,我们发现它可以完成。于是,我们马上升级到指南,发给在线客服,在线客服再发给群里让用户申请。

    有人说让用户马上申请外网地址就可以了。打开外网地址的主页是没问题的,但是各个系统的软件在启用的时候,域名的详细地址都写在相关的环境变量里。如果很难改变,很可能会引发其他问题。

    第一天吃完已经是晚上10点多了,中间4点多才吃完一顿饭。打了N个电话,大家都很累,所以那是第一天。第二天早上,大家又去企业跟进。

    第二天,我到达了企业号。经过17ce测试,发现所有的连接点都已经连接好了,只有北京联通的两个连接点没有反应。但是北京是大家的大本营,绝大多数用户都是北京人。让我们再次与王湾和中国联通沟通,看看我们如何彻底解决这个问题。

    另一方面,做好最坏的打算,交通一直堵怎么办。在工作环境中,梳理申请域名的所有环境变量,确保在不危及服务项目的情况下,随时随地可以立即升级到外网地址。App会详细再做一个版本号,保证随时随地可以完成投产,以便用户强制升级到外网地址传输数据。

    到第二天晚上10点,北京联通的两个连接点仍被封锁,与领导干部座谈。如果到周一早上8:00,两个互联网连接仍然无法访问,更新的系统软件和App将被强制升级(由于当时周日尚未达到投标价格,投标计划将在数周内发布)。

    第三天早上起床第一件事就是拿出手机检查我的联通网络能不能登陆官网,而且成功了!野心3。

    俗话说,越辩越明。经过这次安全事故,我不得不知道DNS解析的全过程。

    DNS解析步骤

    DNS(域名系统)是“域名系统软件”的英文缩写,是一种为组织的域结构分析而命名电子计算机和互联网服务的系统软件。

    用于TCP/IP互联网,其呈现的服务项目用于将IP地址和域名转换为IP详细地址的工作中。俗话说,DNS就是把一个网址转换成一个详细的对公众开放的IP地址。

    从DNS用户浏览到响应的所有步骤,如下图所示:

    第一步

    计算机浏览器可以检查缓存文件中是否有与该域名匹配的详细IP地址,如果有,则可以完成整个解析过程。浏览器域名也有限制,包括缓存文件的时间和大小,可以根据TTL特性设置。

    第二步

    如果用户的浏览器缓存没有,计算机 *** 作系统将首先检查其本地hosts文档是否有此URL投影关联。如果是,它将首先启用此IP地址映射来解析域名。

    第三步

    如果主机中没有此域名的投影,请搜索本地DNS解析器的缓存文件,查看此URL投影是否有任何关联。如果有,马上回去解析域名。

    第四步

    如果 主机和本地DNS解析器缓存文件没有相对的URL投影关联,它们会先找到TCP/IP的主要参数中设置的首选DNS服务器。在这里,大家都称之为本地 DNS服务器。当该服务器接收到搜索时,如果要搜索的域名包含在本地区域资源中,它会将分析结果返回给远程服务器进行域名解析。这项决议是可信的。

    步骤5

    如果要搜索的域名没有被本地DNS服务器解析,但是服务器已经缓存了这个URL投影关联的文件,那么启用这个IP地址映射来解析域名,是不可信的。

    步骤6

    如果本地DNS服务器无法解析本地文档和缓存文件,将根据本地DNS服务器的设置进行搜索(无论是否设置了发送方)。

    如果不使用共享方法,本地DNS将向13个根DNS发送请求。收到请求后,根DNS服务器将识别谁被授权管理此域名(。com),并将返回一个占用顶级域名服务器的IP。

    收到IP信息后,本地DNS服务器可能会联系负责。com域。收到请求后,如果承担。com域无法自行解决,它会找到一个管理方法。com域的下一级DNS服务器到本地DNS服务器的详细地址。

    当本地DNS服务器接收到这个详细地址时,它将寻找域名服务器,重复上面的姿势,并执行搜索,直到它找到域名匹配的服务器。

    步骤7

    如果使用共享方式,这个DNS服务器会比所有一级DNS服务器提出更高的共享请求,由上级服务器解决。如果上级服务器解决不了,或者找到根DNS或者把转移请求转移到高于所有上级领导的地方,那就是一个循环系统。

    无论本地DNS服务器使用共享还是root提醒,最终结果都是返回给本地DNS服务器,然后DNS服务器返回给远程服务器。

    这件事发生之后,给了我们四个非常大的教训:

  • 流程优化存在系统性漏洞,人员交接不及时。

  • 突发事件处理不成熟危及企业声誉。

    监管制度不完善,对于外网地址被屏蔽等问题,要提前设置监管对策。

    有时候非常严重的问题是由你经常忽略的小问题引起的。

    创作者:纯真的微笑

    作者:陶佳龙和孙淑娟

    资料来源:http://www.ityouknow.com/

    欢迎分享,转载请注明来源:内存溢出

    原文地址: http://outofmemory.cn/zz/763503.html

    (0)
    打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
    上一篇 2022-05-01
    下一篇 2022-05-01

    发表评论

    登录后才能评论

    评论列表(0条)

    保存