EmailValidator
EmailValidator copied to clipboard
DNSCheckValidation: Safe way to query AAAA record
Hello, I'm using DNSCheckValidation in production on many sites with great success. Recently I discovered some specific domains that are validated as invalid. Those domains are valid and have correct MX records.
The root cause of problem is that PHP issues "A temporary server error occurred" for AAAA dns_get_record because domain servers returns SERVFAIL for AAAA records. Probably it is not so rare behavior because RFC exists to deal with this issue: https://datatracker.ietf.org/doc/html/rfc4074 - AAAA check should be done separately from A / MX check because AAAA can fail and request for A + AAAA also returns failure.
I found a workaround by overriding in subclass
protected const DNS_RECORD_TYPES_TO_CHECK = DNS_MX + DNS_A + DNS_AAAA;
with
protected const DNS_RECORD_TYPES_TO_CHECK = DNS_MX + DNS_A;
Do you have any ideas how to deal with this issue? Obviously DNSCheckValidation can check MX + A record first and in case of failure do another AAAA lookup.
I was trying to find some way how to make dns_get_record
with DNS_MX + DNS_A + DNS_AAAA
return success but so far I've found nothing.
Testing domain affected by this issue is: sazka.cz See here dns_get_record with and without AAAA record: https://www.tehplayground.com/vlDYL3FrqaPSNIaL
Hi @cuchac , I'm glad you have found usefull the validation. Very detailed issue, thanks. My understanding, from your words, is that this case is common enough to have an RFC while it is also rare enough. I believe DNS validation is not so used.
So, option I see would be something like:
- Transform from
const
to a private property - Add a way to pass "configuration" via a helper type/class or consts, with sensible default to current behaviour to avoid BC breacks
This way it would allow for flexibility in use cases and keep BC.
What do you think? Happy to discuss over a PR ;)
I have the exact same problem. AAAA validation fails because it gets back a SERVFAIL and dns_get_record() returns FALSE, even though an MX record and A record exist.
Perhaps you should not query MX + A + AAAA at the same time. Query just MX, when it does not exist, query A, if that does not exist then finally query AAAA.
The key point is here:
RFC exists to deal with this issue: https://datatracker.ietf.org/doc/html/rfc4074 - AAAA check should be done separately from A / MX check because AAAA can fail and request for A + AAAA also returns failure.
Since a combined lookup for A
+ AAAA
+ MX
can fail with SERVFAIL
(despite valid A
and MX
records existing), the check for AAAA
needs to happen separately.
Thanks @crishoj . Released under 4.0.2