Member Avatar for CoolAtt

Hi All,

I want to get all the IPs of the A RECORDS for mail.google.com.
The aim is to deny access to these IPs.
I learnt that mail.google.com has several IPs.

I did the following steps:
1. whois google.com
2. I got the following as its DOMAIN SERVERS:

ns3.google.com
ns2.google.com
ns1.google.com
ns4.google.com

3.# dig @ns1.google.com a mail.google.com

;; ANSWER SECTION:
mail.google.com.    0    IN    CNAME    googlemail.l.google.com.
googlemail.l.google.com. 300    IN    A    74.125.233.86
googlemail.l.google.com. 300    IN    A    74.125.233.85

I thought this would give me all the IPs.

Currently, in an attempt to get the other IPs I am digging 4.2.2.2 & other free public dns servers..

someone please explain to me why

dig @ns1.google.com  a mail.google.com

does not give the full list & how other FreeDNS servers are getting different IPs?

  • 3 Contributors
  • 2 Replies
  • 304 Views
  • 11 Hours Discussion Span
  • Latest Post Latest Post by CimmerianX

Dani AI

Generated

Brief expert summary: large providers (Google included) do not always return every A record to every querier. Authoritative servers use geo-aware load balancing, anycast, short TTLs and techniques such as EDNS Client Subnet so the answer is tailored to the resolver's network. That explains why saw only a couple addresses from one authoritative query while other public resolvers showed different addresses; ’s point about the resolver/caching layer is also part of the reason.

How to build a wider picture: sample DNS from many different vantage points and aggregate the unique answers. Passive DNS / historical DNS databases give the broadest set but are usually paid services. Zone transfers (AXFR) will be refused for large domains. A quick way to sample several public resolvers and deduplicate results is shown below.

#!/bin/sh
resolvers="8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222"
target="mail.google.com"
for r in $resolvers; do
  dig +short @"$r" "$target" A
done | sort -u

Practical note about blocking: attempting to deny access by hard-coding IPs is brittle. IP sets for big services change, addresses are shared across services, and overblocking is likely. As mentioned, blocking by FQDN at the DNS or using an HTTP/TLS-aware proxy (Host header or SNI) is usually more reliable. If IP blocking is unavoidable, automate frequent re-sampling, prefer documented IP ranges when available, and test for collateral damage.

Recommended Answers

All 2 Replies

Member Avatar for rubberman

Usually we use nslookup for this. The output of "nslookup google.com" returns this:

Server:     68.94.156.1
Address:    68.94.156.1#53

Non-authoritative answer:
Name:   google.com
Address: 173.194.46.64
Name:   google.com
Address: 173.194.46.71
Name:   google.com
Address: 173.194.46.68
Name:   google.com
Address: 173.194.46.73
Name:   google.com
Address: 173.194.46.65
Name:   google.com
Address: 173.194.46.70
Name:   google.com
Address: 173.194.46.69
Name:   google.com
Address: 173.194.46.72
Name:   google.com
Address: 173.194.46.67
Name:   google.com
Address: 173.194.46.78
Name:   google.com
Address: 173.194.46.66

Whereas, "nslookup mail.google.com" returns this:

Server:     68.94.156.1
Address:    68.94.156.1#53

Non-authoritative answer:
mail.google.com canonical name = googlemail.l.google.com.
Name:   googlemail.l.google.com
Address: 173.194.46.86
Name:   googlemail.l.google.com
Address: 173.194.46.85

The "Server:" and subsequent "Address:" block are specific to your ISP. These will vary. The stuff you need is after "Non-authoritative answer:".

FWIW, nslookup is the normally preferred way to look up DNS names and addresses. You can also use it for reverse name lookups by substituting an IP address, such as 173.194.46.85 for "mail.google.com", though often the name bears no resemblance to the original name, especially for google who swaps IP addresses on a second-by-second basis in order to defeat spammers and DDOS (distributed denial-of-service) attacks.

Edited by rubberman
commented: Ok.Thanks.So its Specific to the ISP +2
Member Avatar for CimmerianX

if you want to deny access, any current prosumer router can block requests to any FQDN.

commented: will work on iptables ? +2
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.