The line in the log refers This would have broken with the BadLock fixes in CVE-2016-2118 back on on Samba 4.4.2

The workaround is "allow dcerpc auth level connect = yes" or more specifically "allow dcerpc auth level connect:dnsserver = yes"

I don't see how this is connected with IP ranges or the other things you are seeing, except to say that the fallback to NTLMSSP appears to be failing, perhaps when Kerberos is successful it works.

(In reply to Andrew Bartlett from comment #1)
err, The line in the log you highlight refers to a change made with BadLock fixes in CVE-2016-2118 back on on Samba 4.4.2.

Sorry, had some serious trouble shuffling out the logs due to the environment being very noisy. Probably did a poor job of explaining it, as well. So let me take another swing at it.

With 'allow dcerpc auth level connect' not set, the OBSERVED behavior of Samba 4.5.10 is this:
10.10.0.90: DNS denied, all others permitted with appropriate authentication
10.53.0.1:  All RPC permitted, no authentication observed
10.53.0.2:  All RPC permitted, no authentication observed

Obviously, the behavior EXPECTED would be this:
10.10.0.90: DNS denied, all others permitted
10.53.0.1:  All denied
10.53.0.2:  All denied

In other words, Samba is not actually checking properly in this configuration and as a result permits basically even normal users access to 'dnsserver' on the addresses on lo0. It does this even when it is explicitly told to NOT bind to the 10.53.0.[1,2] addresses as well - which I would say is not desirable behavior. (The whole reason for not binding to them is that if permitted to bind, it includes the anycast addresses as candidates for the top level A and other definitely-not-good-practices behaviors.)
To contrast, on 4.5.7 the behavior observed was as desired; 10.10.0.90 permitted all RPC for authenticated users with appropriate permissions, and denied all on the anycast addresses.

That's why I'm suspecting a regression somewhere in 4.5.8; this behavior wasn't observed in 4.5.7 using the same exact config and the same domain. Upgrading to 4.5.8 triggered it. 
While the 'allow dcerpc' may be required, it should be rejecting on ALL addresses. Instead, it only rejects on the interface Samba is explicitly bound to. The inverse of what one would expect. And the accesses on the anycast address do not appear to be subjected to any checks; it's as though they're acting as the DC itself.

Results of further testing. Client is Windows 2012R2 with all of the latest security patches, but does NOT have 05-2017 Quality rollup. This is starting to look something is behaving very inconsistently.

WITH 'allow dcerpc auth level connect:dnsserver = yes' in smb4.conf, ALL IPs deny access to DNS snap-in as TEST\Administrator.
  dcesrv_request: restrict access by min_auth_level[0x5] to [dnsserver] with auth[type=0xa,level=0x2] on [ncacn_ip_tcp] from [ipv4:10.10.1.38:52205]

WITH 'allow dcerpc auth level connect = yes' in smb4.conf, ALL IPs deny access to DNS snap-in.
  dcesrv_request: restrict access by min_auth_level[0x5] to [dnsserver] with auth[type=0xa,level=0x2] on [ncacn_ip_tcp] from [ipv4:10.10.1.38:52209]

WITHOUT 'allow dcerpc auth level' set, ALL IPs deny access to DNS snap-in.
  dcesrv_request: restrict auth_level_connect access to [dnsserver] with auth[type=0xa,level=0x2] on [ncacn_ip_tcp] from [ipv4:10.10.1.38:52201]

This may be related, or may even be the root cause. This is, again, on a completely clean system with an entirely fresh domain provision. There is clearly an off-by-one error going on in gensec_gssapi_update.

[2017/05/29 13:51:28.538292,  1] ../source4/auth/gensec/gensec_gssapi.c:622(gensec_gssapi_update)
  GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see text): Failed to find SKYHORN$@TEST.PVT(kvno 2) in keytab FILE:/var/db/samba4/private/secrets.keytab (aes256-cts-hmac-sha1-96)
[2017/05/29 13:52:28.611454,  1] ../source4/auth/gensec/gensec_gssapi.c:622(gensec_gssapi_update)
  GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see text): Failed to find SKYHORN$@TEST.PVT(kvno 2) in keytab FILE:/var/db/samba4/private/secrets.keytab (aes256-cts-hmac-sha1-96)
[2017/05/29 13:55:00.372775,  2] ../source4/dsdb/kcc/kcc_periodic.c:711(kccsrv_samba_kcc)
  Calling samba_kcc script

The KVNO is being shifted by 1 here somewhere. The actual KVNO is 1.
root@skyhorn # ktutil -k /var/db/samba4/private/secrets.keytab list | grep SKYHORN
  1  des-cbc-crc              SKYHORN$@TEST.PVT
  1  des-cbc-md5              SKYHORN$@TEST.PVT
  1  arcfour-hmac-md5         SKYHORN$@TEST.PVT
  1  aes128-cts-hmac-sha1-96  SKYHORN$@TEST.PVT
  1  aes256-cts-hmac-sha1-96  SKYHORN$@TEST.PVT

root@skyhorn # samba_spnupdate -d 10
... trimmed ...
pm_process() returned Yes
Security token SIDs (1):
  SID[  0]: S-1-5-18
 Privileges (0xFFFFFFFFFFFFFFFF):
  Privilege[  0]: SeMachineAccountPrivilege
  Privilege[  1]: SeTakeOwnershipPrivilege
  Privilege[  2]: SeBackupPrivilege
  Privilege[  3]: SeRestorePrivilege
  Privilege[  4]: SeRemoteShutdownPrivilege
  Privilege[  5]: SePrintOperatorPrivilege
  Privilege[  6]: SeAddUsersPrivilege
  Privilege[  7]: SeDiskOperatorPrivilege
  Privilege[  8]: SeSecurityPrivilege
  Privilege[  9]: SeSystemtimePrivilege
  Privilege[ 10]: SeShutdownPrivilege
  Privilege[ 11]: SeDebugPrivilege
  Privilege[ 12]: SeSystemEnvironmentPrivilege
  Privilege[ 13]: SeSystemProfilePrivilege
  Privilege[ 14]: SeProfileSingleProcessPrivilege
  Privilege[ 15]: SeIncreaseBasePriorityPrivilege
  Privilege[ 16]: SeLoadDriverPrivilege
  Privilege[ 17]: SeCreatePagefilePrivilege
  Privilege[ 18]: SeIncreaseQuotaPrivilege
  Privilege[ 19]: SeChangeNotifyPrivilege
  Privilege[ 20]: SeUndockPrivilege
  Privilege[ 21]: SeManageVolumePrivilege
  Privilege[ 22]: SeImpersonatePrivilege
  Privilege[ 23]: SeCreateGlobalPrivilege
  Privilege[ 24]: SeEnableDelegationPrivilege
 Rights (0x               0):
lpcfg_servicenumber: couldn't find ldb
lpcfg_servicenumber: couldn't find ldb
Initial schema load needed, as we have no existing schema, seq_num: 2
schema_fsmo_init: we are master[yes] updates allowed[no]
Initial schema load needed, as we have no existing schema, seq_num: 2
schema_fsmo_init: we are master[yes] updates allowed[no]

root@skyhorn /var/db/samba4/private # ldbsearch -H secrets.ldb
# record 1
dn: flatname=TEST,cn=Primary Domains
msDS-KeyVersionNumber: 1
...trimmed...
# record 4
dn: samAccountName=dns-SKYHORN,CN=Principals
msDS-KeyVersionNumber: 1

So the LDB is saying that it is KVNO 1, the keytab has KVNO 1, but Samba is looking for KVNO 2 for both the host AND DNS principals.

if you think that this problem is still presen,t then please test agail with 4.13 and file a new bug report with a compact summary of the problem and condensed information how to reproduce the problem, otherwise we'll not be able to handle it reasonably.