Your A records are fine, but you seem to have changed name servers. Your old NS records are probably cached all over the place; the TTL on those seems to be 48 hours. It looks like the old server (at my-tss.com) is serving the correct data now, but it was probably still serving stale data when you saw the problem. Possibly it took it a while to realize that it wasn’t authoritative for the zone, or possibly there was an update problem.
Generally, it’s better to do the server change and the data change separately. And you have to make sure that the new and old servers are serving the same thing through the full TTL of the old NS records, or at least have the old server definitively reconfigured not to see itself as authoritative so that it can avoid misleading other systems when it gets a query.
Evidence: If I let my system use my ISP’s servers and do dig -t ns bilingadvantage.com., I get the wrong cached data:
Your A records are fine, but you seem to have changed name servers. Your old NS records are probably cached all over the place; the TTL on those seems to be 48 hours. It looks like the old server (at my-tss.com) is serving the correct data now, but it was probably still serving stale data when you saw the problem. Possibly it took it a while to realize that it wasn’t authoritative for the zone, or possibly there was an update problem.
Generally, it’s better to do the server change and the data change separately. And you have to make sure that the new and old servers are serving the same thing through the full TTL of the old NS records, or at least have the old server definitively reconfigured not to see itself as authoritative so that it can avoid misleading other systems when it gets a query.
Evidence: If I let my system use my ISP’s servers and do
dig -t ns bilingadvantage.com., I get the wrong cached data:… but if I go and query the actual GTLD servers, say with
dig -t ns @a.gtld-servers.net billingadvantage.com, I get the right data: