BSNL intercepting in-bound DNS traffic over port 53?

Last night I was just curious and did a simple default nmap scan of my BSNL public IPv4 address from another network and I was surprised to see that port 53 is open.
I tried querying with dig and it did return a response. Quickly I reviewed my firewall rules and by default, everything is blocked and there is no rule allowing port 53 traffic. But I could still query my public IP address and get valid responses from an external non-BSNL network. I then shut down the dnsmasq instance but I could still get a valid response.

Then I tried an nmap scan of another IP address which doesn't even ping and looks un-allocated as of now. Even that responds to DNS requests. It appears to me they are intercepting any port 53 traffic on their IP space and redirecting it to some other working resolver. Please note this is only for inbound requests ie from the external internet to BSNL.

The below is an IP address that was allocated to me before which is now in the pool and doesn't appear to be allocated to anybody yet.

[root@varkey-minipc ~]# nmap -Pn 117.215.188.107

Starting Nmap 6.40 ( http://nmap.org ) at 2020-04-05 15:47 IST
Nmap scan report for 117.215.188.107
Host is up (0.077s latency).
Not shown: 999 filtered ports
PORT   STATE SERVICE
53/tcp open  domain

Nmap done: 1 IP address (1 host up) scanned in 3.89 seconds

[root@varkey-minipc ~]# dig google.com +short @117.215.188.107
172.217.167.174
[root@varkey-minipc ~]# dig dns.google +short @117.215.188.107
8.8.4.4
8.8.8.8
[root@varkey-minipc ~]#

However, it appears to work only from Indian source IP addresses. Cause I tried querying from my VM with Hetzner, but it fails.

root@s1 ~ # nmap -Pn 117.215.188.107

Starting Nmap 7.60 ( https://nmap.org ) at 2020-04-05 12:18 CEST
Nmap scan report for 117.215.188.107
Host is up (0.40s latency).
All 1000 scanned ports on 117.215.188.107 are filtered

Nmap done: 1 IP address (1 host up) scanned in 9.21 seconds
root@s1 ~ # dig dns.google +short @117.215.188.107

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> dns.google +short @117.215.188.107
;; global options: +cmd
;; connection timed out; no servers could be reached
root@s1 ~ #

 

[abbyck]

I too have noticed 53 opened while doing an external port scan.
Ignored that thinking this might be due to some options I enabled in Netlink ONU .

 

[Dark_Nate]

What are the potential security risks implications of this? Assuming on the user end, there's no issue.

 

[popcorn]

end user will have a danger of dns highjack which is harmful as the use of dns cache to exploit the correct dns query to a malicious website.
dnssec helps to eliminate this at the highest domain order TLD.

 

[Dark_Nate]

@popcorn I guess, if the user is using custom DoH, DoT or DNSCrypt/DNSSEC capable resolver on router level at the very least, they should be fine.

I might be wrong though.

 

[popcorn]

There is very less chance user can use these technologies on home routers ! Firefox supports the dnssec go to options-Network you wil find their default disabled, but if you enable it, you can use cloudflare ddnssec as pre installed config. You can manually also use opendns if you wish. But I have seens few antivirus suits hate such dns !!

 

[varkey]

end user will have a danger of dns highjack which is harmful as the use of dns cache to exploit the correct dns query to a malicious website.
dnssec helps to eliminate this at the highest domain order TLD.

Maybe I misunderstood, but how would an end-user have the danger of DNS hijack due to this particular issue.

 

[JB701]

I guess having a open resolver could lead to possibility of abuse using DNS Amplication DDoS attacks

https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/

 

[abbyck]

Yeah, I too was thinking about dns amplification attacks.

 

[varkey]

Ok, but how would this specific issue help in that? This resolver is not on the end user's network, the DNS traffic to the IP address never reaches the end-user. I don't see how this could help in DNS hijack for an end-user.

Sure, having an open resolver would help someone to run an amplification attack (if the resolver doesn't try to mitigate or rate limit such requests), but the end user here ie the BSNL FTTH/broadband user isn't really affected is he?