| *** artom has joined #openstack-dns | 00:21 | |
| *** artom has quit IRC | 00:22 | |
| *** CaptTofu has joined #openstack-dns | 00:24 | |
| *** matsuhashi has joined #openstack-dns | 00:25 | |
| *** CaptTofu has quit IRC | 00:28 | |
| *** jmcbride has joined #openstack-dns | 00:45 | |
| *** jmcbride has quit IRC | 00:46 | |
| *** jorgem has joined #openstack-dns | 00:56 | |
| *** nosnos has joined #openstack-dns | 00:57 | |
| *** nosnos has quit IRC | 01:01 | |
| *** nosnos has joined #openstack-dns | 01:01 | |
| *** jorgem has quit IRC | 01:16 | |
| *** nkinder has joined #openstack-dns | 01:19 | |
| *** CaptTofu has joined #openstack-dns | 01:32 | |
| *** nkinder has quit IRC | 01:51 | |
| *** elemecca has quit IRC | 02:25 | |
| *** jmcbride has joined #openstack-dns | 02:36 | |
| *** jmcbride has quit IRC | 02:41 | |
| *** jmcbride has joined #openstack-dns | 02:42 | |
| *** CaptTofu has quit IRC | 02:53 | |
| *** CaptTofu has joined #openstack-dns | 02:55 | |
| *** jmcbride has quit IRC | 03:01 | |
| *** vinod has joined #openstack-dns | 03:56 | |
| *** CaptTofu has quit IRC | 04:09 | |
| *** CaptTofu has joined #openstack-dns | 04:09 | |
| *** CaptTofu has quit IRC | 04:14 | |
| *** rossk has joined #openstack-dns | 04:21 | |
| *** rossk has quit IRC | 06:15 | |
| *** rossk has joined #openstack-dns | 06:16 | |
| *** rossk has quit IRC | 06:19 | |
| *** rossk has joined #openstack-dns | 06:20 | |
| *** rossk has quit IRC | 06:56 | |
| *** rossk has joined #openstack-dns | 06:57 | |
| *** rossk has quit IRC | 07:01 | |
| *** vinod has quit IRC | 07:06 | |
| *** nkinder has joined #openstack-dns | 08:02 | |
| *** rossk has joined #openstack-dns | 08:07 | |
| *** CaptTofu has joined #openstack-dns | 08:11 | |
| *** rossk has quit IRC | 08:12 | |
| *** CaptTofu has quit IRC | 08:16 | |
| *** matsuhashi has quit IRC | 08:54 | |
| *** matsuhashi has joined #openstack-dns | 08:55 | |
| *** CaptTofu has joined #openstack-dns | 10:12 | |
| *** CaptTofu has quit IRC | 10:16 | |
| *** nosnos has quit IRC | 10:53 | |
| *** krow has quit IRC | 10:57 | |
| *** timfreund has quit IRC | 11:13 | |
| *** timfreund has joined #openstack-dns | 11:35 | |
| *** CaptTofu has joined #openstack-dns | 12:07 | |
| *** timfreund has quit IRC | 12:08 | |
| *** CaptTofu has quit IRC | 12:36 | |
| *** CaptTofu has joined #openstack-dns | 12:36 | |
| *** CaptTofu has quit IRC | 12:41 | |
| *** artom has joined #openstack-dns | 13:02 | |
| *** CaptTofu has joined #openstack-dns | 13:17 | |
| *** vinod has joined #openstack-dns | 13:43 | |
| *** vinod has quit IRC | 13:43 | |
| *** CaptTofu has quit IRC | 13:46 | |
| *** vinod has joined #openstack-dns | 13:49 | |
| *** zigo_ is now known as zigo | 13:50 | |
| *** CaptTofu has joined #openstack-dns | 13:50 | |
| *** vinod has quit IRC | 14:03 | |
| *** eankutse has joined #openstack-dns | 14:12 | |
| *** eankutse has quit IRC | 14:13 | |
| *** eankutse has joined #openstack-dns | 14:14 | |
| *** msisk has joined #openstack-dns | 14:59 | |
| *** vinod has joined #openstack-dns | 15:00 | |
| *** vinod1 has joined #openstack-dns | 15:03 | |
| *** vinod has quit IRC | 15:05 | |
| *** matsuhashi has quit IRC | 15:17 | |
| *** matsuhashi has joined #openstack-dns | 15:18 | |
| *** jmcbride has joined #openstack-dns | 15:31 | |
| *** vinod1 has quit IRC | 15:33 | |
| *** matsuhashi has quit IRC | 15:34 | |
| *** jmcbride has quit IRC | 15:34 | |
| *** richm has joined #openstack-dns | 15:38 | |
| *** harmw has joined #openstack-dns | 15:39 | |
| *** jmcbride has joined #openstack-dns | 15:40 | |
| *** jmcbride has quit IRC | 15:51 | |
| *** jmcbride has joined #openstack-dns | 15:52 | |
| *** vinod has joined #openstack-dns | 16:06 | |
| *** jmcbride has quit IRC | 16:06 | |
| *** jmcbride has joined #openstack-dns | 16:10 | |
| *** vinod has quit IRC | 16:16 | |
| *** msisk has quit IRC | 16:17 | |
| *** artom has quit IRC | 16:21 | |
| *** rossk has joined #openstack-dns | 16:29 | |
| *** vinod has joined #openstack-dns | 16:32 | |
| *** eankutse1 has joined #openstack-dns | 16:36 | |
| *** eankutse1 has quit IRC | 16:36 | |
| *** eankutse has quit IRC | 16:38 | |
| *** rossk has quit IRC | 16:41 | |
| *** rossk has joined #openstack-dns | 16:42 | |
| *** rossk has quit IRC | 16:46 | |
| *** CaptTofu has quit IRC | 16:48 | |
| vinod | I updated some of the agenda items for today's irc meeting. If anybody else has additional items feel free to add at https://wiki.openstack.org/wiki/Meetings/Designate#Agenda | 16:48 |
|---|---|---|
| *** jorgem has joined #openstack-dns | 16:49 | |
| openstackgerrit | Lukasz Jernas proposed a change to stackforge/designate: Various small fixes to documentation https://review.openstack.org/71310 | 16:55 |
| *** artom has joined #openstack-dns | 16:57 | |
| vinod | designate meeting to start on #openstack-meeting-alt in a few minutes | 17:02 |
| *** timfreund has joined #openstack-dns | 17:04 | |
| *** betsy has joined #openstack-dns | 17:04 | |
| *** eankutse has joined #openstack-dns | 17:05 | |
| *** msisk_ has joined #openstack-dns | 17:10 | |
| *** CaptTofu has joined #openstack-dns | 17:33 | |
| *** rossk has joined #openstack-dns | 17:34 | |
| *** DeeJay1 has joined #openstack-dns | 17:41 | |
| openstackgerrit | A change was merged to stackforge/designate: Various small fixes to documentation https://review.openstack.org/71310 | 17:50 |
| DeeJay1 | yay, thanks betsy | 17:52 |
| *** eankutse has quit IRC | 17:59 | |
| richm | To me, looking at the current state of the designate design, was that designate was basically a rest + mq frontend to whatever backend DNS you wanted to use | 18:01 |
| *** nkinder has quit IRC | 18:01 | |
| richm | Not "all your base are belong to designate" | 18:01 |
| kiall | Heya :) Sorry for only joining the last 5 mins there, holidays and woo :) | 18:01 |
| betsy | kiall: No problem | 18:01 |
| kiall | richm: While technically, yes, it's currently possible to mix designate managed and other zones together, that's never been a goal. | 18:02 |
| kiall | Whenever we have a choice between allowing mix+match of designate managed vs unmanaged, and a simpler mechanism that only allows designate managed, we tend to choose the latter | 18:02 |
| vinod | the problem with mix+match would be that using the rest api, we would see only the designate portion | 18:03 |
| vinod | also who would be single source of truth | 18:03 |
| kiall | Anyway - My theory's of MS AD DNS is that we can support it, just not quite the way that might be the most obvious way to do it.. For example.. | 18:03 |
| richm | vinod: not sure what you mean | 18:04 |
| kiall | company.com + _msdcs.company.com .. company.com would be a traditional designate zone, while _msdcs.company.com would be setup as a secondary zone, AXFR'ing from MS DNS | 18:04 |
| vinod | designate would have only the domains/records that it manages, while i assume AD would have the rest or all of them | 18:05 |
| kiall | at that point, everything is in mini-dns, and whatever backend is chosen will serve the zones. | 18:05 |
| kiall | That backend could be MS AD DNS | 18:05 |
| richm | I guess I don't understand what would be in designate that would not be in MS DNS | 18:05 |
| betsy | kiall: And when you say "is in mini-dns" you actually mean Central's storage, right? | 18:05 |
| kiall | betsy: yep | 18:06 |
| richm | I mean, if a company is using MS AD for their entire corporate DNS, what is in the company but outside of that? | 18:06 |
| kiall | richm: If a company is using MS AD for their DNS, putting designate on top won't help them in any way - unless they migrate the zones to be under designates control. | 18:07 |
| kiall | Designates design is such that the Designate database, rather than the DNS server, is the single source of truth. | 18:07 |
| kiall | The is the opposite of, e.g. Neutron, where the switches etc are the source of truth. | 18:07 |
| *** jmcbride1 has joined #openstack-dns | 18:07 | |
| richm | ok - that's going to be a non-starter for some of our customers, who will expect designate to be just a rest + mq frontend for their DNS | 18:07 |
| kiall | So - If Designate was layered on top of MS AD DNS, and mixing designate managed + unmanaged zones is supported, existing zones would still be invisible via the API. | 18:08 |
| *** jmcbride has quit IRC | 18:08 | |
| richm | I still don't understand - if a company is using MS AD for their entire corporate DNS, what is in the company but outside of that? What zone would be unmanaged by the corporate DNS? | 18:09 |
| *** jmcbride1 has quit IRC | 18:10 | |
| kiall | richm: Well, exactly, if everything is MS AD hosted, and they are unwilling to migrate those zones, then they get no benefit to using Designate. Put in another context, if an entire company is running in Hyper-V, and that company is unwilling to migrate those VMs to Nova's control (using Hyper-V as the virt layer) they get zero benefit to installing Nova. | 18:11 |
| richm | ok, let me ask this in another way - if we have a fully functional DNS backend, that can do every sort of CRUD operation possible with the DNS master server, why does designate need to be the master of that DNS data? | 18:13 |
| kiall | I think we're actually on a path that leads us to a better position that Nova has in that story above. Where, eventually, we support inbound AXFR's, and can as a result, import those pre-existing zones and distribute them over the Designate managed namservers. Allowing a slow or partial migration. | 18:13 |
| kiall | richm: When you say "master", are you referring to a DNS master or source of truth? | 18:14 |
| richm | the source of truth | 18:14 |
| richm | where the source of truth is e.g. the existing corporate DNS server(s) | 18:15 |
| *** jmcbride has joined #openstack-dns | 18:16 | |
| kiall | crappy hotel wifi -_- | 18:16 |
| artom | Better than creepy hotel wifi ;) | 18:17 |
| kiall | Okay - So Designate made the choice that it would be the source of truth for all data, it's design is such that making the DNS server the source of truth would be hard.. | 18:17 |
| kiall | The disadvantages to letting the DNS server be the source of truth are scaling (easier to scale a DB than scaling the reads of BIND9 zonefiles off a single master server), ability to store and manage non traditional DNS data - for example tenant_id's etc | 18:18 |
| kiall | and - the application becomes much more complex, as essentially the whole thing exists in a DNS server specific plugin | 18:19 |
| betsy | Our (Rackspace's) use case also calls for Designate to be the source of truth | 18:19 |
| richm | I can understand that bind + zonefile performance is bad | 18:20 |
| richm | I can understand that minidns makes implementation much, much easier | 18:20 |
| kiall | betsy: I think most DNS providers would agree with that, the difficulty is balancing what we as providers want with what enterprise wants :) | 18:20 |
| *** krow has joined #openstack-dns | 18:20 | |
| richm | I can understand that Designate will have to store things outside of the DNS server | 18:20 |
| richm | But all of these things are solvable in other ways, perhaps not as elegantly | 18:21 |
| kiall | Anyway - Making MS AD the source of truth is doable.. A storage plugin that mixed a SQL DB (or w/e) with MS AD would work | 18:21 |
| kiall | At that point, you would just have a no-op DNS backend plugin, as the write the storage replaces it | 18:22 |
| kiall | brb - have to run down to the hotel lobby. Will be 5 mins. | 18:22 |
| *** jmcbride1 has joined #openstack-dns | 18:23 | |
| richm | I guess the Rackspace model is that since Rackspace hosts everything, including DNS, the customer really doesn't care, and has no idea, about the underlying DNS? | 18:23 |
| vinod | yes that is correct | 18:24 |
| richm | And since you guys are struggling daily with bind performance + manageability, you are really wanting a much better DNS implementation? | 18:24 |
| *** jmcbride has quit IRC | 18:25 | |
| richm | and latency (the time between when you tell Designate to add a record and the time when a client can actually query a record) is not an issue because . . .? | 18:26 |
| vinod | our current implementation has several different pieces managed by different groups with some of the pieces not being actively maintained. designate would make it easier to manage | 18:27 |
| *** elemecca has joined #openstack-dns | 18:28 | |
| ekarlso | ello folks | 18:28 |
| vinod | rich when you say the client querying a record - do you mean querying through the rest api or getting to the record by having the address etc. resolved | 18:29 |
| vinod | ekarlso: hello | 18:30 |
| kiall | back | 18:31 |
| ekarlso | what's up ? | 18:32 |
| kiall | richm: so, anyway, I don't think mini-dns or any of the other changes preclude using MS AD DNS, or even having MS AD DNS as the source of truth. it's just simply not something we've been working towards. | 18:32 |
| richm | ok | 18:33 |
| richm | that's fine | 18:33 |
| artom | kiall, well, mini-dns kinda would though, no? | 18:33 |
| kiall | If MS AD *must* be the source of trust, and a slow migration of the non AD managed zones (i.e. everything but the _msdcs.* zones) is unacceptable, then building a storage driver that talks to MS AD DNS should always be doable | 18:33 |
| artom | Unless you make it optional... | 18:33 |
| artom | Or disable-able... | 18:34 |
| artom | Which I guess it will be, if it's just a separate service... | 18:34 |
| kiall | mini-dns would always be "optional" if your storage driver talked straight to the DNS servers. The back half of the system would just be unused.. | 18:35 |
| kiall | There would probably be some quirks around handling of pools etc | 18:35 |
| kiall | But - At a single enterprise scale, pools are likely unnecessary | 18:35 |
| artom | But the API would have them... | 18:35 |
| artom | So you're exposing a concept that doens't actually exist in the back half... | 18:36 |
| kiall | Yep - The custom storage driver would need to handle the quriks, e.g. sharding across multiple storage drivers based on the pool ID | 18:36 |
| kiall | (e.g. pool #1 = MS AD DNS backed, pool #2+ = Standard SQL storage driver with BIND/PowerDNS etc) | 18:36 |
| artom | Weirdness all around then ;) | 18:37 |
| richm | Indeed | 18:37 |
| kiall | artom: yep - weirdness, but workable :) | 18:37 |
| richm | I would just like it to be _possible_, not necessarily easy, to use designate with other-DNS-server-as-source-of-truth | 18:38 |
| artom | I think my gf said that of me once ;) | 18:38 |
| artom | richm, I think what kiall just explained is basically it... | 18:38 |
| richm | I mean, isn't that how it works, right now, without minidns? | 18:38 |
| kiall | richm: The current storage layer would make it workable without core changes. I don't foresee any major changes to that layer which would make it impossible. | 18:38 |
| kiall | richm: no, we never "read" from the DNS server's - Only ever our own database | 18:39 |
| richm | ah, I see | 18:40 |
| kiall | Anyway - Making MS AD DNS the source of truth is doable, just not what we've designed for. | 18:41 |
| *** jmcbride1 has quit IRC | 18:41 | |
| kiall | That said - The storage layer is probably pretty close to what it might look like if we designed for it.. | 18:41 |
| kiall | The difference probably being there would be a split in the storage layer between DNS and non-DNS data | 18:41 |
| richm | makes sense | 18:42 |
| *** jmcbride has joined #openstack-dns | 18:42 | |
| kiall | So - have you been seeing demand for MS AD as the source of truth, or just general predictions? | 18:43 |
| richm | We have had some customers that wanted IPA to use MS AD as the source of truth | 18:45 |
| kiall | ekarlso: heya - hows santa clara? | 18:45 |
| kiall | richm: interesting - was that something you guys solved in IPA? | 18:45 |
| richm | Even though they had to manually configure MS DNS for ldap records, kerberos, etc. | 18:45 |
| richm | If by "solving" you mean "giving the customer a list of manual steps they had to do to configure their DNS properly so that IPA would work" then yes | 18:46 |
| ekarlso | kiall: lots of cool stuff | 18:46 |
| richm | Not just AD, but other DNS servers as well | 18:46 |
| kiall | Ah - Okay, so setting up the IPA equivalent of the _msdcs zone? | 18:46 |
| ekarlso | a ta talk on Intel DPDK vSwitch atm | 18:47 |
| richm | kiall: sort of, except that I don't think there is anything like an _ipa zone | 18:48 |
| kiall | Yea - MS AD is weird in that sense, but the records within are all about discovering the LDAP/Krb/etc servers local to your site.. | 18:49 |
| richm | IPA needs _ldap records, SRV records for kerberos, etc. | 18:50 |
| richm | not familiar with _msdcs zone, will have to read up on that | 18:51 |
| kiall | Anyway - I think that's a little different, in that the equivalent to MS AD DNS being the source of truth for Designate would be MS AD being the source of truth for IPA's Users/Groups/Computers etc | 18:51 |
| kiall | richm: it's filled with SRV records for the various servers.. Just structured in a way that lets you find the AD server in your building, rather than the "global" one | 18:51 |
| richm | ok | 18:51 |
| kiall | And .. Think my internet is dud again | 18:52 |
| richm | There are IPA customers who do want AD to be the authoritative source of user/group data | 18:52 |
| kiall | http://standalonelabs.wordpress.com/2011/05/08/what-is-the-_msdcs-subdomain/ | 18:53 |
| kiall | richm: I'm sure there are :) But did IPA implement that? :) | 18:53 |
| richm | kiall: yes, reading that now | 18:53 |
| richm | IPA provides a sync from AD, which would be something like an AXFR+IXFR | 18:53 |
| richm | IPA can also (or will shortly) be able to do a kerberos cross domain trust with AD | 18:54 |
| richm | which would be something like splitting things into two different zones/subzones | 18:54 |
| richm | in the sync case, AD is still master of the data, where the updates go, and IPA is just a shadow read-only copy of the user/group data | 18:56 |
| kiall | Yea, The sync model is as you say essentially the inbound AXFR to designate model.. The trust model is just standard DNS | 18:56 |
| richm | so could we have minidns used as a slave of the corp dns? | 18:57 |
| richm | is that what you mean by inbound AXFR? | 18:57 |
| *** elemecca has quit IRC | 18:59 | |
| kiall | (Both of those are things that have been talked about several times.. And will be implemented at some point..) | 19:00 |
| kiall | Yea, we've always talked about inbound AXFR support - where Designate would slave off, for example, MS AD and publish the zones to the DNS servers under it's control | 19:00 |
| kiall | Crappy crappy internet -_- | 19:00 |
| *** elemecca has joined #openstack-dns | 19:02 | |
| *** vinod has quit IRC | 19:04 | |
| richm | then that might work too | 19:04 |
| richm | Thanks for being patient with me. There is still a lot I need to learn. I have a lot of homework. | 19:06 |
| kiall | No problem ;) | 19:07 |
| kiall | Okay - gotta run to what will probably end up as another 24 hours of travel.. | 19:07 |
| kiall | "yay" | 19:08 |
| richm | bon voyage | 19:12 |
| *** eankutse has joined #openstack-dns | 19:27 | |
| *** jmcbride has quit IRC | 19:27 | |
| *** eankutse has quit IRC | 19:45 | |
| *** eankutse has joined #openstack-dns | 19:45 | |
| DeeJay1 | just to drop some notes to that discussions. the use case at my company for designate is to provide domain names to hosts in designated subdomains, so designate can be the source of truth for *.sub.company.com, *.sub2.company.com etc where sub* are delegated to designate | 19:53 |
| richm | DeeJay1: What is your primary DNS server? | 19:55 |
| DeeJay1 | richm: F5 GTM ;) | 19:55 |
| richm | Is there a backend for that? | 19:56 |
| DeeJay1 | it was a bind server underneath, but that changed to something I don't know, but it's hidden underneath a SOAP API | 19:57 |
| DeeJay1 | anyway we're using it that way that we have records like "sub.domain.com IN NS server_for_cloud" | 19:58 |
| DeeJay1 | so designate doesn't have to know about it at all | 19:58 |
| DeeJay1 | but like I said - it's just a use case we're currently using (though without designate yet) | 19:59 |
| richm | ok | 19:59 |
| richm | good to know about all of these different use cases | 20:00 |
| *** shakayumi has joined #openstack-dns | 20:00 | |
| *** jmcbride has joined #openstack-dns | 20:02 | |
| *** shakayum_ has joined #openstack-dns | 20:02 | |
| *** shakayumi has quit IRC | 20:05 | |
| *** DeeJay1 has quit IRC | 20:21 | |
| *** jmcbride has left #openstack-dns | 20:31 | |
| *** jmcbride has joined #openstack-dns | 20:34 | |
| *** vinod has joined #openstack-dns | 20:47 | |
| *** jmcbride has quit IRC | 20:51 | |
| *** CaptTofu_ has joined #openstack-dns | 21:06 | |
| openstackgerrit | Betsy Luzader proposed a change to stackforge/designate: Create API calls to Manage Blacklisted Domains https://review.openstack.org/65359 | 21:07 |
| *** msisk_ has quit IRC | 21:08 | |
| *** CaptTofu has quit IRC | 21:09 | |
| *** nkinder has joined #openstack-dns | 21:21 | |
| *** jmcbride has joined #openstack-dns | 21:52 | |
| *** jmcbride has quit IRC | 21:58 | |
| *** jmcbride has joined #openstack-dns | 21:58 | |
| *** betsy has quit IRC | 22:13 | |
| *** nkinder has quit IRC | 22:15 | |
| *** jmcbride has quit IRC | 22:21 | |
| *** jmcbride has joined #openstack-dns | 22:23 | |
| *** jmcbride has quit IRC | 22:28 | |
| *** vinod has quit IRC | 22:34 | |
| *** vinod has joined #openstack-dns | 22:36 | |
| *** artom has quit IRC | 22:39 | |
| *** CaptTofu_ has quit IRC | 22:45 | |
| *** shakayum_ has quit IRC | 22:54 | |
| *** vinod has quit IRC | 22:56 | |
| *** vinod has joined #openstack-dns | 22:59 | |
| *** vinod has quit IRC | 23:03 | |
| *** jorgem has quit IRC | 23:20 | |
| *** CaptTofu has joined #openstack-dns | 23:27 | |
| *** jmcbride has joined #openstack-dns | 23:33 | |
| *** HenryG has quit IRC | 23:41 | |
| *** jmcbride has quit IRC | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!