bind 9.16.28 vrs. 9.18.2 (on freebsd) resolving foryoudecor.com
Michał Kępień
michal at isc.org
Wed May 11 10:30:49 UTC 2022
> we observed a strange behaviour for the domain foryoudecor.com,
> when trying to resolve it using bind 9.18.2, using
>
> dig -t mx foryoudecor.com
>
> The bind log for 9.18.2 says:
>
> May 11 12:00:14 ns named[96774]: fetch: foryoudecor.com/MX
> May 11 12:00:14 ns named[96774]: DNS format error from 61.129.70.40#53 resolving foryoudecor.com/MX for 193.105.105.1#27259: server sent FORMERR
> May 11 12:00:14 ns named[96774]: client @0x803bdcd60 193.105.105.1#27259 (foryoudecor.com): query failed (FORMERR) for foryoudecor.com/IN/MX at query.c:7657
>
> so the domain was not resolvable.
>
> bind 9.16.28 resolves the MX for this domain.
The servers authoritative for foryoudecor.com return broken responses
(FORMERR + OPT) to EDNS queries. This is a violation of RFC 6891
section 7.
BIND 9.18+ is more strict in processing such responses than the older
versions. This is pointed out in the release notes for BIND 9.18.0: [1]
> - Previously, ``named`` accepted FORMERR responses both with and without
> an OPT record, as an indication that a given server did not support
> EDNS. To implement full compliance with :rfc:`6891`, only FORMERR
> responses without an OPT record are now accepted. This intentionally
> breaks communication with servers that do not support EDNS and that
> incorrectly echo back the query message with the RCODE field set to
> FORMERR and the QR bit set to 1. :gl:`#2249`
If you need a workaround for this particular domain, use the "server"
clause in named.conf to disable EDNS for its authoritative servers.
[1] https://bind9.readthedocs.io/en/v9_18_0/notes.html#notes-for-bind-9-18-0
--
Best regards,
Michał Kępień
More information about the bind-users
mailing list