nslookup returning wrong DNS address

[csewell]

This driving me batty as I cannot figure out what is happening. I'm not sure this is a BELL or HH4000 problem either.

Here's the problem: I have a personal domain name that is being hosted on CloudFlares DNS server.  The DNS name is assigned the public ip address of the HH4000. An nslookup of that domain from any PC, WiFi attached phone or tablet on my local network should return the public ip of the HH4000 right? Up until a few days ago it was. Then something changed, and now nslookup returns some 18.*.*.* address which resolves to an amazonaws.com name. This ONLY happens on my internal network behind the HH4000 and it happens on ALL networked devices: PC's, laptops, phones, tablets. If I nslookup from a web app or some PC outside my network, it returns the proper DNS address of the HH4000.

What I have tried: ipconfig /flushdns, powering off the HH4000 until it was assigned a new public ip address, doing an nslookup using another DNS server such as Googles or CloudFlares (8.8.8.8 or 1.1.1.1), assigning these public DNS servers in the HH4000 instead of Bells default DNS servers, changing the adapter settings of some PCs to use a public DNS instead of the default 192.168.2.1, restarting some PCs.

None of those made a difference, nslookup on any device inside my network still returns and amazonaws.com ip  address. Here's another clue: nslookup -v returns the proper ip address,  but I have no idea what the -v switch means in Windows nslookup.

Can someone clue me in on where the problem lies? Bell? HH4000? Something inside my network? Some DNS server somewhere?

[Vanadiel]

CloudFlare is an authorative name server. Your public IP will already have a DNS name assigned.

Try the -d option to see more packet information 

[csewell]

I'm not sure what you mean by "Your public IP will already have a DNS name assigned". As a matter of fact BELL sometimes does not have PTR records for their public ips assigned. In any case I want to use my own domain name, not BELLs, which ,when they do assign one to their public ips, changes with the public ip.

The -d option certainly gives more information, but still tells me:

Got answer:
HEADER:
opcode = QUERY, id = 4, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0

QUESTIONS:
mydomain.com, type = A, class = IN
ANSWERS:
-> mydomain.com
internet address = 18.*.*.*
ttl = 10 (10 secs)

18.*.*.* is NOT the address in the A record for mydomain.com. I do not know where this 18. address comes from.

[Vanadiel]

Not exactly sure what you are trying to accomplish, but mydomain.com cannot be used to point to your public IP address. It resolves to what you are seeing as the 18 address as they likely host their actual servers at Amazon Web services 

[csewell]

I thought what I'm trying to accomplish was clear. I want to access devices on my network from the internet using port forwarding.  The same thing anyone who uses dyndns or no-ip wants to do. And mydomain.com is not the domain name I have registered, I just used it as an example to redact my real domain name. My real domain name is hosted on CloudFlare and the A record has the external address BELL assigned to the WAN port of the HH4000. You would expect an nslookup of my real domain name to return that address but it's not, it's returning this 18.*.*.* address. But only inside my network. Consequently I can't access any of my devices on the LAN side of the HH4000 by domain name, only by ip address.

[csewell]

Can anyone using BELL as an ISP do an nslookup on ngc1952.com and PM the result? I'm trying to find out if BELL is blocking my domain name,

[dks]

Your requested ns lookup shows up on Cloudflare with an IP of 142.181.xxx.xx and clearly identified as a Bell Canada IP. 

[csewell]

That is strange. And you're doing a straight nslookup from a PC connected on the BELL network? It shows up as an 18.*.*.* address for me. There's something going on with my HH4000 or with my connection to BELL. 

[dks]

Yes, I am. Don't forget that Bell may not allow nslookup queries to go right to your modem but may stop at a router for security reasons. 

[csewell]

I thought the HH4000 might be caching DNS entries but restarting and bouncing the power didn't change anything. I can also force DNS over TCP instead of UDP (-vc}, and that returns the proper ip. Anyway the end result of this is a malware warning on my website, and none of my port forwards are working unless I use the ip address instead of the domain name. Free no-ip domain name also works, but I'd rather use the domain name I bought and paid for. I'm going to contact BELL support over this. 

[dks]

Thanks for the update. You may or may not have any success with contacting Bell support. Do expect to spend a lot of time doing so. The Community Forum is part of Bell's support. And always remember that Bell doesn't support equipment and configurations beyond the modem itself. 

[csewell]

You're right, BELL support was useless.  Their only suggestion was a factory reset. They aren't interested in looking  at their network or finding out how my DNS name is being hijacked. I probably would have more luck with a business account.  Anyway, I did find someone else who seems to have the same problem, according to this post: Dig returns incorrect DNS record, but only on specific network. What's wrong? 

Does the GigaHub have a malicious site blocker? I can't see any menu entry to turn that on or off. Or is it something else between the GigaHub and the internet?

My GigaHub is being replaced with a GigaHub 2 in the next few days.  Maybe I will factor reset between now and then,

[dks]

I ran traceroute from within the modem and Windows again and got the same result. Using a web tool goes to the US and then bounces around in France. 

[dks]

Any Bell modem is a dumb device. It's sole function is to change light into electrical impulses and connect to your devices. I can't speculate on Bell's network. They take security very seriously, and rightly so. I have the Giga Hub 2. The modem interface is pretty much the same. 

[Vanadiel]

I was trying to explain this before, but I think there was some misunderstanding on what I was stating.

Tracert for ngc1952.com goes to142.181.*.*

If you check Ican lookup you will see that address is part of a block of addresses registered to Sympatico (Bell).

• Handle: NET-142-181-215-0-1
• Status:

  active

• Address Range: 142.181.215.0 - 142.181.215.255
• IP version: v4
• Name: HSE-DYNAMIC-1732137529-CA
• Type: ASSIGNMENT
• Parent Handle: NET-142-181-0-0-1
• Whois Server: whois.arin.net

Dates

• Registration: 2024-11-20 21:19:07 UTC
• Last changed: 2024-11-20 21:19:07 UTC

The type is "assignment", meaning they are assigned to Bell.

If I understand correctly what you are trying to accomplish, is to use Cloudflare to host your domain and then point that to the Bell IP. Unless you have a static assigned IP issued by Bell, this is going to cause issues as the IP's are designed dynamically for residential services.

Also, residential services are not provisioned to run servers and therefore this is not supported by Bell.

The reason why Free no-ip domain might work, it because they have automatic IP updates for the DNS records. 

Now if 142.181.*.* is the correct IP and we both can resolve it properly, then the issue with it resolving on your end to 18.*.*.* could be because of VPN services, malware blockers, or something else on your LAN that is controlling DNS and provides 18.*.*.* instead of 142.181.*.*.

I highly doubt it is the modem, but I have seen stranger things. 

If you have a cellphone, try using it in cellular data mode and see what it resolves there.