我正在pipe理一个有很多位置的networking，并与我的DNS提供商签出的多个供应商合作，为其中一个IP更改PTRlogging，他们回答说：
亲爱的先生，
我们不能修改您提供的IP地址的PTRlogging，因为这些IP地址不由
ZZZZZZZpipe理。您将不得不联系IP地址的提供者来修改PTRlogging。
这是一般性的做法，PTRlogging只能由pipe理IP的ISP公司添加，或者仅仅是这个DNS提供商的做法？
我认为这比mdpc的build议稍微复杂一些。 该信件是真实的：只有被委派给相关的PTR空间块的人才能pipe理该空间中的PTRlogging。
在第二段中，他们假定现任代表是负责PA IP地址空间的人。 这通常是一个安全的假设，因为PTRlogging的总体结构是这样的，它们被分配到与它们所在的/24 IP地址块对应的块中。但是，正如mdpc所指出的， RFC 2317引入了一个机制，基本块。 我曾与那些使用这种机制来控制其子/24块的PTR的组织合作。 但是它需要一个高度可靠的ISP，一个友好而合规的ISP来启动; 根据我的经验，这是不常用的。
您可以自己走DNS树，看看您的PTR空间已经委派给谁，它很可能是您当前的ISP，并且不太可能成为您当前的DNS提供商，除非碰巧是同一个人。 然后，您可以联系他们，要求直接插入PTRlogging，或将您的子部分委派给您或您的代表。
这不一定是真实的，实际上取决于ISP是否要将PTRlogging维护委托给您。
从我记得几年前，使用一个基于RFC的ISP，我就看到了一个适中的复杂过程，这个过程就是支持这个东西的。 我不知道这个RFC已经被广泛使用，甚至被放弃了。
使用另一个ISP，分配给我的任何networking范围我都被允许自己维护反向区域logging。