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.
You actually make it seem really easy with your presentation however I in finding this topic to be actually one thing that I think I would by no means understand. It sort of feels too complex and extremely vast for me. I’m looking ahead for your next post, I’ll attempt to get the grasp of it!