我又换工作~~内容~~了!

继在上家公司身兼测试、实施、运维、客服、配置管理、质量管理、培训讲师等多职之后,如今在现任也开启了角色变更模式。

这次改得更彻底,连公司名也变啦。咱以后是『光载无限(北京)科技有限公司』的人了,不再属于『北京快网科技有限公司』了。

尽管我还是『武汉快网云计算有限公司』的。

哈哈,理不清关系吗?其实我也理不太清,不晓得是怎么搞的,反正还是『世纪互联』旗下的。

『光载无限』要成为『世纪互联』旗下重点品牌了,听说公司正在筹备品牌发布会,也不知道啥时候开。

使用网页工具 DNSViz 检查域名 DNSSEC 配置

关于 DNSSEC

DNSSEC 全称 Domain Name System Security Extensions,即 DNS安全扩展,是由 Internet 工程任务组 ( IETF )提供的一系列 DNS 安全认证的机制(可参考 RFC2535 )。

它是对 DNS 提供给 DNS 客户端(解析器)的 DNS 数据来源进行认证,并验证不存在性和校验数据完整性验证,但不提供或机密性和可用性。来源:域名系统安全扩展 - 维基百科,自由的百科全书

一些基础的相关介绍可参考我在 CloudXNS 官网发的文章(现均已迁移至本博):

  1. 什么是 DNSSEC ? DNSSEC 的概念及作用
  2. 如何验证 DNS 服务器是否支持 DNSSEC ?

通俗点讲, DNSSEC 的主要作用就是防止 DNS劫持,从而保证 DNS安全。

但在这个保证安全的过程中,DNSSEC 的 RR 和 RRSIG 的传输过程都是未加密的(即:不提供机密性),我们通过一些嗅探工具可以读取 RRSIG 记录以及由 DS 记录建立的信任链。

今天我们就来聊聊 DNSSEC 信任链的那些事。

DNS 资源记录( Resource Record ,简称 RR )介绍

DNS 资源记录简介

DNS server 内的每一个域名都有自己的域文件( zone file ), zone file 是由多个记录组成的,每一个记录就被称为资源记录( Resource Record ,简称 RR )。

当在设定 DNS 域名解析、反向解析及其他的管理目的时,往往需要使用不同类型的 RR ,也就是我们常说的记录类型。

上述 CloudXNS 的记录类型列表中,除 AX 、 CNAMEX 、 LINK 、 DR301X ( 301 跳转)、 DR302X ( 302 跳转)以及 DRHIDX (隐式跳转)为 CloudXNS 自研的扩展解析记录类型之外,其余都是 DNS 体系中常见的标准 RR 类型。

但除了我们系统中支持的这些类型外,事实上还有一些不太常用的目前 CloudXNS 暂不支持的其他 RR 类型,感兴趣的朋友可以和灰姑娘一起学习下。

隔壁粗事了!朝鲜顶级域 .kp 域名 DNS 数据配置可被转移

9 月 20 日上午 10 点左右,朝鲜的一台顶级域名服务器 ns2.kptc.kp 不小心配置允许全球 DNS 区域转移,任何人都可以向这台域名服务器发出区域转移请求,获取到一份朝鲜的顶级 DNS 数据拷贝。朝鲜泄漏的 DNS 数据显示,它的互联网/局域网规模确实非常小,域名寥寥无几。

如何验证 DNS 服务器是否支持 DNSSEC ?

众所周知,DNSSEC 对于 DNS 劫持虽然有极强的防御性,但由于被劫持的数据都会在验证失败后被丢弃,因而并不能让我们在 DNS 劫持的情况下获得正确的解析结果。(请先参考:什么是 DNSSEC ? DNSSEC 的概念及作用

所以,我们需要 DNS 安全传输的前提是加固客户端到 DNS 服务器之间的网络连接的安全性。

也就是说, DNSSEC 除了客户端支持之外,更重要的是 DNS 服务器本身必须有部署 DNSSEC 的支持。

否则:

  1. 客户端没有配置 dnssec-check-unsigned 而 DNS 服务器支持 DNSSEC ,此时 DNSSEC 默认信赖所有没签名的数据,等于没有提供任何防护;
  2. 客户端配置启用了 dnssec-check-unsigned 而 DNS 服务器不支持 DNSSEC , dnsmasq 因为不能获取任何 DNSSEC 签名信息导致不信任全部解析结果,进而使得整个 DNS 解析服务完全无法工作。

那么…

什么是 DNSSEC ? DNSSEC 的概念及作用

我们知道,过去由于环境良好,互联网先驱者们“ Too simple, Too Naive ”,他们设计了域名系统( Domain Name System ,DNS )。就像互联网的其他协议或系统一样,在过去可信的、纯净的环境里运行得很好。

而随着互联网的发展,如今充斥着各种欺诈、攻击,使得今天的互联网环境异常复杂,DNS 协议的脆弱性也就浮出水面。

DNS 最大的缺陷就是解析的请求者无法验证它所收到的应答信息的真实性,一些坏人对 DNS 的攻击可能导致互联网大面积的瘫痪,这种事件在国内外都屡见不鲜。

Jmeter 以 non-gui 模式进行分布式测试

由于 Jmeter 是一个纯 JAVA 的应用,用 GUI 模式运行压力测试时,对客户端的资源消耗是相当惊人的,所以在进行正式的压测时一定要使用 non-gui 模式运行,如果并发数很高或者客户端的硬件资源比较一般的话,还可以以 server 模式用多个 client 进行分布式测试。

下面以武汉快网 CMCC 项目为例,结合官方文档和自己的实际经验来谈一谈, Jmeter 如何以 non-gui 模式进行分布式测试。

转载:从理论到实践,全方位认识 DNS (理论篇)

对于 DNS(Domain Name System) 大家肯定不陌生,不就是用来将一个网站的域名转换为对应的 IP 吗。当我们发现可以上 QQ 但不能浏览网页时,我们会想到可能是域名服务器挂掉了;当我们用别人提供的 hosts 文件浏览到一个“不存在”的网页时,我们会了解到域名解析系统的脆弱。

然而关于 DNS 还有一大堆故事值得我们去倾听,去思考。