我们在购买了域名,进行网站备案以后,差不多就要开始准备域名的解析工作了。
国内外的域名解析服务商所提供的解析服务,基本上没有太大的差别。差别最大的唯一一点,可能就是国内的域名解析服务商所提供的域名解析记录类型可能比较少,都是些基本常用的,而国外的域名解析服务商则可能会全面一些。至于技术实力上的差异,作者本人不做过多评价。平均实力上,国外优于国内;但特定方面的实力,可能国内的一些服务商的技术实力更强,解决方案更适合国人。
下面我将分别用一家国内域名解析服务商——CloudXNS(官网地址为https://www.cloudxns.net/)与国外域名解析服务商——Hurricane Electric(官网地址为https://dns.he.net/),来做域名解析方面的演示。
在正式进行域名解析以前,我们必须注册相关域名解析服务商的帐号,并在域名注册商处把域名的NS服务器更换成相关域名解析服务商的NS服务器,并完成相关域名的添加。
9.1 NS记录
1.什么情况下会用到 NS 记录?
如果需要把子域名交给其他
DNS 服务商解析,就需要添加 NS 记录。
2.记录的添加方式,如图9-1和图9-2所示。
图9-1 在CloudXNS域名管理后台添加NS记录
图9-2 在HE域名管理后台添加NS记录
记录类型:选择“NS”(不用选择,点击New NS即可)。
主机记录:填写子域名,比如需要将www.ipc.im的解析授权给其他DNS服务器,只需要在主机记录处填写“www”即可,主机记录“@”即空记录不能做NS记录,授权出去的子域名不会影响其他子域名的正常解析(在Name下的空格填写“www”即可)。
线路类型:选择“全网默认”即可,否则会导致部分用户无法正常解析(国外域名解析服务商无此选择项)。
记录值:填写要授权的DNS服务器域名,记录生成后会自动在域名后面补一个“.”,这是正常现象(在Nameserver name下的空格填写要授权的DNS服务器域名即可)。
TTL:一般不需要填写,添加时系统会自动生成,各家服务商的默认值各不相同。TTL为域名解析记录的存活时间,数值越小,修改记录后各地生效时间越快(在“TTL (Time to live)”下选择一个你喜欢的数值,一般数值在600至3600即可)。
此记录类型下无法自主定义优先级。以上步骤完成以后,选择保存(Submit)提交即可。
在命令行下可以使用nslookup -qt=ns www.yourdomain.com来查看。在添加完NS记录后,可在命令行下使用ipconfig
/flushdns来刷新本地DNS缓存。
9.2 A记录/AAAA记录
1.什么情况下会用到A记录/AAAA记录?
如果需要将域名指向一个IPv4/IPv6地址,就需要添加A记录/AAAA记录。
2. A记录/AAAA记录的添加方式,如图9-3、图9-4、图9-5和图9-6所示。
图9-3 在CloudXNS域名管理后台添加A记录
图9-4
在CloudXNS域名管理后台添加AAAA记录
图9-5 在HE域名管理后台添加A记录
图9-6 在HE域名管理后台添加AAAA记录
记录类型:根据IP地址类型选择“A”或者“AAAA”,大多数情况下一般选择“A”(不用选择,点击New A或者New AAAA即可)。
主机记录:填写子域名,比如需要添加www.ipc.im的解析,只需要在主机记录处填写“www”即可;如果只是想添加ipc.im的解析,主机记录直接留空,系统会自动填一个“@”到输入框内(在Name下的空格填写“www”或者留空即可)。
线路类型:选择“全网默认”即可,否则会导致部分用户无法正常解析(国外域名解析服务商无此选择项)。
记录值:IPv4/IPv6地址,这里手动填写我们要指向的公网IP地址即可(在IPv4/IPv6 Address下的空格填写要指向的IPv4/IPv6地址即可)。
TTL:一般不需要填写,添加时系统会自动生成,各家服务商的默认值各不相同。TTL为域名解析记录的存活时间,数值越小,修改记录后各地生效时间越快(在“TTL (Time to live)”下选择一个你喜欢的数值,一般数值在600至3600即可)。
此记录类型下无法自主定义优先级。国外服务商的选择里有一个“Enable entry for dynamic dns”的选项,根据个人需要勾选,一般不需要勾选此选项。以上步骤完成以后,选择保存(Submit)提交即可。
国内域名解析服务商——CloudXNS,还有一个自己研究的AX记录,此记录可以调整优先级,当优先级为100%时,与A记录效果相同。与A记录不同的是,此记录可以添加多个主机记录相同的A记录,只需按照需要调节优先级即可;而A记录一般情况下只能添加一个。
在命令行下可以通过nslookup -qt=a www.yourdomain.com来查看A记录,可以使用nslookup
-qt=aaaa www.yourdomain.com来查看AAAA记录。
9.3 CNAME记录
1.什么情况下会用到CNAME记录?
如果需要将域名指向另一个域名,再由另一个域名提供IP地址,就需要添加CNAME记录。最常用到CNAME解析的情况如使用CDN。
2.CNAME记录的添加方式,如图9-7和图9-8所示。
图9-7 在CloudXNS域名管理后台添加CNAME记录
图9-8 在HE域名管理后台添加CNAME记录
记录类型:选择“CNAME”(不用选择,点击New CNAME即可)。
主机记录:填写子域名,比如需要添加www.ipc.im的解析,只需要在主机记录处填写“www”即可;如果只是想添加ipc.im的解析,主机记录直接留空,系统会自动填一个“@”到输入框内,@的CNAME记录会影响到MX记录的正常解析,添加时慎重考虑(在Name下的空格填写“www”或者留空即可)。
线路类型:选择“全网默认”即可,否则会导致部分用户无法正常解析(国外域名解析服务商无此选择项)。
记录值:CNAME记录指向的域名,只可以填写域名,记录生成后会自动在域名后面补一个“.”,这是正常现象(在Hostname下的空格填写CNAME记录指向的域名即可)。
TTL:一般不需要填写,添加时系统会自动生成,各家服务商的默认值各不相同。TTL为域名解析记录的存活时间,数值越小,修改记录后各地生效时间越快(在“TTL
(Time to live)”下选择一个你喜欢的数值,一般数值在600至3600即可)。
此记录类型下无法自主定义优先级。以上步骤完成以后,选择保存(Submit)提交即可。
国内域名解析服务商——CloudXNS,还有一个自己研究的CNAMEX记录,此记录可以调整优先级,当优先级为100%时,与CNAME记录效果相同。与CNAME记录不同的是,此记录可以添加多个主机记录相同的CNAME记录,只需按照需要调整优先级即可;而CNAME记录只能添加一个。
在命令行下可以使用nslookup -qt=cname www.yourdomain.com来查看CNAME记录。
9.4 MX记录
1.什么情况下会用到MX记录?
如果需要设置邮箱,让邮箱能收到邮件,就需要添加MX记录。
2.MX记录的添加方式,如图9-9和图9-10所示。
图9-9 在CloudXNS域名管理后台添加MX记录
图9-10 在HE域名管理后台添加MX记录
记录类型:选择“MX”(不用选择,点击New MX即可)。
主机记录:填写子域名,一般情况下是要做xxx@ipc.im的邮箱,所以主机记录一般是留空的;如果主机记录填“mail”,邮箱地址会变为xxx@mail.ipc.im(在Name下的空格填写“mail”或者留空即可)。
线路类型:选择“全网默认”,为必选项,否则会导致部分用户无法正常解析,邮件无法收取;MX一般不需要做智能解析,直接默认即可(国外域名解析服务商无此选择项)。
记录值:可以是域名,也可以是一个IP地址。如果是域名的话,指向的域名必须要有A记录,如mail.ipc.im,记录生成后会自动在域名后面补一个“.” ,这是正常现象;如果是IP地址的话,直接填写邮件服务器IP地址即可,记录生成后同样会自动补一个“.”(在Hostname下的空格填写CNAME记录指向的域名或者IP地址即可)。
优先级:MX记录优先级的数值越低,优先级别就越高。一般情况下会设置两条MX记录,如一条 MX 设置的为5,另一条为10,则邮件会先尝试发送到MX优先级为5的,如果尝试失败,才会发送到MX优先级为10(在Priority下的空格填写MX记录的优先级数值即可)。
TTL:一般不需要填写,添加时系统会自动生成,各家服务商的默认值各不相同。TTL为域名解析记录的存活时间,数值越小,修改记录后各地生效时间越快(在“TTL
(Time to live)”下选择一个你喜欢的数值,一般数值在600至3600即可)。
以上步骤完成以后,选择保存(Submit)提交即可。
在命令行下可以通过nslookup -qt=mx www.yourdomain.com来查看 MX 记录。
9.5 其他记录
1.TXT记录。TXT记录,一般指为某个主机名或域名设置的说明。 在实际使用过程中,一般做域名归属权验证;或者提升域名邮箱发送外域邮件的成功率,之所以会提升成功率,是因为对方的邮箱会把你的域名加入白名单,以可信邮箱的名义发送邮件,邮箱系统之间不会互相屏蔽的。这种效果我们一般称为“反垃圾邮件”,如果希望对域名进行标识和说明,可以使用TXT记录,绝大多数的TXT记录是用来做SPF记录(反垃圾邮件)。
在命令行下可以使用nslookup -qt=txt www.yourdomain.com来查看TXT记录。
2.显性URL记录和隐性URL记录。说的通俗点,就是域名转发。显性和隐性的区别,就在于转发的目标URL,是否跟当前域名的URL一致。显性的就是不一致的,从当前域名的URL跳转到了目标域名的URL;反之,隐性的就是把目标URL隐藏了起来,表面看起来和当前域名一致。
而显性URL转发,又分为301临时性跳转和302永久性跳转,这就是为什么有的服务商把显性URL记录分为301跳转和302跳转的原因。
这两种域名解析记录,基本上都只有国内的域名解析服务商才有,而国外的服务商基本上都没有。
要使用这两种域名解析记录,域名必须经过备案,或者经过严格审核。
注意:不要随意使用域名的泛解析,如果自身技术水平不能确保泛解析安全的话。千万不能为了增加在百度里的网页收录数量或者其他目的,而随意启用泛解析。
具体缘由这里就不做长篇大论,有兴趣的读者请访问国内互联网安全媒体FreeBuf的一篇相关文章:《见缝插针:DNS泛解析是怎么被黑客玩坏的》,文章具体地址http://www.freebuf.com/news/133873.html。
拓展知识:
域名解析记录互斥表 https://www.cloudxns.net/Index/mutex.html
DNS体系中的标准资源记录类型及表示法集合
类型 | RFC来源 | 描述 | 功能 |
---|---|---|---|
A | RFC 1035 | IP 地址记录 | 传回一个 32 比特的 IPv4 地址,最常用于映射主机名称到IP地址,但也用于 DNSBL(RFC 1101)等。 |
AAAA | RFC 3596 | IPv6 IP 地址记录 | 传回一个 128 比特的 IPv6 地址,最常用于映射主机名称到 IP 地址。 |
AFSDB | RFC 1183 | AFS文件系统 | (Andrew File System)数据库核心的位置,于域名以外的 AFS 客户端常用来联系 AFS 核心。这个记录的子类型是被过时的DCE/DFS(DCE |
Distributed File System)所使用。 | | APL | RFC 3123 | 地址前缀列表 | 指定地址列表的范围,例如:CIDR 格式为各个类型的地址(试验性)。 | | CERT | RFC 4398 | 证书记录 | 存储 PKIX、SPKI、PGP等。 | | CNAME | RFC 1035 | 规范名称记录 | 一个主机名字的别名:域名系统将会继续尝试查找新的名字。 | | DHCID | RFC 4701 | DHCP(动态主机设置协议)识别码 | 用于将 FQDN 选项结合至 DHCP。 | | DLV | RFC 4431 | DNSSEC(域名系统安全扩展)来源验证记录 | 为不在DNS委托者内发布DNSSEC的信任锚点,与 DS 记录使用相同的格式,RFC 5074介绍了如何使用这些记录。 | | DNAME | RFC 2672 | 代表名称 | DNAME 会为名称和其子名称产生别名,与 CNAME 不同,在其标签别名不会重复。但与 CNAME 记录相同的是,DNS将会继续尝试查找新的名字。 | | DNSKEY | RFC 4034 | DNS 关键记录 | 于DNSSEC内使用的关键记录,与 KEY 使用相同格式。 | | DS | RFC 4034 | 委托签发者 | 此记录用于鉴定DNSSEC已授权区域的签名密钥。 | | HIP | RFC 5205 | 主机鉴定协议 | 将端点标识符及IP 地址定位的分开的方法。 | | IPSECKEY | RFC 4025 | IPSEC 密钥 | 与 IPSEC 同时使用的密钥记录。 | | KEY | RFC 2535 和 RFC 2930 | 关键记录 | 只用于 SIG(0)(RFC 2931)及 TKEY(RFC 2930、RFC 3455 否定其作为应用程序键及限制 DNSSEC 的使用。RFC 3755 指定了 DNSKEY 作为 DNSSEC 的代替。 | | LOC | RFC 1876 | 位置记录 | 将一个域名指定地理位置。 | | MX | RFC 1035 | 电邮交互记录 | 引导域名到该域名的邮件传输代理(MTA, Message Transfer Agents)列表。 | | NAPTR | RFC 3403 | 命名管理指针 | 允许基于正则表达式的域名重写使其能够作为 URI 、进一步域名查找等。 | | NS | RFC 1035 | 名称服务器记录 | 委托 DNS 域(DNS zone)使用已提供的权威域名服务器。 | | NSEC | RFC 4034 | 下一代安全记录 | DNSSEC 的一部分; 用来验证一个未存在的服务器,使用与 NXT(已过时)记录的格式。 | | NSEC3 | RFC 5155 | NSEC 记录第三版 | 用作允许未经允许的区域行走以证明名称不存在性的 DNSSEC 扩展。 | | NSEC3PARAM | RFC 5155 | NSEC3 参数 | 与 NSEC3 同时使用的参数记录。 | | PTR | RFC 1035 | 指针记录 | 引导至一个规范名称(Canonical Name)。与 CNAME 记录不同,DNS“不会”进行进程,只会传回名称。最常用来运行反向 DNS 查找,其他用途包括引作 DNS-SD。 | | RRSIG | RFC 4034 | DNSSEC 证书 | DNSSEC 安全记录集证书,与 SIG 记录使用相同的格式。 | | RP | RFC 1183 | 负责人 | 有关域名负责人的信息,电邮地址的 @ 通常写为 a。 | | SIG | RFC 2535 | 证书 | SIG(0)(RFC 2931)及 TKEY(RFC 2930)使用的证书。RFC 3755 designated RRSIG as the replacement for SIG for use within DNSSEC. | | SOA | RFC 1035 | 权威记录的起始 | 指定有关DNS区域的权威性信息,包含主要名称服务器、域名管理员的电邮地址、域名的流水式编号、和几个有关刷新区域的定时器。 | | SPF | RFC 4408 | SPF 记录 | 作为 SPF 协议的一部分,优先作为先前在 TXT 存储 SPF 数据的临时做法,使用与先前在 TXT 存储的格式。 | | SRV | RFC 2782 | 服务定位器 | 广义为服务定位记录,被新式协议使用而避免产生特定协议的记录,例如:MX 记录。 | | SSHFP | RFC 4255 | SSH 公共密钥指纹 | DNS 系统用来发布 SSH 公共密钥指纹的资源记录,以用作辅助验证服务器的真实性。 | | TA | 无 | DNSSEC 信任当局 | DNSSEC 一部分无签订 DNS 根目录的部署提案,使用与 DS 记录相同的格式。 | | TKEY | RFC 2930 | 秘密密钥记录 | 为 TSIG 提供密钥材料的其中一类方法,that is 在公共密钥下加密的 accompanying KEY RR。 | | TSIG | RFC 2845 | 交易证书 | 用以认证动态更新(Dynamic DNS)是来自合法的客户端,或与 DNSSEC 一样是验证回应是否来自合法的递归名称服务器。 | | TXT | RFC 1035 | 文本记录 | 最初是为任意可读的文本 DNS 记录。自1990年起,这些记录更经常地带有机读数据(区别于“人读数据”),以 RFC 1464 指定:Opportunistic Encryption、Sender Policy Framework(虽然这个临时使用的 TXT 记录在 SPF 记录推出后不被推荐)、DomainKeys、DNS-SD等。 |
其他伪资源记录类型
类型 | RFC来源 | 描述 | 功能 |
---|---|---|---|
* | RFC 1035 | 所有缓存的记录 | 传回所有服务器已知类型的记录。如果服务器未有任何关于名称的记录,该请求将被转发。而传回的记录未必完全完成,例如:当一个名称有 |
A 及 MX 类型的记录时,但服务器已缓存了 A 记录,就只有 A 记录会被传回。 | | AXFR | RFC 1035 | 全域转移 | 由主域名服务器转移整个区域文件至二级域名服务器。 | | IXFR | RFC 1995 | 增量区域转移 | 请求只有与先前流水式编号不同的特定区域的区域转移。此请求有机会被拒绝,如果权威服务器由于配置或缺乏必要的数据而无法履行请求,一个完整的(AXFR)会被发送以作回应。 | | OPT | RFC 2671 | 选项 | 这是一个“伪DNS记录类型”以支持EDNS。 |
相关RFC来源链接示例,如RFC 2671的URL为https://tools.ietf.org/html/rfc2671,其他RFC依次类推。此外,还有一些过时的记录类型,这里就不展示了。