DNS and BIND

转载的评价:
本书是介绍bind和dns的权威书籍,由于市面上介绍bind和dns的书比较少,所以本书的
份量也就更重了。本书从dns的基本概念到dns的实现程序bind都作了详细的介绍。如果
你是dns的维护人员,应该通读这本书。如果你想了解一下dns的概念和bind程序的基本
应用,这本书也提供的大量的相关知识。不同层次的人员可根据自已的实际情况选读相关章
节。由于我应用dns只是在局域网内做一下名字解析,应用较浅,所以我只挑了个别章节看
了一下,没有深入dns的高级部份,所以读书笔记也就只包含这部分的内容了。

第一章 背景
    dns是针对ARPnet的特殊问题发展起来的,在整个20世纪70年代,ARPnet还是一个
有几百台主机的很小很友好的网络。仅仅需要一个名为HOSTS.TXT的文件就能容纳所有需
要了解的主机信息。该文件由SRI(Stanford Research Institute的前身)的网络信息中心
(Network Information Center NIC)负责维护,并从一台主机SRI-NIC上分发到整个网络。
ARPnet的管理员通常定期通过电子邮件的方式将他们的变更通知SRI,同时还定期ftp到
sri-nic,以获取最新的HOSTS文件。但随着ARPnet的增长,这种方法行不通了。流量和负
载使SRI的线路不堪重负;名字冲突,造成网络混乱;在不断扩张的网络上要维护文件的
一致性变得越来越难。关键问题是HOSTS文件的结构不是很好,最终导至了hosts文件的
失败和落伍。
    ARPnet的管理者们开始投入研究,为HOSTS.TXT文件寻求继任者。Paul Mockapetris,
当时在南加州大学的信息科学所,负责设计新系统的体系架构。1984年,他发布了描述DNS
的RFC882和RFC883。后来它们被RFC1034和RFC1035所取代,也就是目前的DNS规范。
目前,还有很其它RFC补充RFC1034和RFC1035的内容,它们描述了DNS的安全问题,
实现问题,管理问题等。

DNS 简述
实际上,DNS是一个分布式数据库,它允许对整个数据库的各个部份进行本地控制;同时
整个网络也能通过客户-服务器方式访问每个部份的数据。借助备份和缓存机制,DNS将具
有强壮性和足够的性能。DNS的数据库结构同unix文件系统的结构非常相似,就像一棵倒
着的树。

第二章 DNS是如何工作的
介绍了DNS的工作原理,一些功能和名词。

第三章 如何开始工作
获是bind软件
选择一个域名

第四章 建立BIND
建立区数据,包括正向解析文件(名字到地址的映射),反向解析文件(地址到名字的映射)。
每个网络都有包含它自已的反向映射数据文件。名字服务器用named.conf配置文件把所有
的区数据文件绑定在一起。

区数据文件
区数据文件中的大部份条目被称为DNS资源记录。DNS查找是不区分大小写的,但大写是
被系统保留的,建议用小写。资源记录必须从一行的第一列开始。在DNS RFC中,表示资
源的记录是按特定顺序排列的,但这不是必须的。顺序如下:
SOA记录 指示该区的权威
NS记录 列出该区的一个名字服务器
A 名字到地址的映射
PTR 地址到名字的映射
CNAME 规范名字(相对于别名而言)

注释是以“;”号开始的

设置区默认的TTL值。
在8.2版本前,SOA记录中最后一个字段设置区默认的TTL值。在8.2版出来前,公布了
RFC2308,将SOA记录中最后一个字段的含义改为了“否定缓存TTL”,它的意思是一个远
程名字服务器能将区的否定响应缓存多长时间,否定响应是报告某个域名或某个域名的某个
数据类型不存。8.2版及后继版中用$TTL控制语句。名字服务器在查询响应中提供这个值,
允许其它服务器将数据在缓存中存放TTL所指定的时间。如果数据不是经常变动的,可以
考虑把它的值设为几天,1周大概是使之有意义的最大值。1小时会引起不必要的DNS流量。
如:$TTL 3h

SOA记录
表示对于该区数据而言,这个名字服务器是最好的信息来源。根据这个SOA记录,我们的
名字服务器就享有对该区的权威。
movie.edu IN SOA terminator.movie.edu. al.robocop.movie.edu. (
1 ;序列号
3h ;3小时后刷新
1h ;1小时后重试
1w ;1周后期满
1h) ;否定缓存TTL为1小时
IN 代表Internet类
terminator.movie.edu. 代表主名字服务器
al.robocop.movie.edu. 把第一个点号换成@,代表邮件地址,对电脑没意义,只对人有意义

在反解文件的头几行也添加类似的SOA记录。在这些文件中把movie.edu改为
249.249.192.in-addr.arpa

NS记录
在文件中添加的下一条记录是NS记录。这些记录表明区movie.edu有两个名字服务器。这
些名字服务器运行在主机terminator.movie.edu and wormhole.movie.edu上。
movie.edu IN NS terminator.movie.edu
movie.edu IN NS wormhole.movie.edu
同SOA记录一样,也在反解文件中添加记录

地址和别名记录
接下来创建名字到地址的映射
;主机地址
localhost.movie.edu. IN A 127.0.0.1
robocop.movie.edu. IN A 192.249.249.2
terminator.movie.edu. IN A 192.249.249.3
misery.movie.edu. IN A 192.249.253.2
;
;多宿主主机
wormhole.movie.edu. IN A 192.249.249.1
wormhole.movie.edu. IN A 192.249.253.1
;
;别名
bigt.movie.edu. IN CNAME terminator.movie.edu.
wh.movie.edu. IN CNAME wormhole.movie.edu.
wh249.movie.edu IN A 192.249.249.1
wh253.movie.edu IN A 192.249.253.1
像bigt.movie.edu这样的别名不能出现在资源记录的右边。换名话说,在资源记录的数据部
份总是要使用规范名(terminator.movie.edu)。
如果一台主机是多宿主的(具表不止一个网络接口),让每个接口对应一个唯一的别名,再
为这个别名创建一个地址(A)记录,为每个对所有地址都通用的别名创建一个CNAME记
录。能否在所有情况下都使用地址记录而不用CNAME记录呢?大部份程序是可以的,但
sendmail会有问题。sendmail通常用规范名替换邮件首部中所有使用的别名,只有当邮件首
部中的名字有相关的CNAME记录时才进行这种规范化。如果你的别名没有对应的CNAME
记录,你的SENDMAIL就必须知道你的主机所有可能为外界所知的别名,这就要求你对
SENDMAIL进行一些额外的调整。

PTR记录
创建地址到名字的映射,使用PTR资源记录
1.249.249.192.in-addr.arpa. IN PTR wormhole.movie.edu.
2.249.249.192.in-addr.arpa. IN PTR robocop.movie.edu.
3.249.249.192.in-addr.arpa. IN PTR terminator.movie.edu.
对于192.249.253/24也创建类似的数据。

需要设置回送网络的正反解文件。如果没有则查找127.0.0.1就会失败。

根线索(root hint)数据。从ftp.rs.internic.net里上载。

建立BIND配置文件
从版本4到版本8,BIND配置文件的语法变化非常大,版本8到版本9没有变化。可以通
过运行named-bootconf程序把版本4的配置文件转换成版本8的文件。这个程序随BIND源
码一起发布。

h2n工具是一个PERL脚本,用来把HOSTS文件转换成区数据文件。

运行名字服务器
#named

设置本地域名,这样可以直接查找主机名而不用加上域名。有两种方法设置:hostname or
/etc/resolv.conf。在resolv.conf的第一行加入domain  movie.edu。或者在terminator主机上
把hostname设置为terminator.movie.edu。不要在名字后加点号。

用远程的名字服务器来查找你的区中的域名,把本地域名作为第一个参数,远程名字服务器
作为第二个参数。如果失败,可能是你的区还没有向你的父名字服务器注册。需与父域管理
员联系,检查区授权。
# nslookup carrie getekeeper.dec.com

运行辅名字服务器
需要再建立一个名字服务器以增强DNS的健壮性。以便分担负荷和容错。在named.conf文
件中定义是主还是辅服务器。主要区别是主名字服务器从区数据文件中读取数据,辅服务器
是通过网络从其它的名字服务器装载数据的,这个过程称为“区传送”(zone transfer)。

建立
在辅名字服务器建立区数据文件目录(/etc/named),并把named.conf,named.root,db.127.0.0
这三个文件拷贝过来。修改配置文件,把域的master改为slave,然后添加一个带主服务器ip
地址的masters行。例如:
zone “movie.edu” in {
type master;
file “db.movie.edu”;
};
改为
zone “movie.edu” in {
type slave;
file”bak.movie.edu”;   如果不想在辅名字服务器上保存区数据文件的备份,可以删除这
行。
masters {192.249.249.3};
};

SOA值
序列号:格式为yyyymmddnn,nn代表这一天是第几次修改。在每次更新了你的区数据后
不要忘了增加序列号的值。辅名字服务器通过比较这个序列号是否加载一份新的区数据拷
贝。
refresh(刷新):告诉该区的辅名字服务器相隔多久检查该区的数据是否是最新的。
retry(重试):如果辅名字服务器超过刷新间隔时间后无法访问主服务器,那么它就开始隔
一段时间重试连接一次。这个时间通常比刷新时间短,但也不一定非要这样。
expire(过期或期满):如果在期满时间内辅名字服务器还不能和主服务器连接上,辅名字服
务器就使用这个我失效。这就意味着辅名字服务器将停止关于该区的回答,因为这些区数据
太旧了,没有用了。设置时间要比刷新和重试时间长很多,以周为单位是较合理的。
否定缓存TTL(生存期):这个值对来自这个区的权威名字服务器的否定响应都适用。
新版的bind的时间设置灵活了很多,以前只接收以秒为单位(一周有608400秒)。现在可
以用h(小时),d(天),w(周)表示。
RFC1537建议顶级名字服务器采用以下值:
refresh 24h
retry 2h
expire 30d
否定缓存ttl 4d
新版8,9改变了区数据传播的方式,轮询的特性还在,但增加了当区数据改变后进行通知
的功能,在15分钟之内通知辅名字服务器,要加载该区的一份新的拷贝了。

多个主服务器
可配置最多十个主名字服务器,以分号分隔。辅名字服务器会依序尝试每个IP地址对应的
主服务器。一直到收到回答为止。但从8.2以后,辅服务器会查询所有的主服务器,从具有
最高序列号的服务器那里传送区数据。

第五章 DNS与电子邮件
DNS与主机表相比的一个优势在于支持高级邮件路由。当邮件收发器只用HOSTS文件工作
时,所能做的最多也就是试着把邮件直接发送到主机的IP地址,如果失败,要么延迟发送,
过一会再重试,要么就将邮件退回给发送者。dns提供一种机制,能为邮件的发送者指定备
份主机,它还允许一台主机为别的主机承担邮件处理任务。
DNS用一种资源类型来实现增强的邮件路由,那就是MX记录。它为一个域名指定一个邮
件交换器。它是一台主机,负责处理或转发该域名的邮件。还定义了一个优先级值,它决定
了邮件收发器使用它们顺序,优值小的先使用。
peets.mpk.ca.us. IN MX 10 relay.hp.com 指定relay.hp.com是peets.mpk.ca.us的邮件交
换器,优先级是10

第六章 配置主机
reslov.conf中有五个命令可你使用,domain,search,nameserver,sortlist,options。
domain定义本地域名,从第一行开始,后跟一个空格,然后是本地域名,本地域名后面不
要有点号。
例如:domain movie.ecu
LOCALDOMAIN环境变量也可以设置每个用户的本地域名。
建议使用hostname设置。

search指令
search corp.hp.com paloalto.hp.com hp.com
解析器会首先搜索corp.hp.com,然后是paloalto.hp.com,再是这两个域的父域hp.com。

nameserver指令
默认地,解析器首先查找本地上的名字服务器,也可以通过该指令指示解析器去使用其它主
机的域名服务器。
nameserver 15.32.17.2
nameserver 15.32.17.3  (可指定多个服务器)
注意:在多个nameserver的情况下不要使用回送地址。

sortlist指令
当查询收到的响应包括多个地址时,该设置允许你选择更希望使用的子网和网络。
sortlist 128.32.42.0/255.255.255.0 最多可指定十个优先的子网和网络。

options指令
options debug 设置RES_DEBUG,在标准输出上产生大量调试数据。前提是在编译BIND时
定义了DEBUG参数。
options ndots:2 如果域名参数中的点号大于或等于这个值,那么解析器会在使用搜索列表
之前,先查找这个域名。如果你相信你的用户更有可能输入部份域名而需要使用搜索列表时,
你可以增加这个值。
8.2版引入以下选项
options attempts:2  允许你指定在放弃之前向resolv.conf文件中每个名字服务器发送查询的
次数。
options timeout:2 指定每个对resolv.conf文件中名字服务器的查询的初始超时时间。默认为
5,最大为30。对第二轮以及接下来的几轮查询,解析器会把初始超时时间加倍。再除以
resolv.conf中文件服务器的数量。
options rotate 使你的解析器能使用resolv.conf文件中所有的名字服务器。从而分散负载。默
认只要第一台服务器正常,解析器是不会去查询其它服务器。
options no-check-names 关掉解析器的名字检查功能,默认是打开的。它检查响应的域名是
否合法。
如果你想指定多个选项,可以把它们写成一行:
options attempts:4 timeout:2 ndots:2

第七章 维护BIND
BIND9与8一样,也用controls来决定服务器如何监听控制信息的。
controls {
inet * allow {any;} keys {“rndc-key”}
};
这决定了rndc用户要用什么加密密钥来验证身份才能给服务器发送控制信息。如果没有指
定keys,服务器启动时会出错
key “rndc-key” {
algorithm hmac-md5;
secret “xxxxx”;
};
为安全起见,使用包括文件:
include “/etc/rndc.key”。唯一支持的算法是HMAC-MD5。
要使用rndc,你需要创建一个rndc.conf文件告诉rndc要用哪个认证密钥。而哪些名字服务
器要使用它们。
options {
default-server localhost;
default-key “rndc-key”;
};

key “rndc-key” {
algrithm hmac-md5;
secert “xxxxx”;
};

更新区数据文件,两种方法,手工 或 h2n。

重新开始一个SOA序列号。改变主服务器序列号,重启,停止辅服务器,删除所有备份区
数据文件。因为备份文件被删除,所以辅服务器就会加载一个新的区数据文件,这个区数据
文件就是最新的。

TXT
xxx IN TXT “this is a test”   限制2K字符串数据

RP  负责人邮件地址
robocop IN RP root.movie.edu

组织文件
当域大的时候,区数据文件就会越来越多,有两个命令可以帮助我们组这些文件:
$ORIGIN 改变一个区数据文件的起点
$INCLUDE 在当前区数据文件中插入一个新文件

改变系统文件的位置,主要是从安全角度考虑。
options {pid-file “server1.pid”;} 改变PID的文件名,可以在一台主机上运行两个名字服务
器。
options {named-xfer “/HOME/….”;} 在9版中没有这个文件。
options {dump-file “/home/yangjing/named/named_dump.db”;} 服务器转储数据库
options {statistics-file “/home/yangjing/named/named.stats”;} 服务器统计数据

日志
有七个级别,允许存在文件中或伸用syslog日志系统。
critical
error
warning
notice
info
debug [level] dns服务器特有
dynamic dns服务器特有

语法如下:
logging {

            [ channel channel_name {

              ( file path_name

                 [ versions ( number | unlimited  ]

                 [ size size_spec ]

               | syslog ( kern | user | mail | daemon | auth | syslog | lpr |

                          news | uucp | cron | authpriv | ftp |

                          local0 | local1 | local2 | local3 |

                          local4 | local5 | local6 | local7 

               | null ;

 

              [ severity ( critical | error | warning | notice |

                           info  | debug [ level ] | dynamic ; ]

              [ print-category yes_or_no; ]

              [ print-severity yes_or_no; ]

              [ print-time yes_or_no; ]

            }; ]

 

            [ category category_name {

              channel_name; [ channel_name; … ]

            }; ]

            …

          };

example:

logging {
channel my_syslog {
syslog daemon;
severity info;
};
channel my_file {
file “my_named.log” versions 3 size 10k;
severity dynamic;
print-category yes; 在日志中输出附加信息:消息类别,严重性,时间。
print-severity yes;
print-time yes;
};
category default {unll;}; 如果对于某个类别你没有指定任何通道,那么就会把这些消息发
送到default类所分配的通道中。
category statistics {my_syslog;my_file;};
category queries {my_file;};
};

要记录这些日志,还要再打开名字服务器的调试功能。
#rndc trace
versions 3 文件版本,会保存file,file.0,file.1,file.2,如果不设置将有99个版本。在服务
器启动和重新加载时将file.1-file.2,file.0-file.1,file-file.0。
size 10k 文件的大小限制。

default_stderr通道可把信息写到服务器的stderr中。

null通道可以用来丢弃不想要的信息。

bind9类别
general 包括所有未明确分类的信息。
client 处理客户端请求
config 配置文件分析和处理
database 数据库相关信息
dnssec 处理DNSSEC签名响应
lame-servers 发现错误授权
network 网络操作
notify 异步区变动通知
queries 查询日志
resolver 名字解析,包括对来自解析器的递归查询的处理
security 认可/非认可的请求
update 动态更新事件
xfer-in 从远程名字服务器到本地服务器的区传送
xfer-out 从本地到远程的区传送

第八章 扩展你的域

第九章 担当父域

第十章 高级特性
新版BIND8.1.2 9.10有大量的新特性,其中最突出的是支持DNS动态更新,异步区变动通
知(NOTIFY),以及增量区传送。

地址匹配列表和ACL
acl name {address_match_list;}; 定义一个列表,以后可用name引用
acl “hp-net” {192.168.1.192/26;};
有四个预定义的列表:none,没有任何IP地址;any,所有IP地址;localhost,本地主机的
任一IP地址;localnets,本地主机任一网络接口所在的网络。

第十一章 安全
限制查询  allow-query{}
防止未授权的区传送 allow-transfer{}
以最小权限运行bind,-u 以该用户运行, -g 以该组运行,-t 使用chroot()转到的目录。
使用chroot步骤见书例子。

第十二章 nslookup and dig

如果没有“NoFollow”

自从2005年Google率先引入对链接的“nofollow”属性(“rel=’nofollow’”)的支持以来,对其各种各样质疑的声音便未间断过,其中,以SEO(搜索引擎优化)界为甚,毕竟,“nofollow”属性剥去了链接的价值,对建构于链接的SEO影响最大。

近来,关于移除blog如WordPress默认在留言链接使用“nofollow”属性设置的讨论成为了热点,许多人认为,为了体现对留言者劳动的尊重并回馈留言者,应当将留言链接中的“nofollow”属性移除,从而,刺激留言者在blog中参与讨论的积极性,客观地看,这种说法不无道理。甚至,还有更进一步者,有人认为通过这样,可以让用户真正地参与到blog建设中来,实现blog向Web 2.0的转化  ——老实说,究竟什么是Web 2.0,本人一直搞不太清楚,但与其相信通过刺激用户留言便能构成“用户贡献内容”的Web 2.0模式,我宁可相信博客学堂所认为的移除“nofollow”属性只会让博客变成老式论坛的结论,当然,这是题外话了。

对“nofollow”的质疑,比较有代表性的便是Loren Baker在13 Reasons Why nofollow Tags Suck中所归纳的链接“nofollow”属性的十三条罪状,其主要观点包括:

  • “nofollow”属性并没有起到当初预期中有效地抑制blog spam的效果;
  • 如果blog人工审核留言的话,那么,便完全没有必须必要在留言链接中使用“nofollow”属性;
  • 留言是对blog内容的有益补充与完善,因此,有得便理应有所付出,应当给予事实上在帮助自己建设blog的留言者真正的链接以回报;

是不是很有道理?

毋庸置疑,“nofollow”属性在对付blog spam方面显得力不从心,远不是一个理想的解决方案,但是,至少在现阶段,是不是存在比“nofollow”更有效、更好的办法?移除blog留言链接中的“nofollow”属性或者干脆取消“nofollow”属性,真的能带来blog与留言者的双赢?

恐怕情况并不那么简单。让我们来简单地分析一下如果blog留言链接中没有“nofollow”属性,情况将会怎样:

Blog需投入更多的时间与精力检查链接

在blog留言链接中使用“nofollow”属性,对blog建设者或管理者而言最大的好处在于,即使审核留言,也只需审核留言本身是不是与文章真正相关,是不是针对内容进行讨论,而不必对留言中的链接投入过多的关注:即便其中存在不当的链接、无关的链接甚至404死链接,在“nofollow”的保护下,不必担心会给自己的blog带来伤害。

但如果没有了“nofollow”,blog管理者则必须在链接管理方面投入更多的精力,如果希望自己的blog不受伤害,则至少应避免出现如下的链接:

  • 不当网站如色情、赌博网站的链接;
  • 被搜索引擎判定为链接工厂的链接;
  • 404错误链接,这可能是最令人头痛的,即使在留言发布时该链接没有问题,但如何保证该链接在日后仍能有效?莫非需要定期每周或至少每月检查网站的死链接数量?毕竟,网站出现大量的404链接是SEO的大忌;

而如果blog希望能在SEO方面有所作为的话,要考虑的因素会更多,比如说以Google为代表的主流搜索引擎大都在算法中结合网站内容、出入站链接来定位网站所处的行业、领域乃至网站在所处行业中的位置,那么,当blog中存在大量的无关链接——这应该是不可避免的——时如何让搜索引擎正确了解自己并建立信任是一个至关重要的大问题。

搜索引擎调整算法,降权blog链接的价值

对搜索引擎而言,要保证搜索质量,返回最相关的搜索结果,其必须首先能够保证最大限度地排除spam对其算法的影响。从这个角度看,Google引入“nofollow”并不是要对抗或消除日益猖獗的blog spam大潮,而是希望在其排名算法中引入一道将blog spam拒之门外的防线,换言之,对Google而言,只要blog spam不能影响其搜索结果便达到推出“nofollow”的目的,至于是不是消灭了blog spam,倒还在其次,甚至用点“无赖”的话说,那与Google无关。如果这样看,“nofollow”属性似乎并不是那么“失败”!

那么,如果没有了“nofollow”呢?搜索引擎为了避免、减小或降低blog spam对搜索结果的影响,似乎只能对blog留言中的链接降权处理,甚至对整个blog内的链接降权——危言耸听么?很难说——直接的结果便是所预期的“回报留言者”的设想落空。对blog而言,存在大量的无关或不当链接还有一个是否会受到搜索引擎惩罚的问题。

必然结果便是非但不能达到blog与留言者的双赢,而是双输!

作者: highdiy
原载: 点石互动搜索引擎优化博客

腾讯QQ屏蔽大部分CN域名

腾讯QQ目前已经在聊天对话中屏蔽了大部分CN域名的地址,只有少数一些CN域名得以幸免,具体的表现形式是:当QQ对话的一方输入的聊天信息包含以.cn为结尾的网站地址的时候,腾讯QQ会将整条信息忽略不予显示,对方QQ的屏幕将不显示任何信息。  据我的分析,腾讯QQ的这个行为可能是为了对付愈演愈烈的中文SPAM网站的不得已的措施,由于.cn域名一度以极其低廉的价格(1元价)疯狂倾销,导致不少黑帽SEO站长注册大量cn域名用于制造链接工厂,同时制造大量垃圾信息和垃圾网站。搜索引擎通常通过降权或去除的方式屏蔽这些垃圾网站,但是由于低廉的cn域名导致这样的行为成本极低,被搜索引擎封掉大批域名也不会造成什么损失,因此他们就使用注册的cn域名疯狂进行SPAM。垃圾站点通常使用作弊手法来误导搜索引擎或者网络用户使其错误地进入垃圾网站,很常见的形式是通过木马病毒或者其他方式在QQ聊天记录上增加尾巴信息,误导和欺骗用户进入某些垃圾网站,当这类信息越来越多的时候,最终导致腾讯QQ痛下杀手,直接屏蔽大部分包含.CN的域名。

  经过我的测试,www.vnet.cn(老流氓互联星空)、www.google.cn(谷歌)、www.net.cn(万网)等较为知名的CN网站以及单字母的cn域名(不带www的)都还可以显示,大部分com.cn的域名也可以显示,但是.cn的域名就大部分不能显示,有趣的是,腾讯连自家域名也不放过,www.qq.cn这个域名也是不能显示的。

  微软的MSN也做过类似的事情,国外搞垃圾网站通常也是注册廉价域名,MSN也将廉价注册的INFO域名(0.99美元价格)彻底屏蔽。

  更新:19日晚,腾讯QQ解除了对.cn域名的屏蔽。

AdSense支持在新窗口中打开广告

Google AdSense 首先面向中国发布商发布了一项非常重要的功能 – 在新窗口中打开广告。这是继”允许的网站”之后,AdSense 根据中国发布商的需求以及中国用户的用户体验,对 AdSense 广告联盟产品作出的又一项重大改进。  用户在发布商的网站上点击广告后,广告网页将在一个新的浏览器窗口中呈现。这样,用户不必使用浏览器”后退”按钮才能返回到发布商的网站继续浏览,也能够避免用户意外离开网站造成该网站的用户流失;同时,这一功能也为用户浏览网站以及广告网页带来了方便。

  Google AdSense 广告联盟一贯重视中国市场以及中国发布商的需求,希望通过对产品的不断改进,为用户带来更好的体验,为广告主带来更好的投入回报,也为发布商带来更大的收益。实现用户、广告主以及发布商与 Google的四方共赢!

Google网络存储容量可能高达50G

出处:cnbeta

  调研机构iSuppli近日表示,Google即将推出的免费网络存储空间容量可能高达50G.

  11月底有消息称,Google将推出网络存储服务,允许用户将本地计算机中的文件存储在Google的服务器上.该服务为免费提供,但如果付费,用户可获得更大的存储空间.

  对此,iSuppli高级分析师Krishna Chander认为,与希捷等硬盘制造商相比,提供虚拟硬盘服务的利润更加可观.

  对用户而言,该服务是十分实用的;对Google而言,也是极具诱惑力的.

  目前,雅虎和微软等科技也都提供了网络存储服务,但大部分无法满足企业个人的需求.而且,存储空间也只有5G左右.但Chander预计,Google将免费提供高达50G的存储空间.

  通过在存储服务网站上销售广告,Google即可大赚一笔.Chander预计,将有420万用户部署Google的在线存储服务.假设Google每年从每位用户身上获取50美元的广告营收,那么每年的营收就高达2.1亿美元.

  至于Google的成本,Chander表示,每GB的费用约为25美分.Google需要部署210,000TB的存储空间,其成本约为5250万美元.

nofollow标签的使用

bestroi建议说一下nofollow,所以把以前写的一篇转过来。
nofollow是一年多前(好象)由Google领头新创的一个标签属性,目的是尽量减少垃圾链接对搜索引擎的影响。

Matt Cutts说过,这个标签的意义是告诉搜索引擎这个链接不是经过作者自己编辑的,所以这个链接不是一个信任票。搜索引擎看到这个标签就可能减少或完全取消链接的投票权重。
这个标签通常是用在博客的评论或论坛帖子中,因为这些地方是最多垃圾链接出现的地方。现在主流的博客和论坛软件都自动在评论和帖子的链接中加上了这个标签。
另外一个作用是,如果你在网站上卖广告,可以使用这个标签。因为买卖网页广告的初衷应该是流量,而不是PR值或试图影响搜索引擎排名。加上这个标签完全不会影响流量,但是有可能减少对搜索引擎排名的影响。
那么加了这个标签会把链接投票权重和PR传递值降为零吗?这一点是存有一些疑问的。如果我记的不错的话,Google,Yahoo,MSN表示支持这个标签。但是他们真的把这些链接的投票权重降为零吗?并没有肯定。
可以肯定的是,nofollow+博客评论或论坛帖子,这样的链接的投票权重可以忽略。
其他搜索引擎不一定支持这个标签,比如百度。就我观察的情况看,百度很可能不考虑这个标签,因为垃圾链接在百度还是很起作用的。
除了博客或论坛,在使用nofollow时要小心。想象一下,如果一个网站的导出链接都使用了nofollow标签,这显得自然吗?你向读者介绍一些网站,却告诉搜索引擎你不推荐这些网站?不可疑吗?受伤害的是其他人的网站,还是使用这个标签的网站呢?
以前也说过,害怕链接到其他网站是很多站长的一个误区,实际上链接到其他相关网站在很多时候会帮助你本身网站的排名。
但在博客评论和论坛帖子里面的链接就不一样了,这些链接是用户和读者自己加的,而不是网站拥有人或作者加的。在很多情况下,作者也不会去看这些链接去了什么网站。所以对这些网站的质量当然是不知道,并且不应该背书的。
读者如果有感而发,欢迎留评论,也欢迎留下签名链接。但是如果是想留个链接而留评论,那就不必了,不会有什么作用。
作者: Zac 原载: 点石互动搜索引擎优化博客

各大网站域名服务器测评

1、 Sina.com.cn

http://www.dnsstuff.com/tools/dnsreport.ch?domain=sina.com.cn

Parent

INFO NS records at parent serversYour NS records at the parent servers are: ns2.sina.com.cn. [61.172.201.254 ] [TTL=21600] [CN]
ns3.sina.com.cn . [202.108.44.55] [TTL=21600] [CN]
ns1.sina.com.cn. [202.106.184.166] [TTL=21600] [CN]
[These were obtained from cns.cernet.net]

NS INFO Nameservers versions Your nameservers have the following versions: 61.172.201.254: No version info available (refused).
202.108.44.55: No version info available (refused).
202.106.184.166: No version info available (refused).

SOA

WARN SOA Serial NumberWARNING: Your SOA serial number is: 5. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where ‘nn’ is the revision. For example, if you are making the 3rd change on 02 May 2006, you would use 2006050203. This number must be incremented every time you make a DNS change.

WARN SOA MINIMUM TTL valueWARNING: Your SOA MINIMUM TTL is : 600 seconds. This seems low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.

规范等级:中

Sina.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=sina.com

Parent

INFO NS records at parent serversYour NS records at the parent servers are: ns1.sina.com.cn. [ 202.106.184.166 (NO GLUE)] [CN]
ns2.sina.com.cn. [61.172.201.254 (NO GLUE)] [CN]
ns3.sina.com.cn. [202.108.44.55 (NO GLUE)] [CN]
[These were obtained from l.gtld-servers.net]

WARN Glue at parent nameservers

WARNING. The parent servers (I checked with l.gtld-servers.net.) are not providing glue for all your nameservers. This means that they are supplying the NS records ( host.example.com), but not supplying the A records (192.0.2.53), which can cause slightly slower connections, and may cause incompatibilities with some non-RFC-compliant programs. This is perfectly acceptable behavior per the RFCs. This will usually occur if your DNS servers are not in the same TLD as your domain (for example, a DNS server of ” ns1.example.org” for the domain “example.com“). In this case, you can speed up the connections slightly by having NS records that are in the same TLD as your domain.

NS

WARN Nameservers on separate class C’s

WARNING: We cannot test to see if your nameservers are all on the same Class C (technically, /24) range, because the root servers are not sending glue. We plan to add such a test later, but today you will have to manually check to make sure that they are on separate Class C ranges. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location.

INFO Nameservers versionsYour nameservers have the following versions: 202.106.184.166: No version info available (refused).
61.172.201.254 : No version info available (refused).
202.108.44.55: No version info available (refused).

WARN Nameservers on separate class C’s

WARNING: We cannot test to see if your nameservers are all on the same Class C (technically, /24) range, because the root servers are not sending glue. We plan to add such a test later, but today you will have to manually check to make sure that they are on separate Class C ranges. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location.

SOA WARN SOA MNAME Check

WARNING: Your SOA (Start of Authority) record states that your master (primary) name server is: sina.com. . However, that server is not listed at the parent servers as one of your NS records! This is probably legal, but you should be sure that you know what you are doing.

WARN SOA REFRESH value

WARNING: Your SOA REFRESH interval is : 900 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.

WARN SOA MINIMUM TTL value

WARNING: Your SOA MINIMUM TTL is : 300 seconds. This seems low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.

规范等级:低

2、 sohu.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=sohu.com

Parent

INFONS records at parent serversYour NS records at the parent servers are:dns.sohu.com. [61.135.131.86] [TTL=172800] [CN]
ns1.sohu.com. [61.135.131.1] [TTL=172800] [CN]
ns3.sohu.com. [220.181.26.168] [TTL=172800] [CN]
[These were obtained from a.gtld-servers.net]

NS

WARN Single Point of Failure

WARNING: Although you have at least 2 NS records, and they appear to point to different physical servers, it appears that they block the ICMP packets used as part of our test, which means that they may share the same firewall. If they share the same firewall, this results in a single point of failure, which could cause all your DNS servers to be unreachable.

INFO Nameservers versionsYour nameservers have the following versions:61.135.131.86: ” ”
61.135.131.1: ” ”
220.181.26.168: ” ”

SOA

FAILSOA MINIMUM TTL value

WARNING: Your SOA MINIMUM TTL is : 60 seconds. This seems very low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.

规范等级:高

3163.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=163.com

Parent

INFO NS records at parent serversYour NS records at the parent servers are:ns.nease.net. [202.106.185.75] [TTL=172800] [CN]
ns3.nease.net. [220.181.28.3] [TTL=172800] [CN]
[These were obtained from a.gtld-servers.net ]

NS

INFO Nameservers versions Your nameservers have the following versions: 202.106.185.75: “9.2.3”
220.181.28.3: “9.2.3”

SOA

FAILNS agreement on SOA Serial #

ERROR: Your nameservers disagree as to which version of your DNS is the latest (20011937 versus 20011938). This is OK if you have just made a change recently, and your secondary DNS servers haven’t yet received the new information from the master. I will continue the report, assuming that 20011938 is the correct serial #. The serial numbers reported by each DNS server are:
202.106.185.75: 20011938
220.181.28.3: 20011937

WARN SOA Serial Number

WARNING: Your SOA serial number is: 20011938. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where ‘nn’ is the revision. For example, if you are making the 3rd change on 02 May 2006, you would use 2006050203. This number must be incremented every time you make a DNS change.

规范等级:中

nease.net

http://www.dnsstuff.com/tools/dnsreport.ch?domain=nease.net

Parent

INFO NS records at parent serversYour NS records at the parent servers are: ns.nease.net. [202.106.185.75] [TTL=172800] [CN]
ns3.nease.net. [220.181.28.3] [TTL=172800] [CN]
[These were obtained from j.gtld-servers.net]

NS

INFO Nameservers versions Your nameservers have the following versions: 202.106.185.75: “9.2.3”
220.181.28.3: “9.2.3”

SOA

WARN SOA Serial Number

WARNING: Your SOA serial number is: 991160. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where ‘nn’ is the revision. For example, if you are making the 3rd change on 02 May 2006, you would use 2006050203. This number must be incremented every time you make a DNS change.

WARN SOA EXPIRE value

WARNING: Your SOA EXPIRE time is : 3600000 seconds. This seems a bit high. You should consider decreasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.

规范等级:中

4、 tom.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=tom.com

Parent

INFO NS records at parent serversYour NS records at the parent servers are: brown.hutchcity.com. [202.45.84.67] [TTL=172800] [HK]
edns.wyith.net. [202.181.240.44] [TTL=172800] [HK]
ns1.tom.com. [61.135.159.46] [TTL=172800] [CN]
ns2.tom.com. [61.135.159.47] [TTL=172800] [CN]
[These were obtained from f.gtld-servers.net ]

NS

FAILOpen DNS servers

ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn’t happen). This can cause an excessive load on your DNS server. Also, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Also, the bad guys could use your DNS server as part of an attack, by forging their IP address. Problem record(s) are: Server 202.45.84.67 reports that it will do recursive lookups. [ test] Server 202.181.240.44 reports that it will do recursive lookups. [ test] Server 61.135.159.46 reports that it will do recursive lookups. [ test] Server 61.135.159.47 reports that it will do recursive lookups. [test] See this page for info on closing open DNS servers.

FAIL Lame nameservers

ERROR: You have one or more lame nameservers. These are nameservers that do NOT answer authoritatively for your domain. This is bad; for example, these nameservers may never get updated. The following nameservers are lame:
202.45.84.67

FAIL Missing nameservers 2

ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are:
brown.hutchcity.com.
edns.wyith.net.

WARN All nameservers report identical NS records

WARNING: Your nameservers report somewhat different answers for your NS records (varying TTL, for example).

INFO Nameservers versions Your nameservers have the following versions: 202.45.84.67: “8.3.4-REL”
202.181.240.44: “4.9.6-REL”

61.135.159.46: “TOM.COM DNS Server 2.00″
61.135.159.47 : “TOM.COM DNS Server 2.00″

规范等级:低

5qq.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=qq.com

Parent

INFO NS records at parent serversYour NS records at the parent servers are:dns1.imok.net. [219.133.40.202] [TTL=172800] [CN]
dns2.imok.net. [61.152.100.5] [TTL=172800] [CN]
[These were obtained from e.gtld-servers.net ]

NS

WARN Single Point of Failure

WARNING: Although you have at least 2 NS records, there is a chance that they may both point to the same server (one of our two tests shows them being different, the other is unsure; it appears that there are one or more firewall(s) that intercept and alter DNS packets (some versions of Linux reportedly have a built-in firewall that does this, too)), which would result in a single point of failure. You are required to have at least 2 nameservers per RFC 1035 section 2.2.

INFO Nameservers versions Your nameservers have the following versions: 219.133.40.202: “9.3.2”
61.152.100.5: “9.3.0rc4”

SOA

WARN SOA MNAME Check

WARNING: Your SOA (Start of Authority) record states that your master (primary) name server is: qq.com.. However, that server is not listed at the parent servers as one of your NS records! This is probably legal, but you should be sure that you know what you are doing.

WARN SOA REFRESH value

WARNING: Your SOA REFRESH interval is : 300 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.

WARN SOA EXPIRE value

WARNING: Your SOA EXPIRE time is : 86400 seconds. This seems a bit low. You should consider increasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.

规范等级:低

Imok.net

http://www.dnsstuff.com/tools/dnsreport.ch?domain=imok.net

Parent

INFO NS records at parent serversYour NS records at the parent servers are:dns1.imok.net. [219.133.40.202] [TTL=172800] [CN]
dns2.imok.net. [61.152.100.5] [TTL=172800] [CN]
[These were obtained from j.gtld-servers.net ]

NS

WARN Single Point of Failure

WARNING: Although you have at least 2 NS records, there is a chance that they may both point to the same server (one of our two tests shows them being different, the other is unsure; it appears that there are one or more firewall(s) that intercept and alter DNS packets (some versions of Linux reportedly have a built-in firewall that does this, too)), which would result in a single point of failure. You are required to have at least 2 nameservers per RFC 1035 section 2.2.

INFO Nameservers versions Your nameservers have the following versions: 219.133.40.202: “9.3.2”
61.152.100.5: “9.3.0rc4”

SOA

WARN SOA MNAME Check

WARNING: Your SOA (Start of Authority) record states that your master (primary) name server is: imok.net. . However, that server is not listed at the parent servers as one of your NS records! This is probably legal, but you should be sure that you know what you are doing.

WARN SOA REFRESH value

WARNING: Your SOA REFRESH interval is : 360 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.

WARN SOA EXPIRE value

WARNING: Your SOA EXPIRE time is : 3600000 seconds. This seems a bit high. You should consider decreasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.

规范等级:低

6、 baidu.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=baidu.com

Parent

INFONS records at parent serversYour NS records at the parent servers are:dns.baidu.com. [202.108.250.228] [TTL=172800] [CN]
ns2.baidu.com. [202.108.249.147] [TTL=172800] [CN]
ns3.baidu.com. [220.181.27.61] [TTL=172800] [CN]
ns4.baidu.com. [220.181.27.62] [TTL=172800] [CN]
[These were obtained from m.gtld-servers.net]

NS

FAIL Missing (stealth) nameservers

FAIL: You have one or more missing (stealth) nameservers. The following nameserver(s) are listed (at your nameservers) as nameservers for your domain, but are not listed at the parent nameservers (therefore, they may or may not get used, depending on whether your DNS servers return them in the authority section for other requests, per RFC2181 5.4.1). You need to make sure that these stealth nameservers are working; if they are not responding, you may have serious problems! The DNS Report will not query these servers, so you need to be very careful that they are working properly. ns1.baidu.com.
This is listed as an ERROR because there are some cases where nasty problems can occur (if the TTLs vary from the NS records at the root servers and the NS records point to your own domain, for example).

WARN TCP Allowed

WARNING: One or more of your DNS servers does not accept TCP connections. Although rarely used, TCP connections are occasionally used instead of UDP connections. When firewalls block the TCP DNS connections, it can cause hard-to-diagnose problems. The problem servers are: 202.108.249.147: Error [No response to TCP packets].

220.181.27.61: Error [No response to TCP packets]. 220.181.27.62: Error [No response to TCP packets].

WARN Single Point of Failure

WARNING: Although you have at least 2 NS records, there is a chance that they may both point to the same server (one of our two tests shows them being different, the other is unsure; it appears that there are one or more firewall(s) that intercept and alter DNS packets (some versions of Linux reportedly have a built-in firewall that does this, too)), which would result in a single point of failure. You are required to have at least 2 nameservers per RFC 1035 section 2.2.

INFO Nameservers versions Your nameservers have the following versions: 202.108.250.228: “diy by bind”
202.108.249.147: “9.2.1 ”
220.181.27.61: “9.2.1”
220.181.27.62: “9.2.1”

FAIL Stealth NS record leakage

Your DNS servers leak stealth information in non-NS requests:
Stealth nameservers are leaked [ns1.baidu.com.]!
This can cause some serious problems (especially if there is a TTL discrepancy). If you must have stealth NS records (NS records listed at the authoritative DNS servers, but not the parent DNS servers), you should make sure that your DNS server does not leak the stealth NS records in response to other queries.

SOA

WARN SOA REFRESH value

WARNING: Your SOA REFRESH interval is : 300 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.

WARN SOA EXPIRE value

WARNING: Your SOA EXPIRE time is : 2592000 seconds. This seems a bit high. You should consider decreasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.

规范等级:中

7、 google.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=google.com

Parent

INFO NS records at parent servers Your NS records at the parent servers are: ns1.google.com. [216.239.32.10] [TTL=172800] [US]
ns2.google.com. [216.239.34.10 ] [TTL=172800] [US]
ns3.google.com. [ 216.239.36.10] [TTL=172800] [US]
ns4.google.com . [216.239.38.10] [TTL=172800] [US]
[These were obtained from k.gtld-servers.net]

NS

INFO Nameservers versions Your nameservers have the following versions: 216.239.32.10: No version info available (refused).
216.239.34.10: No version info available (refused).
216.239.36.10: No version info available (refused).
216.239.38.10: No version info available (refused).

SOA

FAILSOA MINIMUM TTL value

WARNING: Your SOA MINIMUM TTL is : 60 seconds. This seems very low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.

规范等级:中

http://blog.pcstars.tk/2007/11/blog-post_09.html

10月份西联汇款取款指南

作者 廖溪 – AdSense 支持小组

各位 Google AdSense 发布商您好,如果10月份您选择的付款方式为西联汇款,现在开始您就可以去领取您的西联汇款的收入了!

领取西联汇款步骤如下:

1.登录您的 Google AdSense 账户,点击付款页面,如果显示10月份”付款已签发”的话,点击此链接边上的”付款细节”。

2.在付款细节页面,请您打印或抄录如下信息并随身携带:
* 您的付款监控码(MTCN),此号码为10位数号码。
* 您的详细的付款金额,详细到美分,如 123.45美元。
* 发汇人的详细信息:
发汇人: Google.Inc
发汇人地址:1600 Amphitheatre Parkway,Mountain View, CA 94043 , USA
3.随身携带您的有效身份证件,如身份证,驾照,护照。

4.首先选择离您最近的西联代理机构,您可以访问 http://www.payment-solutions.com/agent.asp ,请提交地址并从 “Product”(产品) 下拉框中选择 “Quick Cash”(快汇)。您随即会看到距您最近的西联代理机构清单。如果您没有找到的话,请致电西联汇款的免费服务热线 8008208668 进行咨询。

5.前往您最近的西联代理机构或分理处领取付款,如果您付款有任何问题的话,请致电西联汇款的免费服务热线 8008208668 寻求帮助,我们已经跟西联汇款中国部门提前联系相关事宜,相信他们可以给您提供帮助。

6.如果您的拼音收款人姓名不是我们介绍过的标准格式(如 Liao xi,Zhang xiaoming), 姓在前,名在后,姓名中间有空格,请 点击此处 申请更改您的拼音收款人姓名,请注意,您无需为使用西联汇款更改您的中文收款人姓名。

7.如果您在10月 25 日到 10 月 30 日之间更改过您的付款方式,您的付款很有可能以您更改后的方式发出,您可能要稍晚才会在账户中看到更新,感谢您的耐心等待。

对于此次付款给大家带来的不便,我们感到十分抱歉。我们会不断改进我们的付款流程,让您更快更方便地拿到付款。非常感谢各位发布商一直以来对我们的信任和支持。

Google Adsense定义下的成人内容

今天,Google Adsense的官方博客详细阐述了关于成人内容的定义规则,详细解释了哪些网站算是成人内容,是不能放Google Adsense广告的,如果包含成人内容的网站投放Adsense广告,那么Google会停止投放广告甚至停用发布商的账户。  根据Google AdSense的计划政策,发布商的网站内容“不得包含色情或成人内容”,因此,色情网站是不能投放Google Adsense广告的,根据Google这次的解释,成人内容实际指的是“少儿不宜内容”,也就是说不适合少儿观看的内容。其中包括:

1.色情内容以及有色情倾向文字描写的内容,如色情图片、视频、以及色情、成人小说等;

2.有成人或色情引导性的图片或视频,如“偷拍”“走光”“激情图片”等;

3.具有猥亵性或不健康倾向的内容,如“美腿丝袜”“高跟丝袜”等内容;

4.成人用品;

5.对于性教育方面的内容,只有完全教育性的内容才能投放广告,任何成人擦边性质的内容,如成人倾向的描写以及成人图片都属于少儿不宜内容;

6.网页上在投放成人广告,就不能同时投放 AdSense 广告。

实际上,中国目前不少门户网站就包含成人内容,比如某某门户网站的女性频道和社会新闻频道,打开后映入你眼帘的大多都是美女等等不健康的内容,Google对于成人内容的定义似乎执行的并不太好,我举个例子,中国的老牌流氓网站:中国电信互联星空会通过各种手段将用户输错地址后带入互联星空的网站,相信内容参见我以前的报道,这个网站就投放过AdSense广告,而我给出当时的截图来看,这样的内容显然已经符合Google Adsense关于“成人内容”的定义,不过中国电信似乎依然堂而皇之的挂着Google Adsense,实在令人不解。

G.cn

上 Google(谷歌)还有捷径?没错,今天,我们很兴奋地告诉大家谷歌最简网址 G.cn 上线。如果你愿意叫它”快捷键”也无妨。

再老资格的网民也有输入网址时键入”wwww”的时候,再忠诚的谷歌粉丝也难免激动中会生造出”gooogle”来,更何况那些对英语、对谷歌不那么熟悉的朋友,非逼着大家把 Google 这六个字母想记清楚打正确还真是不太”贴心”,是两个”o“还是三个”o”?是”g”在前还是”l”在前?

现在你再也不用全神贯注地输入 www.google.cn 这么长而且比较难记的 URL 了。只要在浏览器中输入 G.cn 就能登陆谷歌的主页,开始您的搜索之旅。这是我们为中国用户量身打造的谷歌捷径。想想看,这应该是世界上最短的域名之一了,也是谷歌自己最短的域名吧。

Gmail即将升级 部分第三方辅助工具将无法使用

Google公司的一名发言人对国外媒体表示,目前,Google公司的工程师正在对Gmail的JavaScript代码进行更新,更新之后的软件将会提供”更快和更灵活的服务”.
Gmail服务的工程师丹·普皮斯介绍说,Google公司将很快在美国英文版中进行Gmail的升级,几周之后,Google将会对其他语言的版本进行升级.
普皮斯在一篇博客文章中表示,在经过升级之后,Gmail可以提供许多在2004年发布是不敢想象的功能.他说:”在过去三年半时间里,我们已经推出了一些很酷的功能.在这期间,我们在开发大型网络应用软件方面学到了很多东西,知道了如何突破网络浏览器的限制.”
閱讀全文

FeedBurner开始集成AdSense

据FeedBurner官方博客报道,FeedBurner在11月31日的万圣节宣布,FeedBurner的广告已经整合了Google AdSense,大家可以在FeedBurner中展示自己的AdSense了。

这项新的集成将会在你的网站和博客中显示和内容相关的AdSense广告,不过需要注意到是,针对Feeds的AdSense选项此时并没有打开,如果你选择激活Adsense服务,那么你可以在你的Blog页面上显示300×250或468×60的文字或图片广告,当你已经安装了必要的代码后,该广告将出现在文章页面的第一项这中。

用户不一定必须是FeedBurner Ad Network成员也可以使用这项功能,使用的时候请务必遵守Google Adsense的计划政策,确保你的网站符合显示AdSense广告的条件。如果你已经是FeedBurner Ad Network成员,并且也配置了在你的网站上显示广告,那么AdSense广告将会在没有FeedBurner Ad Network广告的时候显示。

使用FeedBurner的AdSense的方法是,选择你的Feed,进入Monetize页签,然后输入你的AdSense帐号或者新建一个AdSense账号,然后在网页上加入FeedBurner的代码,就可以展示AdSense广告了。

中国的用户就不用配置了,因为FeedBurner的feeds子域名无法访问,因此这些广告代码加到你的网站上去也什么都无法显示,获得不了任何收入的,不过大家可以期待一下针对Feeds的广告,因为目前在线阅读器访问FeedBurner还是没有问题的。

发布商经验谈 – 三次优化让我的广告点击率从0.5%提高到3.0%

作者 冯英健 – AdSense 发布商

如果你已经是 Google AdSense 内容发布商,如果希望自己的网站获得更高的收入,非常有必要深入了解 Google 的优化建议。在 Google AdSense 的在线支持页面也提供了相当多的内容可以参考,这里根据我自己对个人网站 Google 广告进行优化的体会,给大家介绍一些个人建议,但愿对其他网站站长有所帮助。

我的个人网站从2004年10月底 Google AdSense 支持中文网站开始就申请成为 Google 内容发布商,不过在早期广告的点击率很低,通常只有0.5%左右,在1年多的时间内,经过三次简单的优化,目前的广告点记录平均达到3.0%,AdSense 点击广告的佣金收入也从最初每个月的30多美元增加到目前的2000美元以上(其中包括后来才提供的 Google 产品推介收入)。取得这样的效果当然也是因为网站的访问量在不断增长,不过网站广告的优化还是发挥了决定性的作用。

为什么我的网站广告点击率只有0.5%?

在我的网站开始投放 Google AdSense 内容关联广告的最初几个月内,我注意到广告的平均点击率大约0.5%,有些渠道甚至低至0.1%,起初对此并未多想,以为这种文字广告点击率不高是正常的现象。一个偶然的机会,看到一个介绍 Google AdSense 的成功案例中,广告的点击率是1.5%,这才第一次对自己网站的网站广告模式产生了“优化”的念头。

第一批投放的广告,实际上没有任何优化的意识,也没有对用户获取信息的行为进行分析,只是根据原来网页模板的布局,将合适的广告代码添加进去而已。第一次所做的优化也很简单,只是根据自定义的广告渠道统计数据,将点击率过低的广告去掉,如网页顶部468×60的广告单元、网页模版右侧160×600的摩天大楼广告单元等,同时将728×90的横幅广告放置到网页的主导航条下面。

经过这些改变之后,在很短的时间内,我的平均广告点击率也达到了1.2%,我当时曾经对这一效果相当满意。不过实际上这仍然不是最好的广告投放模式。

第二次优化:广告点击率提升到1.8%

在浏览一些国外网站时,发现其中的 AdSense 广告通常看起来没有边框,好像与正文“融合”在一起,而且广告文字、网址等字体颜色也可以自行定义。于是认真查看了 Google AdSense 设置中的最新功能,原来可以通过“调色板”来进一步优化广告的展示效果。我迫不及待地把所有广告都设置为无边框,并且使背景颜色与网页看起来更加协调。经过这次优化,广告点击率提升到1.8%,广告收入也达到每月400美元以上。

由于看到了 Google AdSense 佣金的增长,进一步提高了通过个人网站赚取广告佣金的兴趣,在这期间的网站运营中,我持续增加了大量原创内容,网站访问量也比一年前增加了一倍以上,这些原创内容也为日后获得更多的收入奠定了基础。

第三次优化:广告点击率达到3.0%

对于1.8%的点击率和每月400美元的收入,我认为这已经是相当不错的效果了,因为在当时,传统的BANNER广告点击率通常在0.5%以下,而对于当时日访问量仅有30000多PV的个人网站,如果通过其他广告联盟获得的月收入通常不到1000元人民币。

不过此后不久,Google 给我提供了更加详尽的 AdSense 优化建议,根据这些建议,我在网页正文内容的左上方放置了300×250的中等矩形广告,并且利用调色版采用了“融合”的方式,使得广告更受关注。另外,在网页顶部等改为图片格式的 Google 产品推介广告。通过这次调整,平均广告点击率达到3.0%,Google 产品推介广告点击率也达到1.0%以上,这样的综合效果使得网站的收入达到较好的水平(相对于同等规模的网站而言)。

通过自己将近3年的 AdSense 广告投放经验,可以简单归纳为两点:第一,要选择合适的广告格式和广告展示位置;第二,也是最重要的一点,提高 AdSense 广告佣金收入的根本是网站运营问题,是要用心运营自己的网站,以高质量的内容赢得用户。

百度将在美国欧洲推搜索服务 迎击Google雅虎

据外国媒体10月18日报道,中国最受欢迎的互联网搜索网站百度司宣布,它打算在美国和欧洲推出网络服务,以在国外市场迎击比它强大的竞争对手谷歌和雅虎公司。百度董事长兼CEO李彦宏今年在韩国首都首尔接受一个采访时说:”我们有全球化的志愿,最终我们会扩展到所有国家,这其中包括美国和欧洲市场。” 李彦宏在首尔正在出席一个经济论坛,他说:”我们需要为每个市场提供略微不同的产品。这就是我们一步步地从中国到日本再到其它国家的原因。“但是他表示向全球扩展业务时,并没有透露进程时间表。

百度凭借其在中国位于谷歌之上的领导地位,提高利润并且将股价推进到其2005年8月份上市时价位的11倍。李彦宏称百度打算今年底在日本推出它的日语搜索服务,这也是该公司第一次走出国门以获得国外市场。百度第二季度净利润与一年前同期比翻番至1.419亿元(1890万美元)。谷歌7月份公布的财报显示,其第二季度实现利润9.25亿美元。

  据市场研究公司Analysys International称,第二季度百度在中国搜索市场的市场份额为58%,而它的竞争对手谷歌只有23%。雅虎位列第三,其第二季度中国搜索市场份额为11.6%。百度定在10月25日纳斯达克闭市后公布其第三季度财报。

细说 AdSense 政策 – 什么是“版权材料”

作者 AdSense 政策专员 – AdSense 政策小组

在前面的“细说 AdSense 政策”系列中,我们陆续介绍了一些常见的政策问题。今天,我们再向大家介绍一下另一个非常常见的政策问题 – 版权材料问题。

顾名思义,“版权材料”就是指在未经版权所有者授权的情况下使用的材料,包括电影,电视剧,电视节目,音乐和歌曲(mp3,铃声,flash),漫画,书籍,软件等。

如果您网站上使用的这些材料有明确的版权所有人(公司或个人),而您在没有该版权所有人的正式授权(具有法律效力的授权书)的情况下使用这些材料,您的网站内容就属于版权材料,就违反了我们的计划政策。

需要强调的是,您网站上的版权声明(例如“本站所有内容均搜集与网络,如果侵犯了您的版权请立即通知我们,我们会立即删除”)是没有任何法律效力的。如果您没有版权所有人的授权,仍然是版权材料,仍然违反了我们的计划政策。

下面我们就举几个版权材料的具体例子:
1. 电影或电视在线观看或下载网站,如果没有出版公司的正式授权,这些内容就属于版权材料。
2. 音乐在线视听或下载网站,或使用歌曲做手机铃声下载的网站,如果没有出版公司的正式授权,就属于版权材料。
3. 漫画网站,如果使用的漫画有明确的版权所有人,并且没有版权所有人的正式授权,就属于版权材料。
4. 在线书籍或小说网站,如果该书籍或小说已经正式发表并有明确的版权所有人,如果没有版权所有人的授权,就属于版权材料。
5. 软件下载网站,如果软件有明确的版权所有人和发行公司,在未经版权所有人授权情况下提供的下载以及任何其他形式 – 如破解版、绿色版、汉化版等都属于版权材料。

另外,有些发布商来信说他的网站服务器上并没有这些材料,并不提供这些材料的直接下载,而只是提供下载链接,问算不算版权材料。我们的回答是:这样的网站内容仍然是版权材料,不符合我们的计划政策。我们不允许发布商直接或间接利用非法版权材料赚取 AdSense广告收益。

请注意,AdSense 所有的广告都不可以展示在版权材料的网站上,包括 AdSense for Content,AdSense for Search,移动广告和推介。同时,发布商也不可以在版权材料的网页上做导向放有广告或推介页面的链接、图片或flash,这同样是违反我们政策的。

如果我们发现含有大量版权材料的网站在投放 AdSense 广告,我们会停止广告的展示,并向发布商发出警告。对于严重违反政策的发布商,我们会停用账户,该发布商将再也不能参加 AdSense。

说这么多,就是希望让发布商对什么是版权材料有一个清楚的了解,帮助大家保证自己的网站符合我们的政策。我们希望广大发布商都能遵守我们的政策,同时,如果发现了违反政策的行为能及时通知我们,与我们一起维护 AdSense 网络的质量。非常感谢大家!

Google PR更新

早上起来一看Google Toolbar 上面的绿块,很多站的PR都已经刷新,这是很多SEOer期待已久的事情。

随便看了一些站,观察了一些5月份后增加的栏目和文章,PR由原来的0升到2-3不等,不过有点意外的是有几个8月份注册的域名PR也都上升到3了,也有部分由3降低至2,当然,本次更新来的比较突然,
仿佛就在一夜之间,关于还会不会有什么新的变化或者调整,我们继续关注中,赶快Check一下你的站点吧!

作者: 枫林&SEO博客

gmail已经支持IMAP

Gmail开始支持IMAP协议,相比起POP协议,其最大的优势在于可以减少许多重复的下载以及保持各个客户端间的同步,比如在基于IMAP协议的客户端上删除某封邮件后,Web Gmail中该邮件也会被删除

目前支持POP3的免费信箱很多,但是几乎找不到支持IMAP的免费信箱,这主要是因为IMAP的特性导致的,因为IMAP会占用比POP3更多的服务 器和带宽资源,务必导致服务器和带宽将要投入更多资源,因此目前IMAP几乎都是收费的服务,而Google得Gmail提供免费的IMAP之后,估计会 对目前收费IMAP邮件服务造成严重打击。