Skip to main content

Public DNS Servers

Domain Name Service (or Server or System) is an internet service that translate easily memorized domain names into IP numbers and vice-versa. DNS Servers can be better understands as Yellow page directory to the Internet.
Every ISP runs DNS services for their customers and users. A user can also runs DNS service for its own.

There are many DNS servers which are open for all, commonly known as Public DNS Servers.
IP addresses of main Public DNS Servers are :-

Google Public DNS Servers
1.   8.8.8.8
2.   8.8.4.4
3.  2001:4860:4860::8888
4.  2001:4860:4860::8844

Level 3 Public DNS Servers
5.    4.2.2.1
6.    4.2.2.2
7.    4.2.2.3
8.    4.2.2.4
9.    4.2.2.5
10.  4.2.2.6

OpenDNS Public DNS Servers
11.     208.67.222.222
12.     208.67.222.222
13.     2620:0:ccc::2
14.     2620:0:ccd::2

Norton Public DNS Servers
15.   198.153.192.1
16.   198.153.194.1

Comodo Secure Public DNS Server
17.   8.26.56.26
18.   8.20.247.20

Other Public DNS Server
19.   195.46.39.39
20.   195.46.39.40
21.   156.154.70.1
22.   156.154.71.1
23.   216.146.35.35
24.   216.146.36.36
25.   151.236.6.156
26.   118.88.20.195




Popular posts from this blog

Flaw in ServerKeyExchange messages of TLS Protocol

Here we will discuss the flaw in the ServerKeyExchange messages of the TLS protocol which caused the Logjam attack over TLS while using Diffie-Hellman Key Exchange. Before SSLv3, we don't use to authenticate the ServerKeyExchange messages where server negotiates with client regarding usage of cipersuite and parameters. From onwards SSLv3, TLS send the signed message where it mention about parameters it will use but remain silent over ciphersuite. Or in other words, signed portion contains parameters but not contain information about ciphersuite the server will going to use. Now just to remind you, the difference between DH and DH-EXPORT is the size of parameters only. So how to use this flaw - If the server supports DH-EXPORT, an attacker (Men-in-the-Middle) can edit the negotiation sent by the client (even if client doesn't support DH-EXPORT), and replace the list of client supported ciphersuite with DH-EXPORT only. The server will in turn send back a

Identity PSK ( iPSK)

With the evolution of IoT (Internet of Things), devices that connect wirelessly have increased many folds. From webcams, Smartwatches, fitness bands, firestick, Alexa, Google Home, and many more.., everything is going wireless for connectivity and so does the security threat. The main concern with IoT devices is the unavailability of the full wireless protocol stack (and in the majority of devices, support of 802.1x is not available). So, previously we only have the WPA-PSK option for connecting the IoT devices.  In WPA*-PSK (WPA or WPA2) WLAN, a Pre-Shared Key (PSK) is configured and distributed to all the clients that connect to the WLAN. This leads to PSK leakage, and it can be accessible to unauthorized users (due to the nature of common PSK across all the devices).  Therefore, there was a need to provision unique PSK or Multiple PSK per SSID. Identity-PSKs are unique pre-shared keys created for clients/groups on the same WLAN. Features of iPSK:-   1.Unique PSK for individual Cli