Friday, 17 February 2017

DNS publishing over COSMOTE, is not any more supported?

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 NumberTest descriptionRequest InitiatorRequest ReceiverTest Outcome
1Nslookup from a Cosmote Internet fed client to a zone hosted on Cosmote served serverServer AServer BSuccess
2Nslookup from a Cyta Internet fed client to a zone hosted on Cosmote served serverServer CServer BFailure
3Nslookup from a Cosmote Cell Internet fed server to a Cosmote served serverServer BCServer BFailure
4Nslookup from a Wind Internet fed server to a Cosmote served serverServer WServer BFailure
5Nslookup from a Forthnet Internet fed server to a Cosmote served serverServer FServer BFailure
6Nslookup from a Vodafone Internet fed server to a Cosmote served serverServer VServer BFailure
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 NumberRequest InitiatorRequest ReceiverTest Outcome
7Server AServer BSuccess
8Server AServer CFailure
9Server AServer DFailure
10Server DServer AFailure
11Server CServer AFailure
12Server BServer ASuccess
13Server BServer CFailure
14Server BServer DFailure
15Server CServer BFailure
16Server CServer DSuccess
17Server DServer CSuccess
18Server DServer BFailure
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.