Currently, if you do a lookup of sia2.howitts.co.uk and come up with an answer of 62.30.63.92, then if you do a reverse lookup of 62.30.63.92, you will get sia2.howitts.co.uk. This is incorrect as there is no PTR record for 62.30.63.92 so you should get a null response.
In the email RFCs it is mandatory that a sending server has a PTR record for their sending IP. (The RFC does not require that the PTR matches the A record, just that it exists). It means that it is a valid anti-spam defence to block all mail from IP’s without a PTR record. Postfix has a parameter for this reject_unknown_reverse_client_hostname. Synthesizing PTR records as adam:ONE does defeats this anti-spam measure.
I have tried a forwarder rule for in-addr.arpa to another DNS server, but adam:ONE’s PTR synthesis still happens and takes priority - and the server is already assigned to the Unfiltered policy.
Please can we have a mechanism to disable this PTR synthesis, perhaps as a rule which can be assigned to different policies.
@NickH I think you’re right on this, I have created an internal issue for engineering and will report back here when it has been addressed. Thanks for the detailed description.
If anything, it will be a config switch to change from your described default behaviour which is by design, to facilitate traffic log analysis.
The vast majority of our endpoints and environments don’t run their own mail servers, so default behaviour will remain as is.
As for synthesizing PTR records on the LAN for hosts without a name, this will remain the default:
admin@RT-AC68R-B468:/tmp/home/root# ansr -T PTR -s 192.168.12.1 100.12.168.192.in-addr.arpa
QD | 100.12.168.192.in-addr.arpa as PTR
AN | 100.12.168.192.in-addr.arpa is PTR 192_168_12_100
== | 1 milliseconds
This behaviour can be overridden with the newly-introduced config switch of disable-synthetic-ptr-answers plus service restart and then you can expect this result:
admin@RT-AC68R-B468:/tmp/home/root# ansr -T PTR -s 192.168.12.1 100.12.168.192.in-addr.arpa
QD | 100.12.168.192.in-addr.arpa as PTR
AN | 100.12.168.192.in-addr.arpa is PTR
== | 1 milliseconds
The snapshot release should be available by tomorrow, followed by Rapid Release and Scheduled Release as per their release cycles. For snapshot release deployment, use this on pfSense: /usr/local/bin/adamone-upgrade snapshot
Synthesizing PTR on the LAN may be OK but will diverge from the true PTR record which pfSense can maintain from static leases (and other leases but is a bit dodgy). I’ll have a play with the switch and using a forwarder rule for 17.172.in-addr.arpa to pfSense.
Can disable-synthetic-ptr-answers be placed in /usr/local/etc/adamone/anmuscle.conf? If it can, does it just go like that or does it need something like =true at the end?