0

As an experiment, I'd like to get responses from a few different 8.8.8.8 servers (per anycast, multiple physical machines are grouped as one IP address, and I believe inspection of the request/response packet bits alone can not tell me which physical machine was actually used).

(Why the experiment? I imagine that there are brief moments when the responses are different due to network updating. And I imagine responses are often just intentionally different; e.g., 8.8.8.8 is a DNS server, so if I ask it for CNN's IP address, the response probably depends on whether I am in Europe or USA. Further, I could do this experiment with USA CNN's 151.101.1.67, instead of 8.8.8.8, to see if anycast still changes the responding machine when I source a "direct-151.101.1.67-labelled" packet in Europe...I am probably misunderstanding a lot of this, so would simply like to do some experiments.)

So, is there a way for me to modify the packet header/body to force an abnormal 8.8.8.8 server?

If not, it seems I would need multiple worldwide internet source injection points to make the requests (easily done with proxy or VPN, though I am hoping I could inject all packets from one point). I could then use tracert to deduce which 8.8.8.8 server responds. Or, is there a general direct/supported anycast method to distinguish which physical server responded?

2
  • 1
    I think the point you are missing is that anycast is simply unicast, obeying all the unicast rules. Each packet is routed independently by its destination IP address. The real difference is that the Internet routers have multiple paths from which to choose, and they choose one based on how their AS is configured to choose the best path. Should that destination quit advertising, the path is withdrawn, and the next best path is installed in the routing table. Anycast is standard unicast routing taking advantage of multiple paths.
    – Ron Maupin
    Aug 9 '20 at 16:02
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Dec 17 '20 at 19:52
2

Short answer: No. Once a packet leaves your network, you have no control over its path.

2
  • Notice my last paragraph. Though I can't control it per your answer, can I distinguish which server was used after the fact?
    – bobuhito
    Aug 9 '20 at 15:55
  • 1
    @bobuhito No, not unless that server identifies itself on the application level (e.g. by a header) or you can make an educated guess from the delivered data.
    – Zac67
    Aug 9 '20 at 16:01
1

As Ron said: No. But using https://atlas.ripe.net/ might be a good way to conduct your experiment. You also should be looking at EDNS, especially https://en.wikipedia.org/wiki/EDNS_Client_Subnet.

0

In short: you will not really have much control over the path your packets take once they leave your network. While this might be possible with IP Source Routing or Segment Routing, in practice no networks on the Internet allow this functionality.

However, to your last question about being able to identify the DNS sever that handled your request: this is possible with the EDNS0 extension "NSID". When requested in the query, and supported by the server, it enables a place for the server to embed some arbitrary bytes used to identify it.

However, unfortunately, the 8.8.8.8 service doesn't seem to support NSID. However, you can see it in action with other services, like 9.9.9.9 ("Quad9").

For example (notice the response marked from "res210.ams.rrdns.pch.net"):

jof@oak ~ % dig +nsid @9.9.9.9 jof.io

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> +nsid @9.9.9.9 jof.io
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43627
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; NSID: 72 65 73 32 31 30 2e 61 6d 73 2e 72 72 64 6e 73 2e 70 63 68 2e 6e 65 74 ("res210.ams.rrdns.pch.net")
;; QUESTION SECTION:
;jof.io.                IN  A

;; ANSWER SECTION:
jof.io.         300 IN  A   104.31.81.242
jof.io.         300 IN  A   104.31.80.242
jof.io.         300 IN  A   172.67.161.78

;; Query time: 13 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Mon Aug 10 20:13:45 UTC 2020
;; MSG SIZE  rcvd: 111
1
  • Unfortunately, questions about host/server configurations and protocols above OSI layer-4 are explicitly off-topic here.
    – Ron Maupin
    Aug 10 '20 at 20:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.