关于DNS的不完全总结

关于DNS的不完全总结

几年前第一次接触到活动目录的时候,正是领导要求部署活动目录的时候。虽然当时手头上有几本书,但是时间紧迫没有来得及仔细研究。边看着帮助边运行dcpromo就开始活动目录的部署了,相信不少人和我当年差不多,稀里糊涂的就开始当起了活动目录的管理员。对于DNS,因为安装会提示自动部署,相信很多人都不会在这方面下很多功夫(包括我原来也是)。我为此付出了不少代价--因为不懂DNS所以遇到DNS的问题不知如何解决。我有保存论坛上感兴趣帖子的习惯(显然直接另存是保存不下来的),我保存有关DNS问题的帖子数量,占各种问题的第三位(我也很吃惊)。

但是论坛上也没有很系统的关于DNS的总结(这毕竟是一个可以写成一本书的很大的方面)。我通过对自己收藏的帖子和参考书的阅读,加上自己经验的总结得出一些操作方面的结论和总结。希望对大家能有所帮助,因为我不擅长DNS(在论坛上我也很少给朋友解决DNS问题),所以我想肯定有我写错的地方,我希望斑竹们能帮忙校正(我脸皮厚)。我的真正目的是通过这篇文章认识到我在DNS方面都存在哪些误解(我还是挺有私心的)。

闲话少说,书归正传。

有过DNS域部署经验的朋友都能感觉到,活动目录的DNS、DHCP和WINS(用的不多了)和NetBios是息息相关的。也是很容易混淆的。所以很麻烦,通常我们开始部署AD的时候是在一个小公司里,大约有几十台电脑的局域网。人员流动不是很频繁,所以的电脑也差不多的天天都开。很少有电脑会换地方,我们全都使用DNS的默认配置就可以很少会出问题。但这样的地方我们不能待一辈子,我们来到一个相对复杂的网络环境时,意识到自己缺乏对DNS的起码常识,怎么办?  为了在遇到难题时能正确表述自己的问题(否则别人想帮你都没办法,除了UP我们更重要的是说清楚自己的问题和听明白高手的意思)那么和我一样从基础开始吧。

什么样的DNS系统是一个比较完美的系统呢?DNS服务器的连续性能提供出色的性能,减少WAN的通信,安全性也必须得到保障。

我们先从概念开始

1。DNS和活动目录关系

论坛早期有一个帖子说得非常好,喜欢钻研的朋友可以看看
http://www.winmag.com.cn/forum/itemdisplay.asp?boardid=10&id=143613
如果不喜欢专业性的词汇,可以看一下我的概括介绍。

DNS定义“命名空间”(名字空间)---微软把例如“contoso.com”的东东叫命名空间,这个空间内的主机储存在一个“区域文件”(zone file)里---主要是一种映射的关系(中学数学就有映射的概念)

活动目录的域(domain)“存储域和域中的对象”,把用户、租计算机帐户记录组注册表的SAM里。---当然域不止这些内容。

DNS和域的结合--完全合格域名(FQDN):例如srv1.contoso.com--说明了srv1主机位于contoso.com这个域里面。

注意:
DNS的结构中,顶级域com.的末尾是有一个句点"."的。DNS解析器是从左到右解析FDQN(看看上面FDQN的例子)的,最后到“.”结束。因为windows的DNS会自动在末尾添加“.”所以我们很容易忘了它的存在,在我们检测DNS(尤其是命令行方式)最好加上末尾的这个"."正因为根域上有这个点,所以我们在林根的DNS上设置转发的时候会发现那个转发器的选现是灰的,不让你设置,因为"."认为自己是根了,没必要转发。所以解决的方法是删掉这个点,才能转发(删掉后就不会灰色可以选择转发了)。

如果没有行政方面的要求你完全可以在域里使用例如devil.coco的域名称,不一定非要.net或者.com.即使父域叫contoso.com,子域也可以叫devil.coco。

当一个企业在做DNS规划时要注意。当企业外部服务(例如网站)需要在internet上注册名称(例如,公司.com)。如果企业内部使用活动目录,那么要使内外部使用不同的名字或者内部的活动目录使用外部名称的一个子域。例如:“contoso.com”,作为企业在internet上的网站,使用www.contoso.com域名。内部的域可以使用contoso.net或者corp.contoso.com作为DNS名。如果不这么做将有可能使内部和外部名称空间出现重叠。客户端登陆域或访问internet都将可能产生问题。尤其当涉及网络地址转换 (NAT) 并且外部 IP 地址处于内部客户端够不到的范围中时就会有麻烦了(了解NAT 的 人应该知道,如果客户端不配置可以正确解析外部地址的DNS是无法访问相关网站的.)。

DNS和活动目录使用各自不同的数据库解析名字。关于这一点我觉得对于实际操作意义不大所以不说了有兴趣的看看上面提到的那个帖子。


2。hosts文件
很多帖子里都有人回复说,看看那个hosts文件有没有问题,或者说修改那个hosts文件里的什么地方(例如屏蔽QQ)

。这是为什么?

hosts存在的目的:减少DNS服务器的工作量,如果客户端查找的一个主机名在hosts文件里有记录(说明不久前访问过),那么客户端就不必找DNS服务器了直接就知道了该主机的IP。我们可以用记事本打开hosts文件。找不到?一般在这里C:/WINDOWS/system32/drivers/etc 这里除了hosts还有好几个文件,也能用记事本打开。都是和TCP/IP相关的,详细我就不说了跟DNS关系不大。

TTL(生存时间),DNS记录必须有TTL,Hosts中得缓存超过了ttl就将被删除,否则DNS得改变将无法在hosts文件中体现。

我们需要一个具体的例子:
有天,客户发现srv1.contoso.com主机无法访问了,我们查看DNS表,发现确实没有相关A记录了。我们手动添加了记录,但是客户还是抱怨无法访问该主机――因为客户端的缓存里里,还是认为该主机无法访问。这时我们就必须在客户的电脑上运行
ipconfig/ flushdns 来清除缓存信息
是的,服务器也有缓存。服务器清理缓存的命令是dnscmd /clearcache

3.主DNS服务器和辅助名称服务器
这个概念在论坛上也无数次的被提起,我觉得还是有必要说明一下的。照例我不会用很专业的词汇,需要考MCSE的朋友最好不要看我写的东西。
我是这样认为的,DNS服务器把所有资源记录到一个文件中(zone file)。只有“主DNS服务器”能对该文件进行写操作(能修改DNS记录),辅助DNS服务器从主DNS服务器(或者其他辅助DNS服务器)那里获得该文件的拷贝(默认24小时得不到拷贝的话,辅助DNS服务器就将失效)。
除此之外还有一种“仅缓存名称服务器”(caching-only name server),它上面仅保存缓存的查询结果(从辅助DNS服务器那里获得),以便使客户端尽快获得查询信息。

这种机制让人想起NT时代的主域控制器和备份域控制器――当然这是一种脆弱的机制。微软为了能多凑合一些时间,允许任何运行DNS的DC都能被设置为它所在域的主DNS服务器。

4.权威性应答与非权威性应答
按照我的理解,如果DNS服务器在自己的区域文件里找到了客户端需要查询的记录,就会返回一个权威性应答。―――例如客户端要查找srv1. contoso.com主机的IP地址。在contoso.com的DC(也就是DNS服务器)上查找该主机的“A记录”,我们找到了。就把记录内容通过DNS应答的方式发还给客户端,这就是一个权威性应答。――当然实际的查询方式比较复杂远没有我说的这么简单。
此外,如果DNS服务器最近被查找过该主机(可能其他客户端也查找过)记录,就会在缓存里找到记录应答客户端――当然上一种方法快。
如果该DC服务器找不到srv1. contoso.com主机的A记录,就会返回(Record Not Found)应答――同样也是权威性应答

如果接到DNS查询请求的服务器不是contoso.com的DC(Dns服务器),那么有3种方法处理该请求:
首先,查询其他DNS服务器直到找到,然后此服务器将找到的内容返回给客户端――非权威性应答
其次,推荐客户端到上一级DNS服务器找。―――非权威性应答。
最后,如果原来被别人访问过,本地有该缓存,那么用缓存里的数据回答―――非权威性应答。
说到这里就要讲清楚,为什么会出现3种方法,为什么有的时候DNS服务器要努力帮客户端查寻有的时候又只是打发到上层就不管了?
因为在客户端查询的请求里面包含一个“搜索类型”(Search type)的东东,一共有两种状态:
1. 递归查询(Recursive),要求DNS服务器一定要救人救到底送佛送上西。反正我就赖上你了,你得给我查到。
2. 迭代查询(Iterative),你(DNS服务器)如果找不到可以给我介绍到另一个DNS服务器那里去找――这种方式的客户端就文明多了――自然DNS服务器的压力就减轻了。
默认情况是递归查询的,我们可以在DNS服务器参数配置禁用(高级选项)。
当DNS服务器被客户端要求递归查询而去查询其他DNS服务器时,默认是迭代查询的。

5.Netbios解析和DNS解析
对于两者的概念我不想多做说明了,值得注意得是他们的查询步骤。
假定我们启用了Netbios解析,windows客户端会按照下面的步骤进行解析(默认B节点配置可以修改为H节点)
(1) Netbios缓存
(2) Wins查询
(3) Lmhosts文件(看看hosts的目录)
(4) 广播
(5) hosts文件
(6) DNS

我们举个例子,如果我们在客户端ping一下srv1.contoso.com主机。我们通常的做法是运行cmd。输入ping srv1 回车。这时发生了什么?
首先,客户端会把计算机的DNS后缀附在名称上发送到DNS服务器。
如果名字里有“.”存在,但是末尾并没有“.”结束,系统会自动追加末尾“.”,如果这样查询也失败了,就会向上面那样追加DNS后缀再试。
如果添加DNS后缀也无法获得主机记录,那么系统就会追加事先为“接口”配置好得备用DNS后缀(仔细看看本地连接的属性)。
不明白为什么要选择“在域成员身份变化时,更改主DNS后缀”的朋友,和经常问“为啥我ping完整的名字才能ping通”的朋友有必要仔细研究一下。

我觉得有关DNS的问题范围太大,短时间很难总结完。今天累了,下次继续总结。有问题可以问,我说错了的赶快指出来。明天还要上班接下来只能业余时间来补充了,争取一周时间完成DNS的总结,自己也全当复习了,也希望能帮到昨天说“这也算是回答”的朋友。
 
<think>我们正在处理用户关于在配置DNS的情况下安装或运行SAP系统的问题。用户已经提供了部分日志和引用,但我们需要聚焦于DNS配置缺失的影响和解决方案。根据之前的日志分析,DNS配置缺失会导致sapinst安装程序在早期阶段就失败(无法获取DNS域名)。但用户现在想了解配置DNS的后果以及可能的应对措施。关键点:1.安装阶段:sapinst需要FQDN(完全限定域名)来配置SAP系统的各个组件。如果无法解析,安装会失败(如日志所示)。2.运行阶段:即使安装完成,DNS配置缺失也会导致SAP系统内部通信问题(因为SAP系统组件之间使用主机名通信)。配置DNS可能产生的问题:a)安装失败:如日志所示,sapinst在开始阶段就会报错并终止。b)组件通信失败:SAP系统由多个组件(ASCS,PAS,AAS,数据库等)组成,这些组件通过主机名进行通信。如果无法解析主机名,组件无法启动或通信。c)系统管理问题:SAP管理工具(如SAPMMC)和操作系统管理工具(如hosts文件)维护困难,特别是在集群环境中。应对措施(在配置DNS的情况下):1.使用/etc/hosts文件进行本地解析(适用于小型系统或测试环境):在每台服务器的/etc/hosts文件中添加所有相关主机名和IP地址的映射(包括FQDN和短主机名)。例如:192.168.1.100s4hana-app.example.coms4hana-app192.168.1.101s4hana-db.example.coms4hana-db2.注意:SAP系统要求每个节点都必须能够解析所有其他节点的主机名(包括FQDN和短主机名),并且反向解析也必须正确。3.在安装过程中,即使没有DNS服务器,只要通过hosts文件提供了正确的解析,安装程序就可以继续。4.运行阶段:同样依赖hosts文件。但要注意,在集群环境中(如高可用性设置),所有节点必须有一致的hosts文件。5.限制:hosts文件维护麻烦,适合大规模系统或动态环境。生产环境强烈建议使用DNS。步骤示例(使用hosts文件安装SAP):a)在所有参与安装的服务器上配置/etc/hosts,包含所有SAP系统相关主机(包括虚拟主机名,如ASCS的虚拟主机名)。b)验证:使用`ping`和`nslookup`检查每个主机名(FQDN和短主机名)都能解析,并且反向解析(通过IP解析到FQDN)也要正确。c)然后重新运行sapinst。注意:反向解析同样重要。例如,SAP系统在生成证书时可能需要反向解析。可以通过在/etc/hosts中同时添加正向和反向记录(但通常hosts文件支持反向记录),因此需要确保通过hosts文件解析时,`getenthosts<IP>`返回正确的主机名。或者,在hosts文件中,对于每个IP地址,将其映射到FQDN和短主机名,这样正向解析没问题,但反向解析需要单独配置(在hosts文件中无法直接配置反向解析)。所以,对于反向解析,如果使用hosts文件,则只能通过设置每个IP地址对应的主机名条目来间接实现,但有些工具(如nslookup)可能会查询hosts文件的反向解析。因此,在测试环境中,可以忽略严格的反向解析要求,但生产环境建议。替代方案:搭建本地DNS服务器(如dnsmasq)以提供内部解析。引用说明:用户提供的引用[1]是安装指南,其中会要求主机名配置。引用[2]是关于OracleASM的错误,与DNS无关,因此我们考虑。因此,总结回答如下:</think>### SAP系统在配置DNS环境下的运行问题与解决方案 #### 一、配置DNS可能引发的问题 1. **安装阶段故障** - **主机名解析失败** SAP安装程序(`sapinst`)要求主机名必须解析为FQDN(完全限定域名)[^1]。如日志所示: ```log WARNING: Unable to determine parameter "DNS domain name" Problem with the DNS configuration: could not determine DNS domain ``` 这将导致安装程序在预处理阶段自动终止。 2. **集群通信中断** - **ASCS/PAS节点发现失败** SAP高可用架构依赖DNS实现服务发现: ```mermaid graph LR A[ASCS] -->|需要解析| B[PAS] B -->|需要解析| C[Database] C -->|需要解析| D[AAS] ``` 未配置DNS时,节点间无法建立TCP连接,引发`SAPCONNECT`错误[^1]。 3. **证书验证异常** - **SSL/TLS握手失败** SAP系统内部通信使用SSL证书,证书验证要求: $$ \text{证书CN} \equiv \text{FQDN} $$ 未配置DNS会导致证书校验失败,产生`SSL_HANDSHAKE_ERROR`。 4. **系统管理障碍** - **ST06监控失效**:操作系统监控无法获取完整主机信息 - **SAProuter连接问题**:远程维护连接需要反向DNS解析 - **传输管理系统(CTS)错误**:系统复制时域名匹配 #### 二、依赖DNS的解决方案 1. **使用Hosts文件替代(推荐测试环境)** ```bash # 在/etc/hosts添加所有节点映射 192.168.1.10 s4hana-app.example.com s4hana-app 192.168.1.20 s4hana-db.example.com s4hana-db 192.168.1.30 s4hana-ascs.example.com s4hana-ascs ``` **注意**:需在所有服务器同步此文件,包括: - 应用服务器 - 数据库服务器 - 共享存储服务器 2. **安装参数强制覆盖** 启动`sapinst`时添加参数: ```bash ./sapinst SAPINST_USE_HOSTNAME=<短主机名> ``` 例如: ```bash ./sapinst SAPINST_USE_HOSTNAME=s4hana-app ``` 3. **内核参数调整(运行阶段修复)** 修改`/etc/sysconfig/sapconf`: ```ini # 禁用FQDN检查 SAP_FQDN_CHECK=no # 设置默认域名后缀 SAP_DEFAULT_DOMAIN=example.com ``` 4. **ABAP程序级修复** 对于已安装系统,在ABAP层修正: ```abap SYSTEM->SET_CUSTOM_PARAMETER NAME = 'service/hostname_resolution' VALUE = 'local'. ``` #### 三、各场景适用方案 | **场景** | **推荐方案** | **风险等级** | |----------------|------------------------------|-------------| | 单机测试环境 | Hosts文件 + SAPINST_USE_HOSTNAME | 低 | | 开发系统 | 内核参数调整 | 中 | | 生产集群 | 必须配置DNS | 高 | > **关键限制**:SAP Fiori和Cloud Connector组件严格依赖DNS,无法通过hosts文件替代[^1]。高可用集群(HA/DR)必须配置DNS反向解析记录。 #### 四、验证方法 1. **安装前检查** ```bash saproot.sh checkDNS -h s4hana-app # 输出应为:FQDN=s4hana-app.example.com ``` 2. **运行期诊断** ```bash sapcontrol -nr 00 -function GetProcessList # 检查进程状态,出现OFFLINE表示通信故障 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值