mesos-dns
mesos-dns copied to clipboard
mesosphere
Proposal: Support PTR records / Generate off of A
Reasoning:
Various ssl implementations (notably java) have issues when trying to connect to ssl enabled servers when no PTR zones can be found.
This can happen regardless whether an actual A record reverse pointer exists or not. Its mostly the zone that matters.
Having PTR records generally can speed up ssl negotiation for other implementations that try a reverse lookup.
Also iirc Hbase/hdfs requires ptr entries as well.
Solution:
Add a PTR map to store reverse PTR records and generate them for every A record from masters. maybe the dns library already supports this.
Also generate zones on say the /18 of every Ipv4 to allow gracefull failure of ptr lookups.
Thoughts?
Actually just read the related and closed issue. Having multiple entries for single dns entry is a bad bad idea.
However id love to see the zone implemented such that stupid implementations dont break. Its not nice i know but there are plenty out there that should be supported regardless imo
@sepiroth887: We should keep in mind that Mesos-DNS is primarily not a DNS zone server.
I am aware of that. However if the intend of mesos-dns is to act as a primary dns and a service discovery mechanism for applications then i do think it should support that feature.
If i do have to keep a dynamically configuring dns server to fullfill that requirement then there is really no reason to use mesos-dns in such a scenario as the dynamic piece would already have to talk to mesos master/zk to work. :(
I am hoping that eventually mesosdns will become the only required app for dns resolution inside a mesos cluster.
I'm not opposed at all to PTR records for all of the A's that we generate.
On Mon, Sep 28, 2015 at 10:46 AM, Tobias Haag [email protected] wrote:
I am aware of that. However if the intend of mesos-dns is to act as a primary dns and a service discovery mechanism for applications then i do think it should support that feature.
If i do have to keep a dynamically configuring dns server to fullfill that requirement then there is really no reason to use mesos-dns in such a scenario as the dynamic piece would already have to talk to mesos master/zk to work. :(
I am hoping that eventually mesosdns will become the only required app for dns resolution inside a mesos cluster.
— Reply to this email directly or view it on GitHub https://github.com/mesosphere/mesos-dns/issues/286#issuecomment-143764310 .
i think the primary reason PTRs themselves could be bad is it may confuse apps looking for certain entries. For ssl it could break the validation if the response FQDN is not part of the cert ( and there is basically a n-1/n chance of that happening if you run n tasks on the same IP)
Not sure how this is solved today with other DNS servers though, I assume CNames?
sounds like PTR's for A records created w/ container IP's (vs. host IPs) might still be useful. it'll take frameworks a bit to catch up with ip-per-container (and not all mesos deployments will want to support it). could be a nice way to test rollout: enabled by default for containers that have their own IPs.
+1 for PTR's for A records created w/container IP's. Here's a real use case: Apache Kafka's zookeeper client does a reverse lookup on the server it is connecting to so it can give a nice name for the thread it's using. It also has a fixed timeout for the connection to be ready. Since nobody will ever resolve the reverse lookup, you're at the mercy of how long it takes the external resolver to fail the lookup. It's a real chore to debug these kinds of problems.
If you have external resolution enabled, your RFC1918 space should be delegated to IANA's blackhole servers.
3c075477e55e:tmp sdhillon$ dig -t NS 10.in-addr.arpa.
; <<>> DiG 9.10.3-P4 <<>> -t NS 10.in-addr.arpa.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63725
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;10.in-addr.arpa. IN NS
;; ANSWER SECTION:
10.in-addr.arpa. 300 IN NS blackhole-1.iana.org.
10.in-addr.arpa. 300 IN NS blackhole-2.iana.org.
;; ADDITIONAL SECTION:
blackhole-1.iana.org. 79334 IN A 192.175.48.6
blackhole-2.iana.org. 79334 IN A 192.175.48.42
;; Query time: 63 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Mon Mar 14 09:00:36 HST 2016
;; MSG SIZE rcvd: 136
PTR Query:
sargun@ircssh:~$ dig @192.175.48.6 1.0.0.10.in-addr.arpa -t PTR
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @192.175.48.6 1.0.0.10.in-addr.arpa -t PTR
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37501
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;1.0.0.10.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
10.in-addr.arpa. 300 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 2002040800 1800 900 604800 604800
;; Query time: 98 msec
;; SERVER: 192.175.48.6#53(192.175.48.6)
;; WHEN: Mon Mar 14 12:02:23 2016
;; MSG SIZE rcvd: 131
More information: https://www.iana.org/help/abuse-answers
xref https://tools.ietf.org/html/rfc6304
On Mon, Mar 14, 2016 at 3:02 PM, Sargun Dhillon [email protected] wrote:
If you have external resolution enabled, your RFC1918 space should be delegated to IANA's blackhole servers.
3c075477e55e:tmp sdhillon$ dig -t NS 10.in-addr.arpa.
; <<>> DiG 9.10.3-P4 <<>> -t NS 10.in-addr.arpa. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63725 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;10.in-addr.arpa. IN NS
;; ANSWER SECTION: 10.in-addr.arpa. 300 IN NS blackhole-1.iana.org. 10.in-addr.arpa. 300 IN NS blackhole-2.iana.org.
;; ADDITIONAL SECTION:blackhole-1.iana.org. 79334 IN A 192.175.48.6blackhole-2.iana.org. 79334 IN A 192.175.48.42
;; Query time: 63 msec ;; SERVER: 4.2.2.1#53(4.2.2.1) ;; WHEN: Mon Mar 14 09:00:36 HST 2016 ;; MSG SIZE rcvd: 136
PTR Query:
sargun@ircssh:~$ dig @192.175.48.6 1.0.0.10.in-addr.arpa -t PTR
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @192.175.48.6 1.0.0.10.in-addr.arpa -t PTR ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37501 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available
;; QUESTION SECTION: ;1.0.0.10.in-addr.arpa. IN PTR
;; AUTHORITY SECTION: 10.in-addr.arpa. 300 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 2002040800 1800 900 604800 604800
;; Query time: 98 msec ;; SERVER: 192.175.48.6#53(192.175.48.6) ;; WHEN: Mon Mar 14 12:02:23 2016 ;; MSG SIZE rcvd: 131
— Reply to this email directly or view it on GitHub https://github.com/mesosphere/mesos-dns/issues/286#issuecomment-196475226 .
reverse DNS for hosts is also a requirement for Hadoop. See http://sequenceiq.com/cloudbreak-docs/latest/mesos/
We have this problem with mesos-DNS and hadoop as well. Reverse PTR generation should be toggleable, since there are no conflicts when running in an IP-per-workload configuration.
