17:04:01 #startmeeting Designate 17:04:01 Meeting started Wed Dec 18 17:04:01 2013 UTC and is due to finish in 60 minutes. The chair is kiall. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:04:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:04:02 bye 17:04:05 The meeting name has been set to 'designate' 17:04:18 Heya - Who's about today? 17:04:22 o/ 17:04:37 I'm here for the first 10 minutes 17:04:40 here 17:04:40 o/ 17:04:48 here 17:05:18 Okay - So, some real quick housekeeping.. It's Christmas .. I'm taking a wild guess we're skipping Dec 25th's meet! 17:05:32 Do we resume on Jan 1, or Jan 8 ? 17:05:37 8th 17:05:47 +1 17:05:51 (I'd be "off work" on the 1st, but am happy to do a meet if people are around) 17:05:53 +1 17:05:57 +1 17:06:06 Okay - Let's call that settled so :) 17:06:17 Psh, I was going to be here ;) 17:06:22 I assume people who want will be around on IRC, so... 17:06:33 Exactly :) 17:06:42 Okay .. So, no actions from last week.. 17:06:48 #topic Followup on Blueprint Backlog Prioritisation 17:07:00 mugsie .. Since this was your doing ;) 17:07:08 cool 17:07:16 so i think last week went well 17:07:25 i have writen up the notes i took from the meeting 17:07:29 they are here 17:07:32 #link https://wiki.openstack.org/wiki/Designate/Blueprints/Meetings/12-2013/Minutes 17:07:58 as it turns out there is a youtube clip of the whole meeting 17:08:08 which I can share if people want 17:08:16 (it is currently set to private) 17:08:34 * artom would watch it. 17:08:36 my IRC is lagging today 17:08:47 People also expressed an interest in having a repeat 17:08:54 i think some time like the 8th? 17:08:54 eankutse1: mine too.. particularly badly 17:09:16 what do people think? 17:09:23 +1 17:09:26 (The next topic will deserve some serious thought, and probably a HO dedicated to it) 17:10:04 So, I'd say, Yes - let's do another video call in place on the meet on the 8th 17:10:10 cool. I will research google hangouts properly this time, and set up something similar as last ime 17:10:13 time* 17:10:37 #action set up VC on the 8th Jan - mugsie 17:11:00 mugsie: thx 17:11:15 Okay - Before we move on, Did anyone have any followups or comments on the call? Anything they'd change for next time? 17:11:37 (Other than knowing where the "Start" button is in advance ;)) 17:11:54 mugsie: cool. Thx 17:11:59 Were y'all able to hear all of us at RAX who were in a room together? 17:12:03 yeah 17:12:03 Did that work out? 17:12:06 it was fine 17:12:08 cool 17:12:11 betsy: yea, that worked fine 17:12:23 betsy, i heard everyone fine. 17:12:57 Okay .. Next topic unless anyone has anything more on the call? 17:13:20 #topic Initial discussion of a possible solution to several issues raised during the Blueprint Hangout 17:13:45 Okay.. So I've intentionally kept ^ a little vague, as we wanted to discuss "in person" 17:13:55 Several of the issues raised in the hangout, like: 17:14:01 - Better BIND support 17:14:12 - RFC Dynamic DNS (aka nsupdate support) 17:14:23 - Transnational updates to zones 17:14:38 and .. quite possibly a few others 17:15:00 17:15:29 Myself and mugsie got thinking, what if instead of trying to integrate with BIND/PowerDNS/NSD in the way we do today, what if we implemented a *tiny* minimal DNS server capable of taking AXFR's from BIND/PowerDNS etc 17:16:00 k 17:16:29 Before you call me insane .. the DNS protocol is quite simple.. I mocked this up in sometime around Jan/Feb to refresh my DNS memory.. (looking for link, lost it) 17:16:39 #link http://pastie.org/private/w9mvs6xgtqzil6wwuflx5a 17:16:44 Whoa Radical!! 17:16:49 * artom did a caching DNS server in Java for a school project. Took a couple of weeks. 17:16:57 exaplain :-) 17:17:14 A simple 600 line implementation of DNS that can accept and respond to queries (the service bit ain't there..) 17:17:44 Since we're not aiming for responding to end user queries with this, we can avoid the need to handle the million or so edge cases 17:17:54 How would Designate update the zones served by the custom DNS server? 17:17:55 But we get some big advantages (and some disadvantages) 17:18:09 kiall, tiny server would be between Designate and real backend? 17:18:16 rjrjr_: exactly.. 17:18:18 If you say MySQL database, I'm going to bonk you for reimplementing a subsset of PowerDNS ;) 17:18:19 Some advantages: 17:18:32 - All updates (bar create/delete zone) go via AXFR 17:18:47 - An endpoint/framework for RFC Dynamic DNS / nsupdate is built 17:19:05 - Transactional changes - we only need to write the changeset to the DB transactionally, AXFR's handle the rest 17:19:32 - DNSSEC signing could be done here, sending pre-signed zones to the real DNS servers 17:19:48 kiall: the DNS protocol has it's dirty corners. 17:19:49 - Overlapping zones could be implemented using TSIG to distinguish which view 17:19:57 17:20:12 eankutse1: keep seeing blank messages from you, not sure if you're trying to talk? 17:20:21 kblin: oh it has 1000's of dirty corners! 17:20:24 so, Central storage, tiny DNS server, and backend need to all be synched? uhhh... 17:20:32 That's why this would never, ever, ever be public facing 17:20:49 * artom has to run, but consider my previous two comments about reimplementing a subset of PowerDNS - they were only half in jest. 17:20:53 rjrjr_: tiny DNS would talk to central, just like the API service does 17:20:59 His IRC is probably lagging as hard as mine, literally minutes behind. 17:21:25 rjrjr_: At that point, we've actually reduced the # of things that need to be kept in sync 17:21:51 tsimmons: seems like freenode is having issues this week 17:21:54 howso? is central storage replaced with tiny DNS server? 17:22:16 Or does the tiny DNS sever not have storage? 17:22:21 rjrjr_, no. tiny DNS server talks directly to storage (well - to central) 17:22:37 It has no storage of it's one.. 17:22:40 kiall: I'm still catching up, on my backlog, but you're planning to use tht thing to push data into the real backend DNS server, right? 17:22:42 of its own* 17:22:44 gotcha. so central storage and tiny DNS server are a whole. 17:22:58 eankutse (or others with mad lag): You can refresh this page to see things in real(ish) time. http://eavesdrop.openstack.org/meetings/designate/2013/designate.2013-12-18-17.04.log.txt 17:23:01 rjrjr_: yep - exactly.. tiny DNS server is just like designate-api 17:23:24 it decodes DNS (i.e. JSON), calls central via RPC, and encodes DNS (i.e. JSON) 17:23:47 Raw speed is not so important, as we're talking about AXFR to the public facing servers.. not end user queries 17:24:02 question, how does the backend learn about new zones? 17:24:48 The current "backends" would be totally stripped down, whichever central processes a "create zone" would, for bind, call `rndc addzone { master tiny-dns-server; }` 17:25:22 Today, here's what we try and keep in sync: 17:25:25 - The SQL DB 17:25:31 - The Master Backend 17:25:33 - The Slave Backends 17:25:51 Right 17:25:52 PowerDNS is "easy" .. the SQL DB, and the PowerDNS SQL DB .. 17:26:09 Bind is harder, as it's zonefiles on a master (and is the master alive? or rebooting? or..) 17:26:39 We also don't do things transitionally, we have no mechanism in place for it.. 17:27:09 transactionally? 17:27:13 If we dumped the current idea of backends for this, we would only have to write to the DB transactionally, then issue the NOTIFY's to the real DNS servers 17:27:43 How would this work with server pools? 17:27:46 rjrjr_: adding 3 RR's while removing 2 RR's from an RRSet - you mentioned it as one of your nsupdate things 17:28:12 betsy: good question :) I think it changes how those would be implemented, but not how they would be exposed. 17:28:41 hmm. Lots to think about 17:29:05 A pool would have N DNS servers configured in it.. when a new zone is added, a TSIG key is built, and central calls out to the servers in that pool with `rdnc addzone`, or a queue, or.. whatever mechanism is needed for the DNS server in use 17:29:18 betsy: I did say this was "radical", didn't I? ;) 17:29:23 backends don't go away completely though because of needs like zone creation. 17:29:29 :D 17:29:40 rjrjr_: exactly, but they get simplified significantly 17:30:10 i like the idea! 17:30:11 Also - Thus is by no means a decided thing.. I'm on the fence over if this is doable, or if I should go check myself into a clinic somewhere ;') 17:30:32 kiall: what's the advantage of AXFR instead of letting the "real" dns servers handle the zone and doing DNS update calls? 17:30:40 So what are the advantages and disadvantages y'all have come up with so far? 17:31:34 kblin: so, some big advantages I see are: 17:32:27 1) We no longer care about the details of a DNS server bar the basic add/delete zone 17:32:40 s/DNS server/public facing DNS server/ 17:33:05 2) All public DNS facing servers are equal - there all slaves, there is no master (well - the "tiny AXFR only" DNS server is master). 17:33:16 3) We gain an endpoint for RFC Dynamic DNS (i.e nsupdate) 17:33:16 neither should the "nsupdate" code path 17:34:39 kblin: so, one issue with doing nsupdates is .. 17:35:07 either we still have a master, or we're left needing to keeping everything in sync across every DNS server 17:35:18 s/keeping/keep/ 17:36:12 Implementing DNS is *hard* .. too hard for us to take on. Implementing just enough DNS to handle AXFR's from known clients, rather than every broken implementation in the world, is easier.. (but still not easy) 17:36:30 true. I'm just not sure if you really can avoid the dirty details of DNS if you're still the DNS master the public facing DNS servers pull from 17:37:07 kblin: I was thinking the same thing 17:37:12 kblin: that may be so :) Which is why I'm on the fence over if this is a good idea.. It frankly needs a TON of thought before anything is decided. 17:37:20 now assuming you have your central API that handles the DNS logic, that's the part that has the core logic 17:37:34 that needs to know what your DNS looks like 17:38:30 I don't see why, from this central instance, pushing updates to the user-facing servers is very different if you use AXFR or UPDATE 17:38:33 Right, but - we always need something that knows what your DNS should look like, with the current method, we need to know how to transform that for PowerDNS, BIND, NSD, ... 17:38:55 in all cases your "backend" needs to know how to set up new zones 17:39:18 kblin: what happens when 1 of to 50 user facing DNS servers is down? We need to start keeping track of every change, and which servers it's been applied to 17:39:24 and in all cases once the zone is there, you can then send updates via a DNS protocol mechanism 17:40:08 kblin, the zone setup is the only diff. some admin work when setting up DNS servers is needed (allow-notify) but that would be true for update (allow-update). 17:40:34 those settings can be done globally. 17:41:09 kiall: sorry for sounding negative, I've just been bitten repeatedly by "oh, nobody is using that obscure feature of DNS anyway" 17:41:18 Yea - I think kblin's argument is around if we implement the tiny DNS server, or a tiny DNS client (or, more likely wrap nsupdate) 17:41:41 kblin: totally understood, I'd be pissed if nobody thought I was insane for suggesting this ;) 17:42:11 as a disclaimer, I'm the author of Samba's DNS server implementation that we wrote to have a server that can use the AD DNS backend active directory uses 17:42:23 I know :) 17:42:35 it also started out as "oh, it's only 1000 lines of code" :) 17:43:08 Kiall: just catching up with my slow IRC - by "tiny DNS" you mean "minimal" not as in the DNS product tinyDNS? 17:43:15 eankutse: yes 17:43:18 thx 17:43:40 eankutse: minimal, just enough to receive and respond to an AXFR from the "real" DNS server 17:43:48 kiall: ok, my gut feeling would be that a tiny DNS client might be a bit easier to control 17:43:50 k 17:44:19 kiall: but arguably the "what if we can't update some of the servers" case needs some thought in that scenario 17:44:29 kblin: there are a couple of advantages to doing it this way rather than using nsupdate.. Ignoring keeping the N global DNS servers in sync.. 17:45:58 <-- totally blanked