<<< 550-5.7.25 [x.x.x.x] The IP address sending this message does not have a
<<< 550-5.7.25 PTR record setup, or the corresponding forward DNS entry does not
<<< 550-5.7.25 match the sending IP. As a policy, Gmail does not accept messages
<<< 550-5.7.25 from IPs with missing PTR records. For more information, go to
<<< 550-5.7.25 https://support.google.com/a?p=sender-guidelines-ip
<<< 550-5.7.25 To learn more about Gmail requirements for bulk senders, visit
<<< 550 5.7.25 https://support.google.com/a?p=sender-guidelines. af79cd13be357-7cd1ca4215fsi331230985a.612 - gsmtp
554 5.0.0 Service unavailable
My reverse name (which I only sorta control, I have to ask my upstream providor to fix this for me, and it may take him a day or so to do it), is "smtp.vintners.net".
I used to have a setup with "generic" names at my upstream provider (NetSol), namely "ns5" and "ns6", with these of course having a matching correct "A" record. The idea was that if I have to change machines out, I merely change this IP and nothing else changes - the machine can have a different name, it just needs to take over these seervices.
No - will not work. Apparently when comcast/google/etc. check for name match, they check that the name at the upstream DNS provider (NetSol), matches the reverse lookup name. Use ZONEMASTER.COM lookup to help you figure this out.
So all of these must match:
cd /etc/namedbnamed-checkzone <your domain name> primary/<your domain name>.hostsnamed-checkconf -z | more
Unable to fetch DNSKEY set '.': timed out
in /var/log/messages soon after bootup. Google search
said to add "-4" to named_flags in rc.conf,
assuming it was related to starting up ipv6 even though I have no ipv6
interface defined. Tried this, nope, no difference.
Messed with adding dnssec-enable no;
to named.conf, nope just got an error about that being
obsolete.
Tried adding managed-keys-directory "/etc/namedb/";.
Also had to do a touch managed-keys.bind. It did get rid
of the previous error, but now I'm getting "unable to synchronize
managed keys" and "failed to initialize managed-keys". I guess that's
progress, but I'm not going to pursue at this time. Removed
directives and file.
pkg update recently, it ended with a comment
that Bind9 was deprecated and needs to be upgraded soon. I did:service named stoppkg delete bin914pkg install bin916service named start/usr/local/etc/rc.d/named starttail /var/log/messagesnamed[27147]: could not get query source dispatcher (63.226.250.177#53) named[27147]: loading configuration: address in use named[27147]: exiting (due to fatal error)I checked for old named process running with
ps ax | grep
named -- nope. Tried netstat -Lan | grep 53 --
still nope. Rebooted just in case there was something still silently
hanging in there, nope./etc/namedb/named.conf and commented out the line:
query-source address 63.226.250.177 port 53;
This fixed it. I don't have any explanation, this is the address it
should be using. I've checked from outside the domain, and the server
is answering -- no explanation...named[537]: DNS format error from a.b.c.d#53 resolving some.bogus.domainname/A: too many questions named[537]: DNS format error from a.b.c.d#53 resolving some.bogus.domainname/AAAA: non-improving referral named[537]: DNS format error from a.b.c.d#53 resolving some.bogus.domainname/AAAA: Name bogus.domainname (SOA) not subdomain of zone some.bogus.domainname -- invalid responseThese may be real issues, but they're not my issues -- they are not under my control, I cannot fix them (their sysadmins are idiots or oblivious).
Some Google searching and reading man pages tells me to add:
logging {
category lame-servers { null; };
category edns-disabled { null; };
category resolver { null; };
};
to the /etc/named.conf.options file. If you
don't already have this file (I didn't), you can scrounge a
copy from the Ports tree
I think I finally got rid of that dang blasted "working directory is not writable" error...
chown bind /var/named/etc/namedb