DNS NO GLUE

Author： Hagen.GoO 转载请注明作者出处
MSN contact： wantm009@hotmail.com
Keyword： DNS Report，NameServer，NS RRs，NO-GLUE，

DNS Report http://www.dnsreport.com/ 的在线工具在校验某域名配置时，parent nameservers 部分老是有 Glue at parent nameservers 即 NO GLUE 的警告。

看了网页上的简短说明，也不是非常明白所谓的 NO GLUE 到底是什么概念。翻阅相关书籍，略有斩获，招贴备忘。

我们知道，按照ICANN/IANA的协调：
COM. NET. 2个域的 nameservers 是 a.gtld-servers.net. b.gtld-servers.net. 等 A-M 13台服务器。
CN 和 COM.CN. 等中国国家的ccTLDs 的 nameservers 是 a.dns.cn. b.cns.cn. 等6台服务器。

第一种情况：比如我们申请到域名 domain.com.，在域名配置的控制面板可以注册并添加多条 NS RRs，如 ns1.domain.com. ns2.domain.com.等。这些新添加的 NS RRs 在其 parent nameservers 将以如下的方式存在：

domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.
ns1.domain.com. IN A xxx.xxx.xxx.xxx
ns2.domain.com. IN A xxx.xxx.xxx.xxx

即，我们可以使用类似这样的命令：
nslookup -q=any ns1.domain.com. a.gtld-servers.net.
nslookup -q=ns domain.com. a.gtld-servers.net.
直接在 a.gtld-servers.net. 处查询（非递归）到 domain.com. 相关的 NS RRs 以及对应的IP地址，这种情况就是 GLUE 的。

第二种情况：比如我们申请到域名 domain.com.，我们使用域名注册商提供的，且已经存在的 NS 来负责解析此域名，比如中国万网的 dns7.hichina.com. dns8.hichina.com.，这个时候在其 parent nameservers 将以如下的方式存在：

domain.com. IN NS dns7.hichina.com.
domain.com. IN NS dns8.hichina.com.

由于这是2台已经注册过的 nameservers ， 即还有：

dns7.hichina.com. IN A xxx.xxx.xxx.xxx
dns8.hichina.com. IN A xxx.xxx.xxx.xxx

dns7.hichina.com. dns8.hichina.com.和 domain.com. 同属于一个 TLDs，所以我们在向 a.gtld-servers.net. 查询（非递归） domain.com. 相关 NS RRs以及对应IP地址时，a.gtld-servers.net. 都能给出正确应答，这种情况也是 GLUE 的。

第三种情况：比如我们申请到中国国家域名 newdomain.cn.，我们使用域名注册商提供的 NS 来负责解析此域名，比如中国万网的 dns7.hichina.com. dns8.hichina.com.，这时 domain.cn.的相关NS在其 parent nameservers a.dns.cn中将以如下的方式存在：

newdomain.cn. IN NS dns7.hichina.com.
newdomain.cn. IN NS dns8.hichina.com.

由于 dns7.hichina.com. dns8.hichina.com.和 newdomain.cn. 不是同属于一个 TLDs，所以我们在向 a.dns.cn. 查询（非递归） newdomain.cn. 相关 NS RRs以及对应IP地址时，a.dns.cn. 只都能给出 NS 记录，不能给出其对应 IP 地址，需要我们再另外一次的递归查询才能得到对应 IP 地址。这种情况就是 NO GLUE 的。

另外还有一种特殊的情况，类似第二种情况，目标域名和 nameservers 的所属域名是同一个 TLDs 的，比如都是 COM. 的，但这几个 nameservers 没有在所属域名的 parent nameservers 中注册过，那么这种情况也应当是 NO GLUE 的。

总结一句话，在同一个 TLDs 的 parent namservers 上直接可以查询到目标域名相关的 NS RRs 以及 NS 对应的 IP 地址的情况就是 GLUE ，否则就是 NO GLUE。虽然 NO GLUE 略微会造成解析上的延迟，但不是致命的问题。有条件的域名建议使用 GLUE 的 NS。

另外： DNS Report 的工具在诊断 COM.CN.中国国家域名是否 GLUE 上有一点小小的问题，实用的时候，可以斟酌看待。

迅雷 FTP 下载的 BUG

Author： Hagen.GoO 转载请联系作者
MSN_contact： wantm009@hotmail.com
Keyword：迅雷，xunlei，WS_FTP Server，CuteFTP Server，Secure FTP Server，BUG

迅雷5 （5.4.1.230） 在从某些非匿名 FTP Server 上下载文件时存在重大兼容（BUG）问题。

经笔者仔细测试，常用的 Windows 平台的 FTP Server 中，迅雷5和如下两款FTP软件存在兼容问题：

IpSwitch （http://www.ipswitch.com）的 WS_FTP Server 5.05 以及
GlobalSCAPE （http://www.globalscape.com）的 Secure FTP Server 3.2。

默认配置情况下：
非匿名用户登陆 WS_FTP Server，其用户的 HOME 目录是 /USERNAME 或 /user/USERNAME
而非匿名用户登陆 Secure FTP Server，其用户的 HOME 目录则是：/usr/USERNAME

我以 WS_FTP Server 5.05 为例：图中所示：Download 用户登陆 WS_FTP Server，当前用户的默认 HOME 目录就是 /download；

比如其目录下有 TEST.ZIP 文件，于是此文件的完整下载路径就是FTP://DOWNLOAD:PASSWORD@FTP.SERVER.COM/DOWNLOAD/TEST.ZIP。我们把这个链接添加到迅雷的新下载任务，就会发现迅雷任务失败。但同样的链接，在 Flashget 或 Flashfxp 这样中规中矩的软件中则完全可以。经过比较，迅雷在登陆 WS_FTP Server 成功以后，向服务器提交的文件请求都是相对路径的，而非绝对路径。如图所示。

即：当前路径已经是 /download，迅雷再提交 RETR download/test.zip 自然就出错了，而 Flashget 或 Flashfxp 提交的都是绝对路径的 RETR /download/test.zip，所以就能正常下载。

简单言之：如果 FTP 登陆以后的 HOME 目录是 / ，迅雷都能正常下载。但如果是类似 /USERNAME 的情形，由于相对路径的所致，迅雷一定报错。

此问题（BUG），已经正式递交迅雷官方，静待处理中……

愚蠢的新网

Author： Hagen.GoO 转载请联系作者
MSN_contact： wantm009@hotmail.com
Keyword： DNS，新网，域名注册

前阶段，号称中国最大的域名注册商新网公司 http://www.xinnet.com/ 被黑客攻击、长时间不得恢复一事，闹得沸沸扬扬。
为防止这样的事故重演，给自己在新网的 CN 域名多添加几个 NameServer 势有必要。
打开新网的域名控制面板，除默认的2个 NS （ns.xinnet.cn 和 ns.xinnetdns.com）以外，新网还允许用户自行添加新的 NS RRs，如图：

添加完毕，过24小时去查看 DNS 修改的生效情况。

先到 .CN 的 NameServer，A.DNS.CN 上查询，发现添加的2条新 NS RRs 已经生效，截图可以看到，总共有4个 NameServer 负责本域名解析。心觉OK了。

再去本域名原先默认的2个新网 NameServer：ns.xinnet.cn 和 ns.xinnetdns.com ，但查询半天也没有新添加的 NS 的影子。有图为证。

和新网的客服及技术员支持理论半天，对话撂下一句：这是没有办法的、系统就这样。

新网这种承载用户 DNS 解析服务的公司，要么就不要允许用户自行添加 NS RRs，既然允许，就应该在其默认的 NameServer 上做好相应配置！对客户不负责，对技术不精益求精，活该被黑！！

在 Trend Micro IMSS 外发邮件时使用目标域名的特定 MX RRs

Author： Hagen.GoO 转载请注明作者出处
MSN contact： wantm009@hotmail.com
Keyword： Trend Micro，TrendMicro，IMSS，InterScan，Mail Gateway

朋友公司安装在 Windows Server 上的 Trend Micro IMSS 遇到了一点问题，大致情形是：
某目标域名（target.com）有3个 MX 记录，分别是：

target.com. IN MX 10 mx1.target.com.
target.com. IN MX 20 mx2.target.com.
target.com. IN MX 50 mx-backup.target.com.

某些特殊原因，IMSS在连接 mx1/mx2 的时候老是 554 被拒，猜想IMSS的IP可能进入了对方 mx1/mx2 的黑名单，不过手动测试 mx-backup 倒是可以连接。但是愚蠢的 IMSS 每次都是按照 MX 的优先级依次尝试，当连接到 mx1/mx2 发生 554 被拒时，就停止尝试，无论如何都无法连接到 mx-backup 。

原想：修改 %SYSTEMROOT%\SYSTEM32\DRIVERS\ETC\HOSTS 手动添加一条“x.x.x.3 target.com”（x.x.x.3 表 mx-backup 的IP地址）的记录就可以搞定。但测试发现 IMSS 使用的是自己的 DNS 函数，并不会调用本机上的 HOSTS 文件，此法作古。

经过一番苦思，得另两法：

1，修改路由法。即在 IMSS 的服务器上手动修改本机到 mx1/mx2 的路由，以期 IMSS 无法连接到 mx1/mx2，继而被迫连接 mx-backup。（当然也可以在上一级路由器上，或者防火墙上配置）操作命令行下执行：

route add x.x.x.1 mask 255.255.255.255 GATEWAY-IP metric 99 （x.x.x.1 表 mx1的IP地址）
route add x.x.x.2 mask 255.255.255.255 GATEWAY-IP metric 99 （x.x.x.2 表 mx2的IP地址）
注： GATEWAY-IP 应是一个不可到达，或者无效的网关地址。可以是本机的内网IP，或同网段其它IP。

2，使用 SmartHost 递交法。即针对 target.com 域的邮件都转发到 SmartHost 中所列的 mx-backup 上。操作如下：

IMSS WEB 控制台 -> Configuration -> SMTP Routing -> Delivery -> Domain-Based Delivery
-> 添加一个记录：域名target.com 递交方法 SmartHost x.x.x.3:25 （如图：）

方法2可能会有小小的漏洞：即对于 target.com 域来说，本地 IMSS 是一个 OpenRelay 的服务器；但方法1则受到网络配置的局限。因此是各有千秋，依酌而使吧。

Trend Micro IMSS 中限制邮件大小的设置

Author： Hagen.GoO 转载请注明作者出处
MSN contact： wantm009@hotmail.com
Keyword： Trend Micro，TrendMicro，IMSS，InterScan，Mail Gateway

　　Trend Micro InterScan Messaging Security Suite （IMSS）是台湾趋势科技中小企业级的邮件防毒产品。一直以来没有好好研究过它在限制邮件大小方面关于 Per Session 和 Per Connection 的定义。趋势的帮助文档和官方KB也都没有仔细描述。
　　近日朋友的 IMSS 由于在限制邮件大小上出了点问题，所以得暇稍微留意了一下。

　　IMSS 在 Configuration － SMTP Routing － Message 菜单，对邮件大小有4项定义，如图：

A Limit message size （解：限制单个邮件尺寸）
B Limit data size per session （解：限制每会话数据尺寸）
C Limit number of messages per connection （解：限制每连接邮件个数）
D Limit number of recipients per message （解：限制每邮件收件人数）

　　其中项A和D都比较好理解，但是项B和C中的，per session 和 per connection 到底做何解释呢？
　　请看下面一个发送实例：

EHLO DOMAIN.COM //EHLO 命令
250 OK
MAIL FROM:<USER@DOMAIN.COM> //第一个 MAIL FROM 命令
250 <USER@DOMAIN.COM>: Sender Ok
RCPT TO:<recipient@target-A.com> //target-A 的收件人
250 <recipient@target-A.com>: Recipient Ok
DATA //DATA 命令
354 ESMTP: Send data now. Terminate with "."
. //以.命令结束第一次发送
250 ESMTP: Message accepted for delivery
MAIL FROM:<USER@DOMAIN.COM> //第二个 MAIL FROM 命令
250 <USER@DOMAIN.COM>: Sender Ok
RCPT TO:<recipient@target-B.com> //target-B 的收件人
250 <recipient@target-B.com>: Recipient Ok
DATA //DATA 命令
354 ESMTP: Send data now. Terminate with "."
. //以.命令结束第一次发送
250 ESMTP: Message accepted for delivery
QUIT //退出命令

　　这个例子中，MTX在第一个邮件发送完成以后并没有使用 QUIT 命令退出，就继续 MAIL FROM 命令，在原有TCP连接上直接发送第二个邮件。
　　于是我们可以看到在这个TCP连接中一共发送了2个邮件，数据量大小就是2个目标邮件的总和。所以项B和C就是判断这种情况下的阀值。

禁止 MSN Spaces 调用本地 MSN Messenger

Author： Hagen.GoO 转载请联系作者
MSN_contact： wantm009@hotmail.com
Keyword： CLSID，MSN Spaces，MSN Messenger，{F77CE52C-FDD7-4487-9EE1-ACC80BAAB3CC}
Quote：

MSN Spaces 不仅网速慢，而且过于迂腐JS脚本，通常把IE浏览器搞个半死。

最令人讨厌的是：MSN Spaces还会调用本地的 MSN Messenger。

刚才花了几分钟，通过 Sysinternals Regmon 工具对注册表的监控：发现只要删除注册表中{F77CE52C-FDD7-4487-9EE1-ACC80BAAB3CC}的CLSID项就能阻止 MSN Spaces 调用本地 MSN Messenger。

此CLSID的具体位置是：（删除其中任意一处即可）

HKEY_CLASSES_ROOT\CLSID\{F81CD990-910B-4bbf-9CB3-6A77F3D697B3}
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{F81CD990-910B-4bbf-9CB3-6A77F3D697B3}

利用 Windows 自带命令修复文件关联

Author： Hagen.GoO 转载请联系作者
MSN_contact： wantm009@hotmail.com
Keyword： EXE文件关联，exefile，木马
Quote：

翻阅 Windows 帮助文件的时候，发现2条修改系统文件关联的有用命令：assoc 和 ftype 。

• assoc 是命令行的显示或修改文件扩展名关联命令；
• ftype 是命令行的显示或修改用在文件扩展名关联中的文件类型。

有些恶意程序或木马程序，习惯修改文件关联，使用上述2条命令，就能快速修复，简单方便。试举例说明：

.EXE的可执行文件，可以适用：

assoc .exe=exefile
ftype exefile="%1" %*

.COM的可执行文件，可以适用：

assoc .com=comfile
ftype comfile="%1" %*

.CHM帮助文件可以适用：

assoc .chm=chm.file
ftype chm.file="hh.exe" %1