Monthly Archives: 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 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.

Advertisements

Msg 8152, Level 16, State 10 String or binary data would be truncated. The statement has been terminated.

It appears that when you want to “insert into” data from an nvarchar(max) field to another nvarchar(max) field, and the table has a lot of data the ms sql query is terminated giving you the error

Msg 8152, Level 16, State 10 String or binary data would be truncated The statement has been terminated.

After narrowing down data fields and understanding which field is the problematic one, and given that the source field is nvarchar(max) and so is the destination, you need to go on troubleshooting this.

Suppose I have the following query:

INSERT INTO ServiceJournal

(PriorityID, TechnicianID, ServiceTaskID, ClientID, ServiceDate, ProblemReportDateTime, EventTypeid, ReminderID, CustomerSiteID, DetailedProblemDescription)

SELECT        3 AS Expr1, Customers.EmployeeResponsibleID, 16 AS Expr2, Customers.CustomerID, GETDATE() AS Expr3, GETDATE() AS Expr4, 2 AS Expr5, 2 AS Expr6, 1 AS Expr7, Customer_Tasks.TaskDescription

FROM            Customer_Tasks INNER JOIN

Customers ON Customer_Tasks.CustomerID = Customers.CustomerID

WHERE        (Customer_Tasks.IsMaintenance = 1)

The field DetailedProblemDescription is the one producing the problem.

I tried creating a new field on the destination table ServiceJournal, called test as nvarchar(max) and changed my query to

INSERT INTO ServiceJournal

(PriorityID, TechnicianID, ServiceTaskID, ClientID, ServiceDate, ProblemReportDateTime, EventTypeid, ReminderID, CustomerSiteID, test)

SELECT        3 AS Expr1, Customers.EmployeeResponsibleID, 16 AS Expr2, Customers.CustomerID, GETDATE() AS Expr3, GETDATE() AS Expr4, 2 AS Expr5, 2 AS Expr6, 1 AS Expr7, Customer_Tasks.TaskDescription

FROM            Customer_Tasks INNER JOIN

Customers ON Customer_Tasks.CustomerID = Customers.CustomerID

WHERE        (Customer_Tasks.IsMaintenance = 1)

The script inserts a number of rows, as it should!

I tried to rename the problematic field to DetailedProblemDescription2 and retry. It does not work.

I backed up the field data to another field and deleted the field. This is where I started losing the table integrity. I had to take the data with an export script, drop and recreate the table (taken from a backup) and restore the data.

Need to mention that concatenating the DetailedProblemDescription field with cast (DetailedProblemDescription as nvarchar(4000)) or other data type, did not work as well.

To make a long story short, I overcame the insert into problem by putting

SET ANSI_WARNINGS  OFF;

 

SET ANSI_WARNINGS  ON;

As long as the “problematic” field characters don’t go over 4000 characters, no problem occurs. I will need to test it with more in the next months.

Have no time to investigate this further, but worth’s writing it down and sharing:)

Till next time!

%d bloggers like this: