|
|
P.S. @taneb1:
203.74.33.0 is not a Wildcard Record. Wildcards are used for non existent domains, which is not the case for TrustPower Webmail as can be seen below:
https://docs.citrix.com/en-us/netscaler/12/dns/supporting-wildcard-dns-domains.html
The I.P. of 203.74.33.0 listed as "Primary DNS" on Trustpower's support website points only to https://rns-1.kinect.co.nz. - TrustPower Webmail, maintained by Vocus incidentally.
One has to wonder why the extra hop is in place - unless a genuine mistake has been made.....
.
ID Verified
Trusted
Mercury
Any comments made are my personal views and does not represent those of my employer
As I said already, the DNS fubar is secondary, however it remains an issue nonetheless.
I won't go through every single problem but it may help to know that the customer was with Trustpower in Auckland and moved to an RBI area prior to Christmas, TP was meant to have a broadband connection up and running on the 22nd of December.
5 weeks later, there is still NO connection, furthermore the client lives in an area where there is also no cellphone coverage. TrustPower CSR are well aware of this.
On two separate occasions, TP CSR have informed the client and myself that a ticket had been logged with Chorus. The first time, before I got involved, the client waited a week - after no Chorus Tech appeared the client called TP - who denied a ticket had ever been logged.
The second time, I spoke directly with TP CSR, I made it clear that I was an IT Technician and the problem was not at the clients end, initially the CSR gave me a canned reply stating a disclaimer was needed before a ticket could be logged with Chorus. This is around 3 weeks into the fiasco and AFTER the client had been through Tier 1 hoops.
I called back and talked to a second CSR, who, after I fired off a barrage of technical information to reaffirm the problem was out of the clients control, advised I had to talk to "Tier 2" support - then said T2 was not available. The 3rd time I called, I like the client was assured a ticket would be logged with Chorus.
A week later, again with a no show client called TP - again TP denied a ticked had ever been logged.
This is now 5 WEEKS after provo was meant to happen. Quite frankly it is not MY job to figure out wtf is going on to cause no authentication, it's Trustpowers.
And I can state with confidence that Trustpower CSR support ranks at the very bottom of all the ISP's I have dealt with over the last 15 years. TP CSR support is abysmal.
While hio77 would never state this publicly, I know he agrees, he helped me extensively well before this thread was started.
Neither of us can figure out why there is no connection, however we do know it is not at the clients end.
regsm01: 202.74.33.0 is configged to point nowhere and so will not be striking anything when you search of it(why are you trying to search IP's when your customers modem is missing a WAN IP anyway???), the reverse lookup found a site scraping off random DNS and happened to manage to find trustpowers?
I'm not sure if you're trolling or just very misinformed, however either way, the screenshot below should make the answer to your question crystal clear.
Hi,
pillmonsta:
regsm01: 202.74.33.0 is configged to point nowhere and so will not be striking anything when you search of it(why are you trying to search IP's when your customers modem is missing a WAN IP anyway???), the reverse lookup found a site scraping off random DNS and happened to manage to find trustpowers?
I'm not sure if you're trolling or just very misinformed, however either way, the screenshot below should make the answer to your question crystal clear.
I think what's confusing here is that you're doing a reverse DNS lookup on an IP, then trying to browse to what that comes back with. That doesn't really produce anything useful. As Tane said, rns-1.kinect.co.nz doesn't exist, so it gets whatever is configured for *.kinect.co.nz, which has a CNAME to webmail. What is in the DNS for 0.33.74.202.in-addr.arpa. is not really relevant to the function of the recursive name servers on 202.74.33.0 and 202.74.33.1, as others have stated I believe.
DNS servers have nothing to do with whether your CPE gets an IP address or not - a broken DNS server would stop the Internet from working once you're connected probably, but it doesn't get involved in you getting assigned an IP address by DHCP or PPPoE. You seem to agree with the assessment that DNS isn't important here, which is good. Not really sure how the DNS conversation came up in the first place though.
You say that the DNS is "fubar". It's not, though I can understand why rns-1.kinect.co.nz not existing and going to a wildcard might be confusing for some people, so I've added that (and some other similar ones) so other people don't get confused in the future.
pillmonsta:
P.S. @taneb1:
203.74.33.0 is not a Wildcard Record. Wildcards are used for non existent domains, which is not the case for TrustPower Webmail as can be seen below:
https://docs.citrix.com/en-us/netscaler/12/dns/supporting-wildcard-dns-domains.html
The I.P. of 203.74.33.0 listed as "Primary DNS" on Trustpower's support website points only to https://rns-1.kinect.co.nz. - TrustPower Webmail, maintained by Vocus incidentally.
One has to wonder why the extra hop is in place - unless a genuine mistake has been made.....
The statement about wildcards being for non-existent domains is a little bit off. I don't think Tane said 202.74.33.0 is a wildcard. You can stick a wildcard in when you want anything.$domain to resolve, but don't want to have to pre-define all those things. It used to point to the Trustpower corp. website, right now it points to webmail as there are customers who hit it with weird mistyped names sometimes.
The statement about that webmail being run by Vocus is false. I am not clear why you make that assumption - can you show your working? Not sure what the extra hop refers to, did you do a traceroute or something and see Vocus in the path?
You've pretty consistently said 203.74.33.0 - but the IP is really 202.74.33.0. Note the first octet - 202 not 203. It looks like your investigation is mostly on 202.74.33.0 which is good, but writing 203.74.33.0 in these posts sure makes it confusing, and hard for anyone else trying to follow you.
Let me know if you have any technical questions about DNS or any other ISP/Internet technical stuff - I can't speak much about your particular connection as I don't have any info, but I understand from reading the thread that it's been terminated which is a shame. I understand Tane's asked privately for the connection info but hasn't heard back? We probably still have records if you know the account name or whatever, would be interesting to find out what's gone wrong there. These sorts of issues generally happen in the last mile access provider's network as they often have a lot of manual people doing provisioning etc., but are generally quick to fix. It's a bit confusing as I think you've said that it's RBI, which means a bunch of different things in different parts of the country.
Usual disclaimer that I'm not speaking for anyone other than myself, etc. etc.
nathanward:
The statement about wildcards being for non-existent domains is a little bit off. I don't think Tane said 202.74.33.0 is a wildcard. You can stick a wildcard in when you want anything.$domain to resolve, but don't want to have to pre-define all those things. It used to point to the Trustpower corp. website, right now it points to webmail as there are customers who hit it with weird mistyped names sometimes.
As it's likely yet another proxy for TP I'll just address Tane directly:
Agreed.
Is this better?
Maybe you can try & explain away mail01.kinect as well? Yes, I said rns-1, but I had already seen this way beforehand. I suppose kinect has nothing to to with TrustPower either? More denial.....
The statement about that webmail being run by Vocus is false. I am not clear why you make that assumption - can you show your working? Not sure what the extra hop refers to, did you do a traceroute or something and see Vocus in the path?
How I got the information is none of your business. I said it was maintained by Vocus, and yes I can provide evidence why else would I make such a random statement?
I take screenshots of everything just so I can back it. I'm curious as to why yet another new user is so interested in a trivial point made in the thread? More deflection?
You've pretty consistently said 203.74.33.0 - but the IP is really 202.74.33.0. Note the first octet - 202 not 203. It looks like your investigation is mostly on 202.74.33.0 which is good, but writing 203.74.33.0 in these posts sure makes it confusing, and hard for anyone else trying to follow you.
I imagine it would be quite obvious to anyone else reading this thread what I was referring to considering the topic at hand. It's a lot easier to post a screenshot that type an IP every time.
nathanward:
Let me know if you have any technical questions about DNS or any other ISP/Internet technical stuff - I can't speak much about your particular connection as I don't have any info, but I understand from reading the thread that it's been terminated which is a shame.
I understand Tane's asked privately for the connection info but hasn't heard back? We probably still have records if you know the account name or whatever, would be interesting to find out what's gone wrong there. These sorts of issues generally happen in the last mile access provider's network as they often have a lot of manual people doing provisioning etc., but are generally quick to fix. It's a bit confusing as I think you've said that it's RBI, which means a bunch of different things in different parts of the country.
Condescension is a cheap way to try and gain an upper hand. If you're confused buddy, join the others at TrustPower. No experience required. Would you like me to post proof of that statement as well?
And no Tane has not attempted to contact me, not that it would make any difference. Nor do I care what you "understand". Cut the BS, please. ;)
If five weeks without communication is "a shame" it's no wonder TP has such a bad rep. Want to see links for that statement too?
My friend by the time an IT Technician arrives on the scene the situation is normally at critical.
New ISP's like TP and need to learn technicians at clients residence always have more sway than any CSR drip feeding the customer BS. So don't try it on us as well.
Who do think advised the client to dump TrustPower?
As I said before, it's your job as an ISP to sort the authentication problem out - not mine. My job is to assess whether the issue is with ISP or the Client.
I'm excellent in Virtual to Physical Address translation if you'd like to talk OS and CPU's. Networking def takes 2nd seat however that does not mean I don't see things that aren't right.
I am a fast learner. In fact I've spent the last week poring through Chorus and Cisco docs to see just how deep the ISP Rabbit Hole is.
Does BUBA & "presence" mean anything to you?
Anyway, the real issue here is Trustpowers crap service - don't try and deflect from that by attacking my networking skills.
This thread can def be closed in my pov....the damage is already done.
- Btw, the number of brand new 1 or 2 post users participating in this thread has not gone unnoticed either.
|
|
|
