学习
实践
活动
专区
工具
TVP
写文章
专栏首页运维部落Nginx 动态DNS解析方案: resolver

Nginx 动态DNS解析方案: resolver

Nginx 动态DNS解析方案: resolver

运维就要无所不能,无所不会

大家好,我是Stanley「史丹利」,你们已经回家我,而我还在学习「其实是因为撞车了,请假计划被打乱了...」。今天聊 nginx 动态dns 解析。【似乎发现 Nginx 的一个 BUG】

问题排查过程比较长,不感兴趣的朋友可直接跳到文末看结论和 Nginx resolver 的注意点

文章目录如下:

  • 一、背景
  • 二、动态解析方案
    • 方案一:每次dns有变化,重启Nginx
    • 方案二:使用Nginx Resolver
    • 方案三:使用 Nginx-upstream-dynamic-server
    • 方案四:使用 ngx_upstream_jdomain
  • 三、Nginx Resolver 方案测试【BUG】
    • 3.1 排除粗心手误问题
    • 3.2 排除测试方案问题
    • 3.3 排除DNS配置问题
    • 3.4 排除域名重复配置问题
  • 四、排查过程总结及Nginx Resolver注意点

一、背景

PHP架构核心技术栈是LNMP,业务接口互调的主流方式:

  • 方式一:程序内部路由
  • 方式二:标准RESETful接口
  • 方式三:通过 Nginx proxy 透传

最理想的方案是:方式一,但不同业务之间的接口,跨项目调用并不适用。

所以推荐方案是方式二。但对开发精力投入和codeing有挑战,在公司内部推行难度奇大,尤其初创期的公司基本不可能。光就这点而言,SpringCloud的统一网关架构ZUULGateway确实要比PHP高明。

个人认为:随着IT互联网不断成熟,小步快跑不断被挑战的,慢就是快理念不断举起的意识下。轻量级PHP语言是否真的快,确实要不断被挑战。前有前端技术语言的快速迭代,纯静态页面逐步成为主流。后面golang新兴高并发语言,Java工程级别架构语言。PHP的定位确实很尴尬,这可能也是PHP市场不断萎缩的原因。吧

剩下的方式三,是我们现在应用比较多的场景。主要以 upstream 和 proxy_pass 为主。

  • upstream方式
    upstream upstream_1 {
        ip_hash;
        server 10.1.1.1:80  max_fails=3 fail_timeout=31s;
        server 10.1.1.2:80  max_fails=3 fail_timeout=31s;
        keepalive 10;
    }
    
    location /abc/ {
        proxy_pass upstream_1;
        ...
    }

如上为目录主流upstream方式

  • Proxy url
location /out_ip/ {
    out_ip.example.com;
}

该方式是nginx proxyResetFul 结合的“变种”。通常情况下,out_ip.example.com 是作为 ResetFul 的标准接口调用,但少数情况是 out_ip.example.com 同样是 Proxy 角色,后端会有转发或 upstream 到多台Real Server.

Proxy最大的问题是:后端Real Server变更时, Nginx 不会主动更新DNS缓存,很不幸,我们还因此引发了一场小事故(对方变更,未通知我们重启nginx)

官网原文如下:

As NGINX starts up or reloads its configuration, it queries a DNS server to resolve backends.example.com. The DNS server returns the list of three backends discussed above, and NGINX uses the default Round Robin algorithm to load balance requests among them. NGINX chooses the DNS server from the OS configuration file /etc/resolv.conf. This method is the least flexible way to do service discovery and has the following additional drawbacks:

  • If the domain name can’t be resolved, NGINX fails to start or reload its configuration.
  • NGINX caches the DNS records until the next restart or configuration reload, ignoring the records’ TTL values.
  • We can’t specify another load‑balancing algorithm, nor can we configure passive health checks or other features defined by parameters to the server directive, which we’ll describe in the next section.
  • Nginx 在启动/重载的时候回去解析转发的域名
  • 如果域名无法解析 Nginx 就无法启动
  • 只有下次重启/重载的时候才会重新去解析,启动后无视TTL

https://www.nginx.com/blog/dns-service-discovery-nginx-plus/

二、动态解析方案

方案一:每次dns有变化,重启Nginx

坑1:会有遗漏通知的情况(我们就遇到了)

坑2:机器太多,麻烦

坑3:耦合性太高,如变更频繁,无法接入,且可能会影响现有应用

方案二:使用Nginx Resolver

声明 resolver 即可,Nginx core模块内置 ,无需新增编译模块。操作简单

// 但我们遇到了惊天“bug”...折腾了1.5天,也没找到原因..

方案三:使用 Nginx-upstream-dynamic-server

方案四:使用 ngx_upstream_jdomain

三、Nginx Resolver 方案测试【BUG】

Nginx Resolver 不需要额外编译Nginx,且配置简单。所以我们第一想法是采用该方案。

  • 原配置
location /prod-url-test/ {
   ...
   proxy_pass http://$proxy_url;
}
  • 添加resolver后的配置
location /prod-url-test/ {
   resolver 4.4.4.4  valid=10s;
   set $proxy_url "prod-url-test.t1.test.example.com";
   proxy_pass http://$proxy_url;
}

但实际测试结果如下:

  1. Dns 变更,nginx 并不能正常解析
  2. 重启 nginx 后,生效。

下面就开始了抓妖怪的曲折道路,因为过程较为曲折,我大致总结为如下几个阶段:

  • 排除粗心手误问题
  • 排除测试方案问题
  • 排除DNS配置问题
  • 排除域名重复配置问题

3.1 排除粗心手误问题

  1. 使用对比工具检查可能的拼写错误
  2. 检查 hosts ,确认域名没有绑定hosts
  3. 确认 Linux, Windows DNS 缓存机制并验证

3.2 排除测试方案问题

  1. 确认方案准确可行,无歧义
  2. 基于Y同学的方案,我全新重头又验证一遍。确认过程无疏忽错误

3.3 排除DNS配置问题

  1. 优化 DNS 默认 TTL 1D,修改为 10S
  2. 确认主从 DNS 同步机制,及 dig , nslookup确认解析生效

3.4 排除域名重复配置问题

确认没有模糊匹配的域名干扰

grep -iE '域名'  /etc/nginx/ -R

一顿操作猛如虎,一看收入250。竟然没定位到问题,有点尴尬..

随后,我增加了如下测试方案:

  • 方案一: 新增域名
lst-dns-test.t1.test.example.com

为最大化模拟问题,域名的长短也保持一致。

为排除现有 DNS 潜在的问题,及技术人员响应不及时的情况。同时我自己又搭建了一套 DNS.

  • 方案二:新增自建 DNS 服务

最终配置如下

location /lst-dns-test/ {
   resolver 6.6.6.6  valid=10s;   # 6.6.6.6 为自建DNS
   set $proxy_url "lst-dns-test.t1.test.example.com";
   proxy_pass http://$proxy_url;
}

经测试,结果如下:

域名

结果

是否符合预期

lst-dns-test.t1.test.example.com

dns修改后,Nginx无需重启,自动生效

完全符合预期

prod-url-test.t1.test.example.com

dns修改后,Nginx不重启不生效,重启后概率生效

不符合预期

至此,严重公司 DNS 服务配置异常。将测试域名 lst-dns-test.t1.test.example.com 在公司DNS做解析,保证所有配置和 prod-url-test.t1.test.example.com 一样后再做测试。结果依旧~~

至此,其实已经不知道怎么办了... 在和晓明沟通后,建议 tcpdumpDNS 解析的数据流是怎么流向的,怀疑 DNS缓存,并做了递归解析。

依旧没有定位到问题,但帮我们了解到 Nginx resolver 的解析数据流:

  • Nginx DNS解析步骤:
  1. 先使用系统dns解析,再使用nginx relover 指定 的dns解析
  2. 后者的dns解析结果覆盖前者

而有问题的域名,压根没有到我自建的DNS上请求解析.... 难怪使用我自建的DNS一直不生效。但不能解释 使用公司的DNS,为什么必须重启才能生效。

traceroute  lst-dns-test.t1.test.example.com
traceroute  prod-url-test.t1.test.example.com

traceroute后,发现2个域名路由不一样,正常的域名只有一跳,不正常的域名要经过两跳。所以,又将终点怀疑到公司网络设备。

请公司网络同学协助后,建议将服务器的 DNS 修改为我自建的 DNS, 保证环境的纯净性。

采用该方案后,发现问题依旧。。。

至此,彻底凉凉,接下来再搞,只能看源码了。

后来突生一计。将 Nginx 所有的配置,全部清除,只保留有问题的的域名 prod-url-test.t1.test.example.com

发现,竟然正常了,即不用重启 Nginx,修改 DNS 后, Nginx 解析自动生效。

再恢复所有的 Nginx 配置后,发现问题重现....

四、排查过程总结及Nginx Resolver注意点

问题还原

prod-url-test.t1.test.example.com
lst-dns-test.t1.test.example.com
test-compare.t1.test.example.com

同时测试如上3个域名,1:1保持配置一样,只有 prod-url-test.t1.test.example.com 不正常。

  • Nginx DNS解析步骤:
  1. 先使用系统dns解析,再使用nginx relover 指定 的dns解
  2. 后者的dns解析结果覆盖前者
  • 技术环境:
  1. nginx resolver 使用自建dnsnginx server系统使用集团dns
  2. nginx resolvernginx server系统 均使用集团dns
  3. nginx resolvernginx server系统 均使用自建dns
  • 测试场景:
  1. 同样配置下,修改域名解析地址,不重启nginxprod-url-test.t1.test.example.com表现的现象均一样)
  2. 同样配置下,修改域名解析地址,重启nginxprod-url-test.t1.test.example.com 有一定比例失效, 其它域名表现正常(3种技术环境表现的现象均一样)
  3. 删除所有nginx配置,只保留 prod-url-test.t1.test.example.com 域名。所有测试均正常。符合要求。还原服务器上所有的nginx配置, 再次回到场景1和2的情况。(3种技术环境表现的现象均一样)
  • (暂)结论:
  1. nginx resolver 存在一定解析失败的概率问题
  2. nginx resolver 在配置较复杂的场景下存在配置失效的问题。
  • 使用Nginx resolver注意点
  1. 使用 resolver 功能,通过 resolver 这种方式来实现nginx动态解析代理域名,相当于放弃了upstream,也就无法使用upstream相关配置功能,比如回话保持、健康检测等等
  2. 针对如下妖怪问题,建议严谨测试后再上线。

好的,不说了。我要去取车为国庆生了。最后祝大家假期愉快,一路不堵!

文章分享自微信公众号:
运维部落

本文参与 腾讯云自媒体分享计划 ,欢迎热爱写作的你一起参与!

作者:松鼠尚堂
原始发表时间:2021-09-30
如有侵权,请联系 cloudcommunity@tencent.com 删除。
登录 后参与评论
0 条评论

相关文章

  • nginx dns解析源码分析

    在使用同步IO的情况下,调用gethostbyname()或者gethostbyname_r()就可以根据域名查询到对应的IP地址,。

    stan1ey
  • 【DNS 解析】使用DNSPOD实现动态公网解析(DDNS)

    注:本文用到的所有代码已开源:https://arsrna.coding.net/public/website-mainsite/ArSrNaDDNS/git/

    Ar-Sr-Na
  • Nginx DNS解析漏洞PoC公开细节

    5月26日,由绿盟科技CERT监测到Nginx发布安全公告,修复了一个Nginx解析器中的DNS解析程序漏洞(CVE-2021-23017),由于ngx_res...

    李俊鹏
  • 通过 Serverless 来动态切换 DNS 解析

    我们业务是做在线直播和视频点播的,在点播这个业务场景上,为了保证客户端的访问性能,我们接入了腾讯云的 CDN 服务。因为是做视频点播的,所以 CDN 服务费用一...

    Mogody
  • 【DNS解析】如何设置DDNS(动态域名解析)

    1、登录OpenWrt,找到系统(System)→软件包(Software),将下方软件包的地址放入从网络安装的输入框中,点击确认(ok)完成安装。 ipk安装...

    Im小泽
  • nginx 的 DNS 缓存

    nginx 配置中有1个upstream配置是指向一个域名Y的,而这个域名Y解析对应IP其实是会动态变化的。

    一个会写诗的程序员
  • Nginx 缓存服务器(番外)动态 upstream

    在更新应用镜像(图中的App1)版本后,部分静态资源抛出HTTP 502状态码。先来看下 nginx缓存服务器日志,重点在"Host is unreachabl...

    用户1560186
  • Nginx域名解析流程,源码分析

    nginx在做正向代理、反向代理的时候,或upstream使用域名的时候,要做频繁的域名解析,为了更快的响应,nginx有一套自己的域名解析过程

    李俊鹏
  • 如何使用Nginx实现CDSW的跨网段访问

    在企业安装了CDSW后,由于服务安装在生产网络,考虑到集群的安全企业不允许将生产环境的网络直接放通给办公网或外网访问,如果需要在办公网或是外网访问则需要通过反向...

    Fayson
  • CVE-2021-23017:nginx DNS解析漏洞PoC公开

    https://mailman.nginx.org/pipermail/nginx-announce/2021/000300.html

    FB客服
  • 移动环境下DNS解析失败后的优化方案

    我们手机游戏中,通过上报收集到的数据来分析,发现相当多的一部分用户,在请求一些配置时会遇到无法解析的情况,或者域名的解析直接被拦截了。

    meteoric
  • nginx配置根据参数转发

    需求: 因浏览器安全策略,在reference为https类型时,无法跳转获取http协议链接的数据。 因此,设计解决方案为:由程序将需要跳转的完整url作...

    吟风者
  • Linux学习之DNS+DHCP动态域名解析

    DNS用来做主机名和IP地址的解析 DHCP用来动态分配IP 这里要做的是,使DHCP在分配IP时,动态更新DNS的解析记录 服务器IP:192.1...

    星哥玩云
  • Nginx之OCSP stapling配置

    Fundebug
  • 高并发架构的CDN知识介绍

    对一次网络请求过程的了解程度,一是展现你的专业知识;二是深刻的理解,让你在大型网站架构中做出更适合、可靠的架构。而DNS是这一切的出发点,本文结合一张常用架构图...

    大愚
  • Nginx开启OCSP以解决Let's Encrypt证书被DNS污染访问缓慢

    最近突然发现我的网站在苹果手机上Safari浏览器上第一次会访问会非常慢,但只要第一次访问后,后续的访问速度均不受影响...这就纳闷了,网站速度我都是优化过的,...

    ICU
  • nginx实现负载均衡

    upstream将创建一个上游服务配置项,用于交给proxy_pass 转发ip.

    仙士可
  • 【DNS 解析】Nginx+SSL+DNS解析+腾讯云服务器,免费给自己的个人网站开启HTTPS防护

    之前给大家介绍了如何通过DNS解析把自己的域名绑定到腾讯云服务器上,在使用的过程中我发现了一个问题:

    程序员晚枫
  • 应对运营商网络故障高可用架构设计

    腾讯云上部分客户,基于腾讯云云产品能力,在同地域不同可用区,快速构建了业务级别的同城双活架构(如下图)。具备了单产品/单链路的高可用能力,同时也具备同城单可用区...

    用户3971906

扫码关注腾讯云开发者

领取腾讯云代金券