服务器自动获取DNS地址改为手动DNS设置,核心操作是在网卡配置中关闭DHCP的DNS自动分配选项,填入固定的首选和备用DNS服务器地址,Windows Server和Linux系统的具体步骤有所不同。
很多站长或运维新手都会遇到这样一个场景:服务器的网络连接正常,但域名解析总是不稳定,偶尔出现网站打不开的情况,排查到最后,往往发现是自动获取的DNS地址拖了后腿,运营商的公共DNS在高峰时段响应变慢,或者分配的DNS服务器经常变动,导致解析异常,把DNS改为手动指定,是提升服务器解析速度和稳定性的基础操作。
改手动DNS前的准备工作
开始动手之前,先把需要用到的东西准备好,你需要记下当前网络环境下的几个关键参数,尤其是IP地址、子网掩码、默认网关,如果服务器是托管机房里的物理机,这些信息在服务器交付资料里能找到;如果是云服务器,登录云厂商的控制台就能看到,改DNS不涉及IP地址变更,但如果不小心改错了其他地方,可以按照这些参数快速恢复。
首先通过Windows的“运行”框或Linux的终端窗口,输入命令查看当前网络配置,Windows Server系统打开命令提示符,输入ipconfig /all,可以看到当前网卡的IPv4地址、子网掩码、默认网关以及当前正在使用的DNS服务器地址,Linux系统则输入cat /etc/resolv.conf,可以看到当前使用的DNS配置,这些信息记录下来备用。
服务器dns设置修改方法:Windows Server系统操作
Windows Server在服务器操作系统里占了相当大的比重,多数企业级应用都跑在Windows Server上,整个修改过程都在图形界面里完成,步骤很直观。
进入控制面板,找到“网络和共享中心”,点击左侧的“更改适配器设置”,这里会列出服务器上的所有网卡,找到正在使用的那个,右键点击,选择“属性”。
弹出窗口中,找到“Internet 协议版本 4 (TCP/IPv4)”,双击打开属性页面,在这个界面里能看到两种获取DNS的选项:自动获取和手动指定,当前状态应该是“自动获得DNS服务器地址”,现在要把它切换掉。
勾选“使用下面的 DNS 服务器地址”,然后在“首选 DNS 服务器”一栏填入公共DNS地址,比如5.5.5(阿里DNS)或29.29.29(腾讯DNSPod),备用服务器一栏填入8.8.8(谷歌DNS)或114.114.114(114DNS),填完之后一路点击“确定”,设置就生效了。
修改完了别急着关窗口,打开命令提示符,输入ipconfig /all确认一下DNS地址是否已经变成你填写的值,如果没变,试试运行ipconfig /flushdns清除系统DNS缓存,再执行ipconfig /renew重新获取网络配置。
如果服务器有多块网卡,比如一台服务器接了内网和外网两个网段,每块网卡都需要单独设置DNS,内网环境的DNS服务器通常由机房或公司内部提供,外网网卡则用公共DNS,场景不同,选择的DNS也不一样。
设置dns服务器地址:Linux服务器的操作路径
Linux服务器没有图形界面,一切操作都在终端里完成,不同的发行版,配置方式略有差异。
基于Red Hat系的操作方式
CentOS、Rocky Linux、AlmaLinux这些系统,网络配置最早是通过直接修改网卡配置文件来进行的,网卡配置文件存放在/etc/sysconfig/network-scripts/目录下,文件名一般为ifcfg-eth0或ifcfg-ens33,具体文件名可以通过ip addr命令查看。
用vim或nano编辑器打开这个文件,找到BOOTPROTO这一项,把它从dhcp改成static,如果没有这一项,就手动添加,接着在文件末尾追加两行:
DNS1=223.5.5.5
DNS2=119.29.29.29
保存退出后,重启网络服务让配置生效,CentOS 7及以下版本执行systemctl restart network,CentOS 8及以上版本执行nmcli c reload,或者在NetworkManager管理界面里重新加载连接。
基于Debian系的操作方式
Ubuntu和Debian的DNS配置方式经历了变化,旧版本的Ubuntu同样修改/etc/network/interfaces文件,在网卡配置段落里添加:
dns-nameservers 223.5.5.5 119.29.29.29
新版Ubuntu(18.04及以上)默认使用netplan作为网络配置工具,配置文件在/etc/netplan/目录下,文件名一般为01-netcfg.yaml或50-cloud-init.yaml,用编辑器打开,在网卡的dhcp4参数下方增加:
nameservers:
addresses: [223.5.5.5, 119.29.29.29]
保存之后执行netplan apply使配置生效。
如果服务器安装了桌面环境或使用了NetworkManager工具,还可以用nmtui这个文本图形界面来操作,执行nmtui命令,进入“编辑连接”,选择网卡,在“IPv4配置”里把自动改为手动,在DNS服务器栏填入地址,退出保存即可。
Linux系统的配置比较碎片化,不同版本、不同发行版之间的差异很容易踩坑,操作前先确认一下系统版本和网络管理方式,可以少走弯路。
Windows和Linux修改DNS后的生效方式对比
修改完DNS之后,马上测试能否正常解析域名,Windows系统执行ping www.baidu.com,Linux系统执行dig baidu.com或nslookup baidu.com,能正常返回IP地址,说明DNS配置已经生效,如果解析失败,优先检查已填写的DNS地址能否通过ping连通。
两种系统的生效机制有所区别:
| 系统类型 | 修改工具 | DNS缓存清理命令 | 服务重启命令 |
|---|---|---|---|
| Windows Server | 图形界面 | ipconfig /flushdns |
不需重启网卡 |
| Linux(Red Hat系) | 编辑配置文件 | systemd-resolve --flush-caches |
systemctl restart network |
| Linux(Debian系) | netplan YAML文件 | systemd-resolve --flush-caches |
netplan apply |
如果服务器搭建了DNS缓存服务,比如Windows Server的DNS角色或Linux下的dnsmasq、unbound,修改完系统DNS之后,还需要重启这些缓存服务,否则服务器自身解析很快,但对外提供的解析结果仍然沿用旧的DNS配置。
dns设置手动好还是自动获取好:不同场景下的选择逻辑
新手容易把DNS理解为网络参数里不值一提的陪衬项,实际上DNS的选择直接影响服务器对外服务的响应速度,自动获取的DNS来自DHCP服务器分配,通常是机房网络或云平台默认提供的,对于不需要精确控制解析行为的场景,自动获取省事,不用额外管理,但当遇到以下情况时,手动设置的优势就体现出来了:
- 服务器日均解析请求量较大,自动获取的DNS存在响应慢或者不定时抽风的情况
- 服务器托管在跨地域的机房,自动获取的DNS往往是当地的运营商DNS,解析精度有限
- 需要接入CDN服务,CDN厂商通常建议使用特定DNS以获取最佳调度节点
- 用到了云平台的私有域名解析服务,必须手动指定才能生效
国内公共DNS的响应速度差距不大,教育网和某些专网环境有专门的DNS解析服务器,公共DNS反而不可用,这种情况务必手动指定成网内提供的DNS地址。
常见的权威公共DNS地址如下:
- 阿里DNS:5.5.5 / 6.6.6
- 腾讯DNSPod:29.29.29
- 百度DNS:76.76.76
- 114DNS:114.114.114
- 谷歌DNS:8.8.8 / 8.4.4
公共DNS的选取尽量选择国内的,解析速度和抗污染能力都有保障,谷歌DNS在国内环境下解析部分域名会受阻,建议优先使用国内服务商。
linux服务器dns配置修改后无法上网排查思路
改完DNS发现网站还是打不开,或者服务器无法上网,这种问题在实操中很常见,排查的路径从链路层到应用层逐级验证。
检查网卡是否成功获取到IP地址,如果Linux配置文件里BOOTPROTO改成了none或static,但没有手动分配IP参数,网卡会因为没有地址而无法通信,Windows系统如果误操作把“自动获得IP地址”也勾没了,同样会导致断网,先确认IP地址还在,再往下排查。
确认IP正常但解析仍然失败,尝试直接通过IP地址访问外网资源,执行ping 223.5.5.5,如果能返回数据说明物理链路没有问题,问题出在DNS解析环节,执行cat /etc/resolv.conf,查看系统当前读取到的DNS配置,Linux系统存在多个配置文件互相覆盖的问题,/etc/resolv.conf经常被NetworkManager或dhclient重写,即使手动修改过,重启系统后也可能被重置回自动获取的地址。
Ubuntu系统还存在systemd-resolved与netplan配置冲突的情况,导致/etc/resolv.conf被软链到systemd的目录下,业内专家指出,这类环境可以先通过systemctl disable systemd-resolved关闭系统自带解析服务,再重新配置DNS。
防火墙策略也有拦截DNS请求的情况,DNS走UDP和TCP的53端口,如果系统防火墙或安全组规则没有放行这个端口,外部DNS服务器即使可达,也无法完成解析请求,Linux系统检查firewall-cmd --list-all或iptables -L -n,Windows系统检查防火墙高级设置里的入站规则。
dns设置改成手动后常见问题解答
问:服务器改完手动DNS之后,域名解析一直失败,但是Ping公共DNS的IP又是通的是为什么?
答:Ping通说明网络连路正常,问题出在DNS协议交互上,先以nslookup指定UDP53端口测试指定服务器解析,再用telnet DNS服务器IP 53测试TCP端口连通性,如果UDP无法解析而TCP正常,大概率是网络设备或防火墙对UDP DNS流量做了策略限制,另外注意检查服务器系统时间,NTP时间偏差过大时,使用DNSSEC的解析请求会被直接丢弃,这个原因比较隐蔽。
问:Windows Server改完DNS之后重启,DNS地址又变回自动获取了是什么原因?
答:检查IP地址获取方式是否同时被修改成了自动获取,Windows拨号网络或无线网卡会周期性检测网络变化并触发DHCP更新,把DNS地址重新覆盖,需要确认当前使用的是以太网适配器,且适配器属性里IPv4的设置中,两个选项都被正确修改,云服务器需要检查控制台的网卡配置里是否开启了DHCP的自动配置功能,有些云厂商的网络配置在系统重启后会用元数据服务强制覆盖系统内的DNS设置。
问:手动设置DNS和自动获取,哪种方式对于服务器更安全?
答:手动设置的可控性更高,自动获取的DNS来自DHCP服务器,理论上存在被恶意DHCP劫持的风险,服务器在不可信的局域网环境里,这是相当一部分企业内网存在的安全隐患,手动指定公共DNS或自建DNS,能规避ARP欺骗和DHCP劫持所带来的DNS污染问题,前提是DNS服务器本身足够可靠,通过dig +trace检查解析链路的完整性可以验证,自建DNS需要更专业的维护,出现解析故障时影响全部业务,稳妥的做法是设置两个不同线路的DNS做冗余。