Recursive-Resolver

The curious case of esic.in DNS

A couple of weeks ago, at my $dayjob, we implemented a recursive resolver with RPZ in an enterprise network. After a few days, the customer got back to us with an issue - the DNS resolution of the domain esic.in failed with an NXDOMAIN response. After a cursory look at the problem, it became evident that esic.in resolved correctly but www.esic.in did not. The customer also reported that if they switched the resolver to 8.

Jio VoWiFi issue - It's always DNS!

tl;dr If Jio VoWiFi isn’t working for you, set a different DNS resolver on the phone. While I am a big proponent of running your own resolver in the network, ( runyourownresolver.in ) , you could test by using open resolvers. The issue doesn’t seem to be impacting everyone and only a subset of users. To begin with, there are multiple things broken in the authoritative name servers ns1.vowifi.jio.com. and ns2.

Chromium based browsers & DNS

While this is not something new, it perhaps has more significance because of the ever increasing market share of more than 60% of Chromium based browsers. Chromium based browsers have a very uncanny method to check if the web browser is sitting behind a captive portal. And if you’re running a recursive resolver in your network with a large user base running Chromium based browsers (Google Chrome, Brave etc), it might even startle you if you observe the recursive resolver logs.