Do BT routers block DNS which resolve to private IPs

[hmm3]

So after a really frustrating time trying to deal with this tonight I've settled on a workaround which might work for some cases. Not sure if it would help in your case @ninebolts 

In my case I changed it to be a cname of a "hostname.home" instead, which then the BT router handles the A record of to get around this filtering.

I understand this may be a sensible default, and protects against some dns rebinding attacks, is why I assume its implemented. But to not have the ability to reconfigure this, nor the ability to reconfigure DHCP to point to alternative DNS servers is a really crappy and disappointing situation.

[chandler3224]

@licquorice wrote:

To what purpose?

Certainly for the business I work for we have domains that loop back to internal servers to ease software development. We have a domain resolving to a local IP as well as a domain resolving to an internal test server.

I have the same issues as OP as well as @ninebolts  and @hmm3 . I am trying to resolve to a 172.20 address but it does seem that BT filter out reserved IPs. I did ask BT support but they suggested to raise a complaint to get someone to confirm whether this is the case, so currently I've got an open complaint. 

@hmm3 you mention that you have a cname of hostname.home. I assume this is something you've set up locally? Could you elaborate on this a bit more? 

---

[hmm3]

Sure, at a glance, judging by your IP ranges this isn't going to be remotely helpful, apologies. And as I've continued to test it even has its own quirks and inconsistencies! It will also not work for companies trying to support mutiple end users, or anything like that. It works for me, in my home.

So what I mean is my hub will assign the hostname given on dhcp it's own A record, lets say, for the sake of example "kubernetes.home". So if it's getting its address from the homehub DHCP I can point "kubernetes.hmmm3.com" CNAME to "kubernetes.home" and the homehub will resolve it to, lets say 192.168.1.253, because it's doing the resolution itself for the A record.

What I've actually found in testing this is pretty incredible, it seems to be if the client queries the DNS server by its ipv6 address, then the query won't return anything even from the HH. I don't recall seeing anything in the RFC about handling records differently on this front, but I admit- it has been a while. Still looking into it if its the real root cause but some quick manual testing seems to suggest it might be. So this might end up with me disabling IPv6 as well in the HH, which is a massive shame because that was an annoyance with my last provider!

If the client calls it by ipv4 address then it will lookup "kubernetes.hmmm3.com", find the "kubernetes.home" CNAME and lookup the A record from the home hub itself, which is successfully returned.

This would all go away if we could configure alternative DNS servers given in DHCP, of if this behaviour could be disabled. Behaviours that break RFC's should at least be configurable, and I shouldn't need to manage DHCP manually on each device. It's incredibly frustrating. I get that it's not a problem that affects 95+% of people but it is broken.

If you get any news from your complaint @chandler3224 , I would love to hear back.

[chandler3224]

Ah brilliant, thanks for the info. That's a clever solution but unfortunately it won't help in my case as we have users who aren't on BT as well. 

As for the complaint, I had a notification yesterday that it's been closed with no extra detail. Just straight up closed. I'm going to call today/tomorrow and ask for an update but I'm not getting my hopes up. 

[licquorice]

You have to remember the home hub is a mass produced ISP supplied device that is going to be locked down and plug and play for the 99% of the customer base that have no need to change any settings.  Anybody wishing something more configurable is likely to be using a third party router.

[hmm3]

I completely understand that perspective and I generally agree but that's my particular issue here, if you make something that just works, it does need to work!

It's far more reasonable to expect people to be able to configure something than fault find undocumented network breaking behaviours - even if it were to be remotely reset before support are willing to hop on a call about other issues?

If you make something that goes and breaks standards then that's where good documentation and configuration really should, in my opinion, have to be in place. I'd be happy to be corrected if public DNS resolving private IP addresses isn't standard and that it's other DNS servers that are the issue, but nothing and no RFC I have seen supports that so far.

The only logical reason I can see for this is to protect users from DNS rebinding attacks. But its a massively disproportional response to a really minor threat. Especially when steps aren't being taken to block, say, known malicious domains!

[hmm3]

Feel free to cut me off here- obviously it's none of my business whatsoever, but what is your setup like?

Just thinking if its a point to point VPN to servers you control its probably going to be easier to just push alternative DNS servers as at the point of the connection, even if they're just Google's.

If its a VM host internal network, for Windows and if they're devices under your control you could maybe roll out NRPT rules instead and point them to a VM, Google's server, or your own for that domain. Or even just roll a hosts file to the developers via GPO (bit gross though!). Not sure about other OS's, or if you have a BYOD type thing going on.

Easier than battling multiple ISP's or rolling out your own routers for everyone, I'm thinking. Though whatever the case, I appreciate your raising of a complaint.

[chandler3224]

@hmm3 You're totally right! Pushing it through the VPN setup is the way to go however it seems that the VPN software the company uses is old, very old, and doesn't set the DNS correctly. It's something I'm working with them with but I was trying to tackle it from two different angles. 

I didn't initially aim to raise a complaint. I just wanted to find out whether the BT DNS blocked internal IPs seeing as an official response would have backed my case. However, as I mentioned, BT support have closed the complaint without any sort of reply. 

We've resorted to setting the DNS to Google DNS IPs for those who are affected as we're not always connected to the VPN. Not ideal but does the job. 

I appreciate the help though, thanks!