DNS response - combine A and TXT records - dns

Question

I want to resolve an IP address.
For that I'm creating a DNS query (of type A record). Lets say some DNS server gets this query and then send it to one of my servers to resolve it.
Now I want to know which of my servers answer this request.
To do that, I though about adding a TXT record to the response.
Is it possible to add a TXT record to a query with A record?
And is there a better way to discover which of my server answered the request?
EDIT:
As for the server IP -
I have an app, which query a DNS server (lets say it's Google's public DNS server - 8.8.8.8). When Google gets this query, it's not returning the answer, but ask one of my servers for the answer. Only then it will return the correct answer to my app. Now, if I'll check the server IP, I will get 8.8.8.8, but what I want to know is which of my server gave Google the answer.

Answer 1

The client knows which server replied, see this dig example:
$ dig com. #f.root-servers.net +noall +stat
; <<>> DiG 9.12.0 <<>> com. #f.root-servers.net +noall +stat
;; global options: +cmd
;; QUERY SIZE: 44
;; Query time: 140 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Tue Sep 04 12:04:30 EST 2018
;; MSG SIZE rcvd: 856
I see that the server at IP 192.5.5.241 replied to me (this one is anycasted by the way).
Now about
Is it possible to add a TXT record to a query with A record?
No, that is against the specification. The answer section should only have the answer to the query that is the A record. Resolvers are not expected to take into account anything else. You could try/think/imagine using the "Additional" section for that, but it is not fit for it, and again you would have mixed results.
But in fact I am not sure to understand the goal you are trying to reach. Do you control the DNS server? the DNS client?
If you control the DNS server you have access to its logs so you know what it was requested with and who it replied to. If you control the client you see obviously which server replied to you.
Before expanding too much on points that may be irrelevant, look also at the NSID option (RFC5011) this is used today. This is more relevant when you have anycasted nameservers or any cloud of it, as under a single IP you may reach a lot of different instances, so it is important to have something more than the IP to identify them (which shows that an IP address is more of a location than an identication token in fact).
For example if I redo above query with dig com. #f.root-servers.net +nsid +nocookie I now get:
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; NSID: 70 61 6f 31 61 2e 66 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 2e 6f 72 67 ("pao1a.f.root-servers.org")
I see that in that specific case it was a server identifying itself (this can be trivially spoofed of course without DNSSEC) as pao1a.f.root-servers.org.
Doing same query from another vantage point could answer instead with:
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
; NSID: 41 4d 53 2e 63 66 2e 66 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 2e 6f 72 67 (A) (M) (S) (.) (c) (f) (.) (f) (.) (r) (o) (o) (t) (-) (s) (e) (r) (v) (e) (r) (s) (.) (o) (r) (g)
(decoding is different because older dig version)