Question: Support of the Additional Section in the answer

[spotify]

Question: Support of the Additional Section in the answer

[pettermahlen]

You're right that there's no way to get hold of anything from the Additional section of the response.

The additional section is defined as "the additional records section contains RRs
which relate to the query, but are not strictly answers for the
question." (https://www.ietf.org/rfc/rfc1035.txt, section 4.1). As such, it's an optimisation. If I understand the mesos issue thread correctly, the response in question contains the data to the SRV query, which is an A record, a port, weight, etc., and also a response to an A record query for the name returned in the SRV query response. It's an attempt by the DNS server to enable the client to not make additional queries, and it won't always get returned. So if the server that is authoritative for the SRV name is not authoritative for the A name pointed to by the SRV record, it is unlikely to return the A record result in the additional section.

I don't think it's necessary or desirable to return the Additional section in this API. A client can get the same results by doing:

1. Query for the SRV record
2. Query for the A record that is returned

The results of the second query are likely to be cached, so that lookup will be fast. Also, see http://tools.ietf.org/html/rfc2181#section-5.4.1 for some reasoning around whether DNS caches/clients should trust data in the Additional section.

[tobilg]

Thanks a lot for your very fast and detailled answer. While I think that for the case Mesos DNS the DNS server should be authorative concerning both SRV and A records, you're still correct with the points mentioned.

As Mesos/Marathon apps/frameworks can be scaled to a lot of instances, I wanted to avoid the downsides of making A record requests for every service record returned. Even if they'd take 1ms each, there could be some potential latency gain when more instances are run IMHO.

[tzeH]

I was interested in the same thing because Consul has some corner cases where I can't split the request in two.
This is in a case, where a service has its own ip and its own, random, port. When I query the server, only the combination of ip and port is meaningful. But every time I ask the server it gives me a different answer, since it is using round-robin for load-balancing.
With two requests, I would get the port for one service instance and with the second query I would get the ip for another. The combination however points to nothing.
I can work around this, but at the moment it would be a nice option to get the ip from the "additional section".

[pettermahlen]

Hm, I'm not sure I understand your comment @tzeH. Could you provide some more details/examples on what exactly Consul returns? Some background on my thinking: the SRV query will return one or more A record + port combinations. The A record query may return multiple IP addresses. It is common practice to return those IP addresses in varying order so as to enable round-robin load balancing.

What you're describing sounds a little odd, and like it might break in the presence of caching A record responses, and caching is very near the core of what DNS is about. Maybe I'm misunderstanding?

[tobilg]

Not sure what Consul returns, but coming back to my original question, Mesos DNS return something like the following:

$ dig _inf-elasticsearch._tcp.marathon.mesos. SRV @192.168.200.161
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.8.3-P1 <<>> _inf-elasticsearch._tcp.marathon.mesos. SRV @192.168.200.161
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48481
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 6

;; QUESTION SECTION:
;_inf-elasticsearch._tcp.marathon.mesos.    IN SRV

;; ANSWER SECTION:
_inf-elasticsearch._tcp.marathon.mesos. 60 IN SRV 0 0 31418 inf-elasticsearch-oweft-s0.marathon.slave.mesos.
_inf-elasticsearch._tcp.marathon.mesos. 60 IN SRV 0 0 31732 inf-elasticsearch-7u45u-s1.marathon.slave.mesos.
_inf-elasticsearch._tcp.marathon.mesos. 60 IN SRV 0 0 31151 inf-elasticsearch-chk48-s2.marathon.slave.mesos.
_inf-elasticsearch._tcp.marathon.mesos. 60 IN SRV 0 0 31417 inf-elasticsearch-oweft-s0.marathon.slave.mesos.
_inf-elasticsearch._tcp.marathon.mesos. 60 IN SRV 0 0 31733 inf-elasticsearch-7u45u-s1.marathon.slave.mesos.
_inf-elasticsearch._tcp.marathon.mesos. 60 IN SRV 0 0 31152 inf-elasticsearch-chk48-s2.marathon.slave.mesos.

;; ADDITIONAL SECTION:
inf-elasticsearch-oweft-s0.marathon.slave.mesos. 60 IN A 192.168.200.161
inf-elasticsearch-oweft-s0.marathon.slave.mesos. 60 IN A 192.168.200.161
inf-elasticsearch-chk48-s2.marathon.slave.mesos. 60 IN A 192.168.200.163
inf-elasticsearch-chk48-s2.marathon.slave.mesos. 60 IN A 192.168.200.163
inf-elasticsearch-7u45u-s1.marathon.slave.mesos. 60 IN A 192.168.200.162
inf-elasticsearch-7u45u-s1.marathon.slave.mesos. 60 IN A 192.168.200.162

;; Query time: 1 msec
;; SERVER: 192.168.200.161#53(192.168.200.161)
;; WHEN: Mon Mar 21 09:10:19 2016
;; MSG SIZE  rcvd: 650

The actual mapping of hosts/ips to the ports is done by matching the hostname from the answer section (for the ports) to the hostname of the additional section (for the ips).

[huntc]

@tobilg Those answers should be relatively static though right? inf-elasticsearch-oweft-s0.marathon.slave.mesos should only ever resolve to one thing.

[tobilg]

@huntc I guess you're right, but I closed the issue long ago (because of apparently "Won't fix"/"Works as designed"). We ended up implementing our own solution in Java and JS (https://github.com/tobilg/mesosdns-client).