bind 9.16.28 vrs. 9.18.2 (on freebsd) resolving foryoudecor.com

[Michał Kępień]

> 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ń