@Torsten_Rüger
Again, I have to agree with UFHH01 and I want to give you some additional explanation.
With respect to the "nameservers", note the following.
There is the nameserver that handles the requests to point to your server(s) AND there is the nameserver that handles requests for specific domains.
Each of those separate (master) nameservers has one or more slave nameservers and, for the sake of convenience, we return to this topic later.
The PTR record is a DNS record that associates "domains" with IPs and/or IP blocks (as opposed to the A record, that points domains to IPs, a huge difference).
As such, the PTR record only is relevant for the association of hostnames with specific IP blocks.
A common usage of the PTR record is therefore to be found at the level of hosting providers, that assign various hostnames to IP blocks (and sub-blocks) they have.
In short, the nameserver that handles the requests to point to your server(s) is
- the nameserver that has to include the correct PTR records, appropriate for IPv4 and IPv6,
- the "true" (primary) nameserver, that associates traffic with your server,
- the responsibility of your hosting provider (and sure, they have to set it up properly).
and, in essence, it can be stated that this type of nameserver is barely relevant, in the sense that it is "out of reach".
The A records are present on the nameserver that handles requests for specific domains and this type of nameserver can be present in the form of
- external nameservers, for instance the nameservers of the domain registrar, OR
- local nameservers, as managed by Plesk (or even some other set of nameservers that are managed by you).
In short, traffic intended for specific domains is routed to some IP by means of A records, maintained at external or local nameservers.
With respect to primary and secondary (i.e. master and slave) nameservers (of the type that handle requests for domains) the following.
In general, the before mentioned local and/or external nameservers do not have to contain a PTR record for domains managed.
The only exception is the case in which Plesk functions as a primary nameserver, i.e. a local nameserver.
AND this exception only applies to the domain chosen: the <domain> in ns.<domain>.<tld> has to include a PTR record (and multiple other records).
In your case, you have used and/or have the intention to use Plesk as a primary nameserver.
Note that it requires some thorough knowledge to create a proper setup, in order to have Plesk function as a primary nameserver.
Also note that every primary nameserver has to have a secondary nameserver and this secondary nameserver can NOT be on the same physical server.
Furthermore, note that using an external secondary nameserver will not actually function as a "true" secondary nameserver: the primary nameserver, as setup with Plesk, will not propagate changes in DNS records automatically, unless some appropriate configuration and/or action is taken.
Finally, note that managing nameservers really is work for specialists, with the right equipment, hardware and infrastructure.
In conclusion, it often is not adviceable to manage your own nameserver, i.e. use Plesk as a primary nameserver (of the type that handles requests for domains).
With respect to the alleged typo "?all" the following.
Note that
- "-all" means "Fail": mail is REJECTED (i.e. SPF designates the host as NOT being allowed to send)
- "?all" means "Neutral": mail is ACCEPTED (i.e. SPF designates the host as being allowed to send)
- "~all" means "SoftFail": mail is ACCEPTED and MARKED (i.e. SPF designates the host as NOT being allowed to send, but it is in transition)
AND note that SPF syntax implements a sequential set of rules, meaning that every rule is checked in chronological order of occurrence.
For instance, "spf=v1 a mx ip4:<IP address> ?all" implies that, in chronological order:
- at "a": all A records are tested. If test succeeds, mails are accepted.
- at "mx": all A records for all the MX records are tested in order of priority. If test success, mails are accepted.
- at "ip4:<IP address>: mail related to the <IP address> is accepted.
- at "?all": all other mails are accepted (and not marked)
and, given the chronological order of testing, any test will probably end at the "a" level and, in worst case scenario´s, at "ip4" level.
In essence, the "?all" can do no real harm, since all previous (spf) tests will not allow that a test at the "?all" level occurs, at least in 99,999999% of the cases.
Sure, it is better to use a "~all", but you should not need that in most cases.
However, it is not good to use the strict "-all", since any misconfiguration (server-wide, or even spf configuration) can completely block all mail traffic.
In conclusion, there is not a bug that can be related to Plesk, at least not in your case.
Your issue has to do with either incorrect PTR records or your (primary) nameserver (managed by Plesk) not propagating DNS changes to the secondary nameserver.
If you ask me, you have more than one issue, I am pretty sure that both the "PTR problem" AND the "propagation problem" are occurring in your situation.
In my humble opinion, if you have an external nameserver, I cannot imagine why you would want to setup a local primary nameserver (just completely use external nameservers).
Regards.....
Facebook
Twitter
