1.1.1.1 has wrong IP when getting DNS for certain websites

#1

I use CloudFlare’s DNS, i.e. 1.1.1.1 and 1.0.0.1.
Since today I have issues connecting to https://www.rei.com.

Checking with dig it seems that 1.1.1.1 returns a different IP than for example the competitors:

dig @1.1.1.1 www.rei.com A

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> @1.1.1.1 www.rei.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58149
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;www.rei.com.                   IN      A

;; ANSWER SECTION:
www.rei.com.            1072    IN      CNAME   www.rei.com.edgekey.net.
www.rei.com.edgekey.net. 5      IN      CNAME   e739.a.akamaiedge.net.
e739.a.akamaiedge.net.  20      IN      A       104.87.142.13

;; Query time: 14 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sat Dec 28 14:56:21 PST 2019
;; MSG SIZE  rcvd: 125

Versus your competitor:

dig @8.8.8.8 www.rei.com A

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> @8.8.8.8 www.rei.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18909
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.rei.com.                   IN      A

;; ANSWER SECTION:
www.rei.com.            3496    IN      CNAME   www.rei.com.edgekey.net.
www.rei.com.edgekey.net. 110    IN      CNAME   e739.a.akamaiedge.net.
e739.a.akamaiedge.net.  8       IN      A       23.7.135.149

;; Query time: 13 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Dec 28 14:56:07 PST 2019
;; MSG SIZE  rcvd: 125

Connecting to the website with CloudFlare’s DNS gives issues.

/usr/local/bin/wget --delete-after --dns-servers=1.1.1.1 --tries=1 http://rei.com
--2019-12-28 14:39:19--  http://rei.com/
Resolving rei.com (rei.com)... 69.192.138.229
Connecting to rei.com (rei.com)|69.192.138.229|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.rei.com/ [following]
--2019-12-28 14:39:19--  https://www.rei.com/
Resolving www.rei.com (www.rei.com)... 104.87.142.13
Connecting to www.rei.com (www.rei.com)|104.87.142.13|:443... failed: Connection timed out.
Giving up.

With the competitor:

/usr/local/bin/wget --delete-after --dns-servers=8.8.8.8 --tries=1 http://rei.com
--2019-12-28 15:51:16--  http://rei.com/
Resolving rei.com (rei.com)... 23.196.195.206
Connecting to rei.com (rei.com)|23.196.195.206|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.rei.com/ [following]
--2019-12-28 15:51:16--  https://www.rei.com/
Resolving www.rei.com (www.rei.com)... 104.70.204.186
Connecting to www.rei.com (www.rei.com)|104.70.204.186|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.tmp’

index.html.tmp             [ <=>                        ] 236.69K  --.-KB/s    in 0.05s

2019-12-28 15:51:16 (4.61 MB/s) - ‘index.html.tmp’ saved [242374]

Removing index.html.tmp.

Not sure if it’s a TTL issue, or a wrong configuration.

Same issues for:

http://checkcoverage.apple.com
and
http://bloomingdales.com

#2

Cloudflare actually properly resolves www.rei.com (as a CNAME). The problem is with the host it points to, which Google resolves to 23.7.135.149 and Cloudflare to 104.87.142.13.

Both addresses are Akamai addresses, so I would assume both run the same service, however the 23 address is probably geographically closer to you and 104 the default address. This is because Cloudflare does not reveal your network to the authoritative resolver (it does not support ECS) and hence Akamai responds with a default address.

https://community.cloudflare.com/search?q=ecs%20subnet has more on that

#3

So why does the connection with Cloudflare DNS fail, but the one with Google DNS connect?

1 Like
#4

That is a question for Akamai :wink:

Though, there is one issue with the OP’s test. He checked rei.com, not www.rei.com. The naked domain actually redirects to “www”, however this is where the interesting part happens. The check with Google also returns a 104 address in this case and not the 23 one (though a different one), my assumption would be wget might not use the specified resolver for the resolution of redirects.

2 Likes
#5

Also also, rei.com resolves for me on both services to “172.227.83.148” whereas it resolves differently for the OP.

1 Like
#6

I did see the 301, but assume (usually a bad idea) that it retains the DNS flag.

Yes, a better test would be to www to avoid the redirect.

2 Likes
#7

I am still sure this is the usual ECS issue, but @user2075, can you post the output of these commands?

nslookup rei.com 8.8.8.8
nslookup rei.com 1.1.1.1

nslookup www.rei.com 8.8.8.8
nslookup www.rei.com 1.1.1.1

nslookup -type=cname www.rei.com 8.8.8.8
nslookup -type=cname www.rei.com 1.1.1.1

nslookup -type=cname www.rei.com.edgekey.net 8.8.8.8
nslookup -type=cname www.rei.com.edgekey.net 1.1.1.1

nslookup e739.a.akamaiedge.net 8.8.8.8
nslookup e739.a.akamaiedge.net 1.1.1.1

nslookup -class=chaos -type=txt id.server 1.1.1.1
1 Like
#8

At least the issue with the naked domain can be explained with the authoritative resolvers. All but edns3.ultradns.biz return 104.91.73.201, with the former returning 23.196.6.32.

So there definitely is some issue with the domain’s configuration too, however that doesnt explain the “www” record, which I’d still attribute to ECS.

1 Like
#9

Upon a second check the .biz server returned 104.111.222.250, all others 104.107.34.128.

We now have at least four different addresses. Either someone is playing with the configuration as we speak or the servers are not synchronised.

@user2075, apart from the possible ECS issue, the domain owner should definitely look into that too.

2 Likes
#10

To summarise

  • The “www” record seems to be properly configured and is a double CNAME. IMHO the issue here will be ECS

  • The naked domain returns a variety of addresses, both on Google, Cloudflare, and the authoritative servers. Either someone is currently making changes or the servers are not in-sync or there is some obscure load balancing going on, possibly coupled with ECS as well.

    So far I seem to have got all these addresses for the naked domain

    • 23.79.216.58
    • 23.196.6.32
    • 84.53.159.250
    • 104.91.73.201
    • 104.107.34.128
    • 104.111.222.250
    • 172.227.83.148

I havent checked in detail and assume their naked domains are consistent, but the Apple record as well as the “www” record of Bloomingdale’s both have the same Akamai CNAME setup, which I’d file as ECS issue again.

1 Like
#11 
C:\Users\<TRIMMED>>nslookup rei.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    rei.com
Address:  23.214.246.124


C:\Users\<TRIMMED>>nslookup rei.com 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    rei.com
Address:  23.214.246.124


C:\Users\<TRIMMED>>
C:\Users\<TRIMMED>>nslookup www.rei.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    e739.a.akamaiedge.net
Address:  104.117.147.151
Aliases:  www.rei.com
          www.rei.com.edgekey.net


C:\Users\<TRIMMED>>nslookup www.rei.com 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    e739.a.akamaiedge.net
Address:  104.87.142.13
Aliases:  www.rei.com
          www.rei.com.edgekey.net


C:\Users\<TRIMMED>>
C:\Users\<TRIMMED>>nslookup -type=cname www.rei.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
www.rei.com     canonical name = www.rei.com.edgekey.net

C:\Users\<TRIMMED>>nslookup -type=cname www.rei.com 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
www.rei.com     canonical name = www.rei.com.edgekey.net

C:\Users\<TRIMMED>>
C:\Users\<TRIMMED>>nslookup -type=cname www.rei.com.edgekey.net 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
www.rei.com.edgekey.net canonical name = e739.a.akamaiedge.net

C:\Users\<TRIMMED>>nslookup -type=cname www.rei.com.edgekey.net 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
www.rei.com.edgekey.net canonical name = e739.a.akamaiedge.net

C:\Users\<TRIMMED>>
C:\Users\<TRIMMED>>nslookup e739.a.akamaiedge.net 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    e739.a.akamaiedge.net
Address:  104.117.147.151


C:\Users\<TRIMMED>>nslookup e739.a.akamaiedge.net 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    e739.a.akamaiedge.net
Address:  104.87.142.13


C:\Users\<TRIMMED>>
C:\Users\<TRIMMED>>nslookup -class=chaos -type=txt id.server 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
id.server       text =

        "LAX"

Unfortunately this means that I cannot use Cloudflare, as it is unreliable. Well, Akamai responds with the wrong stuff, but I cannot control that :frowning:

1 Like
#12

Yes, your output is what was expected.

As mentioned, technically, Cloudflare resolves www.rei.com just fine. The issue is with its eventual target e739.a.akamaiedge.net which is resolved to different IP addresses. I strongly believe that this is an ECS issue but cannot definitively confirm it, for that you might want to contact support.

However the naked domain still resolves randomly. Your output showed Google and Cloudflare resolved to the same address in this instance (23.214.246.124), even though Google resolved it earlier to “23.196.195.206” and Cloudflare to “69.192.138.229”.

IMHO there is an overall DNS configuration issue with that domain.

2 Likes