Serve PTR records for unambiguous tasks

[christian-marie]

Hi, we (a team at Commonwealth Bank) are trying to roll out a HDFS cluster on top of Mesos. This seems to require reverse DNS to be properly configured for tasks, and this seemed the most convenient place to add PTR records.

This patch is currently only unit tested, I'll be integration testing tomorrow.

This may be of interest to #286 and #67 (closed).

[mesosphere-ci]

Can one of the admins verify this patch?

[jdef]

ok to test

On Wed, Oct 12, 2016 at 10:08 PM, Mesosphere CI Robot < notifications@github.com> wrote:

Can one of the admins verify this patch?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mesosphere/mesos-dns/pull/481#issuecomment-253392594, or mute the thread https://github.com/notifications/unsubscribe-auth/ACPVLNl3i1noGW70nzRjm8YTWp0o4T0Dks5qzZKCgaJpZM4KVZ9y .

[christian-marie]

Update: Handlers needed to be set up for these reverse records (obviously).

Tested to work in practice now (very ad-hoc testing, redacted):

$ dig aaa.bb.cc.dd.in-addr.arpa. -tptr @localhost

; <<>> DiG 9.10.3-P4-Ubuntu <<>> aaa.bb.cc.dd.in-addr.arpa. -tptr @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29836
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;aaa.bb.cc.dd.in-addr.arpa. IN  PTR

;; ANSWER SECTION:
aaa.bb.cc.dd.in-addr.arpa. 15   IN  PTR task-name.domain.

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Oct 17 05:08:54 UTC 2016
;; MSG SIZE  rcvd: 93

[christian-marie]

@jdef I'm pretty happy with this now, does it seem workable?

[jdef]

last time that @sargun and I discussed PTR records there was some concern about mesos-dns being responsible for ALL PTR-resolution and that it would break in enterprise environments. We really didn't have a strong plan for delegation of PTR resolution. There's at least one RFC that tries to tackle this. And a quick google search turns up existing documentation for other DNS apps w/ respect to PTR delegation, e.g. http://www.zytrax.com/books/dns/ch9/reverse.html . I suspect that a more robust solution would be needed long term if we intent to fully support PTR resolution in reasonably sized clusters within an enterprise context.

I have no problem with mesos-dns supporting PTR resolver functionality, as implemented, as long as it defaults to "off" (seems to be the case for this PR) and comes with a strong warning in the docs that this is a highly experimental feature and enabling it could break anything but the most simple mesos clusters.

[christian-marie]

Ok. I'll add some experimental flags and docs today.

[christian-marie]

Rebased, WIP removed.

[christian-marie]

P.S. Some docs added.

[sargun]

Is there a SOA for the PTR zone?

[christian-marie]

Not sure what you mean. If you can modify the test to demonstrate, that would hep.

[mesosphere-ci]

Can one of the admins verify this patch?

[christian-marie]

Good day sirs

[mesosphere-ci]

Can one of the admins verify this patch?

[jdef]

closing this out since the OP is no longer interested in this and we haven't needed it yet for DC/OS. please re-open if this is being closed in error.