Raul Miller wrote:
>
> On Wed, Sep 27, 2000 at 09:12:25AM -0400, Jan Knepper wrote:
> > OK, but what would that mean to the config files?
>
> You'd have to recreate them. djbdns config files are much, much simpler
> than bind's.
>
> Unfortunately, that also means that they're different.
>
> On the positive side, creating all the config files you need for djbdns
> is about as hard as creating the reverse zone files you need for your
> ptr records. On the negative side, you'll have to do a bit more work
> up front, to install djbdns and daemontools. On the positive side,
> you'll be saving yourself a lot of work in the long run.
>
> If you don't want to install djbdns (and there's a mailing list for that:
> [EMAIL PROTECTED]), what you have to do with bind is create
> another zone (or perhaps multiple zones) for your ptr entries, and
> populate it with ptr records. Your bind docs should tell you the details.
>
> [Final aside: ptr records can [but don't have to] give identifying
> information, but the real reason that some won't accept mail from a
> machine without ptr records is that you have to know a little bit about
> how dns works before you set them up. And, lots of spammers don't know
> how about dns. So, basically, they're an acid test that some spammers
> don't pass.]
>
> --
> Raul
Actually, the ISP had to delegate the reverse IP's, or the reverse zone,
and it appears that they have done this as of today, at least partially:
root@frodo:~# dig -x 63.105.9.34
; <<>> DiG 8.2 <<>> -x
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; 34.9.105.63.in-addr.arpa, type = ANY, class = IN
;; ANSWER SECTION:
34.9.105.63.in-addr.arpa. 0S IN CNAME 34.32.9.105.63.in-addr.arpa.
(partial dig results).
However, the CNAME in the answer is invalid:
root@frodo:~# dig any 34.32.9.105.63.in-addr.arpa @auth100.ns.uu.net
; <<>> DiG 8.2 <<>> any 34.32.9.105.63.in-addr.arpa @auth100.ns.uu.net
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;; 34.32.9.105.63.in-addr.arpa, type = ANY, class = IN
;; AUTHORITY SECTION:
32.9.105.63.in-addr.arpa. 6H IN SOA auth100.ns.uu.net.
hostmaster.uu.net. (
(partial dig output).
Still pretty messed up... Maybe they're just preparing to delegate the
zone, but now instead of answering NXDOMAIN for the first PTR record,
they're answering with a CNAME that resolves to NXDOMAIN....
GW
