Msg 8152, Level 16, State 10 String or binary data would be truncated. The statement has been terminated.
February 14, 2017
Windows 10 roaming profiles cause Edge and other packaged applications to fail loading
September 6, 2017
The past few months COSMOTE, a Greek ISP started providing VDSL access in our country. Right after being very happy about it, we started noticing changes affecting many of our customer services, including proper Domain Name Services data exchange.
The Domain name Service, supports hosting of a domain name zone, servicing clients requesting host A or other records from this DNS, while DNS transfer is a process which enables the Domain Name Zone transfer in a set of prior selected and configured DNS servers.
Our tests, described below, involve both of the above functions.
| Test Number | Test description | Request Initiator | Request Receiver | Test Outcome |
| 1 | Nslookup from a Cosmote Internet fed client to a zone hosted on Cosmote served server | Server A | Server B | Success |
| 2 | Nslookup from a Cyta Internet fed client to a zone hosted on Cosmote served server | Server C | Server B | Failure |
| 3 | Nslookup from a Cosmote Cell Internet fed server to a Cosmote served server | Server BC | Server B | Failure |
| 4 | Nslookup from a Wind Internet fed server to a Cosmote served server | Server W | Server B | Failure |
| 5 | Nslookup from a Forthnet Internet fed server to a Cosmote served server | Server F | Server B | Failure |
| 6 | Nslookup from a Vodafone Internet fed server to a Cosmote served server | Server V | Server B | Failure |
As it appears on Test 3, the mobile network of Cosmote cannot access a zone hosted on a private server internet fed by the terrestrial Cosmote network. That’s weird, but understandable since the merging between the two is only a few months old.
Ok now let’s see what else is “weird” now. Suppose we have the following 4 servers:
SERVER A: is internet fed by Cosmote ADSL
SERVER B: is also internet fed by Cosmote ADSL
SERVER C: is internet fed by Cosmote VDSL
SERVER D: is also internet fed by Cosmote VDSL
A few more tests described below:
| Test Number | Request Initiator | Request Receiver | Test Outcome |
| 7 | Server A | Server B | Success |
| 8 | Server A | Server C | Failure |
| 9 | Server A | Server D | Failure |
| 10 | Server D | Server A | Failure |
| 11 | Server C | Server A | Failure |
| 12 | Server B | Server A | Success |
| 13 | Server B | Server C | Failure |
| 14 | Server B | Server D | Failure |
| 15 | Server C | Server B | Failure |
| 16 | Server C | Server D | Success |
| 17 | Server D | Server C | Success |
| 18 | Server D | Server B | Failure |
I will make it a bit less confusing for you. VDSL fed servers communicate with each other. ADSL cannot access the VDSLs and vice versa. The weird things is that both the ADSL and VDSLs are provided by the same ISP, which in all our cases is COSMOTE.
We should note, that all the above servers have Business accounts (connex @ Work).
As IT professional we can tolerate with:
- VPN connections dropping every 3 minutes, with no reason.
- Cosmote routers having their firmware updated, whenever the provider asks, using their CPL
- SIP ports being occupied for Cosmote future VOIP usage.
What we cannot tolerate is the DNS protocol and especially when there is no previous notification regarding such a service ban.
I really do wonder, what is next? The SMTP?
Thank you Cosmote for protecting us, but I guess we will protect ourselves and change all our customers to non Cosmote ISPs.
We take as:
Failure: the timeout of DNS query (using nslookup) pointed on a working DNS server (server [ip]) and on an existing well shaped dns zone.
Success: a successful dns query (using nslookup) presenting back all dns records of the requested zone (set q=all/ set q=any)
17/2/17 UPDATE: The above started happening with port 25 (SMTP) randomly.
