| *** CaptTofu has quit IRC | 00:27 | |
| *** CaptTofu has joined #openstack-dns | 00:27 | |
| *** CaptTofu has quit IRC | 01:11 | |
| *** CaptTofu has joined #openstack-dns | 01:11 | |
| *** CaptTofu has quit IRC | 01:13 | |
| *** mikal has quit IRC | 01:13 | |
| *** CaptTofu has joined #openstack-dns | 01:14 | |
| *** mikal has joined #openstack-dns | 01:14 | |
| *** shakayumi has quit IRC | 02:21 | |
| *** CaptTofu has quit IRC | 02:29 | |
| *** CaptTofu has joined #openstack-dns | 02:30 | |
| *** dmakogon_ has joined #openstack-dns | 05:26 | |
| *** dmakogon_ has quit IRC | 07:08 | |
| simonmcc | first one in wins | 10:08 |
|---|---|---|
| *** cflmarques has joined #openstack-dns | 10:27 | |
| *** cflmarques has quit IRC | 11:10 | |
| *** CaptTofu has quit IRC | 11:16 | |
| *** CaptTofu has joined #openstack-dns | 11:17 | |
| *** cflmarques has joined #openstack-dns | 11:26 | |
| cflmarques | hi guys. I can only create domains per tenant if I have keystone authentication enabled I am right? | 11:37 |
| cflmarques | hi guys. I can only create domains per tenant if I have keystone authentication enabled am I right? | 11:37 |
| *** shakayumi has joined #openstack-dns | 11:48 | |
| *** shakayumi has quit IRC | 12:20 | |
| kiall | cflmarques: yes, there are two auth modes... "keystone" or "none" | 12:46 |
| kiall | So - If keystone auth is not in use, then everyone is a admin in a single shared tenant/project | 12:46 |
| cflmarques | hi kiall | 12:56 |
| cflmarques | so what is this "X-Designate-Sudo-Tenant-ID" for? | 12:56 |
| kiall | That's intented for use with Keystone auth, allowing certain users to act on behalf of another tenant | 12:57 |
| cflmarques | I can only used that if I am admin? | 12:57 |
| kiall | Yea - That's not intended for end users in any way! | 12:57 |
| cflmarques | oh I see | 12:57 |
| cflmarques | so any tenant can use designate but only by providing with keystone authentication for especific project | 13:00 |
| kiall | Yea, or you can customize the policy.json and only allow users with certain roles etc acess.. | 13:03 |
| kiall | access* | 13:03 |
| cflmarques | that is a really good hint :) | 13:04 |
| cflmarques | I really never thought about policy.json | 13:06 |
| cflmarques | thanks | 13:08 |
| *** dkehn_away is now known as dkehn | 13:10 | |
| dmakogon | hi, guys, could you answer one question to me ? | 13:14 |
| dmakogon | kiall: what kind of DNS server Designate is ? | 13:14 |
| dmakogon | is it architecturally like dynamic dns or like powerdns ? | 13:15 |
| kiall | dmakogon: designate isn't a DNS server itself, it manages PowerDNS or Bind9 or .. | 13:15 |
| kiall | (PowerDNS is by far the best supported at the moment) | 13:15 |
| dmakogon | kiall: thanks | 13:16 |
| dmakogon | have you got any documentation about whole project (deployment, API etc) ? | 13:16 |
| kiall | http://designate.readthedocs.org/en/latest/ are the docs :) | 13:21 |
| cflmarques | dmakogon:The docs can help you! | 13:23 |
| dmakogon | thanks, alot | 13:23 |
| *** tsimmons has joined #openstack-dns | 14:04 | |
| *** msisk has joined #openstack-dns | 14:27 | |
| *** tsimmons has quit IRC | 14:42 | |
| *** vinodmr has joined #openstack-dns | 14:44 | |
| vinodmr | kiall: In Designate, are there checks for subdomains and superdomains to prevent a user from creating a sub/super domain for a domain owned by another user? | 14:45 |
| *** msisk has quit IRC | 14:49 | |
| *** msisk has joined #openstack-dns | 14:51 | |
| kiall | vinodmr: yea, but I believe there is a bug in it when creating a superdomain of an existing domain.. I've not had a chance to verify yet though. | 14:53 |
| vinodmr | Thanks kiall. | 14:58 |
| vinodmr | Do you happen to know where this code resides? | 14:59 |
| kiall | Just dialling into a call - be back in a few mins! | 14:59 |
| *** briancline has joined #openstack-dns | 14:59 | |
| justinsb | On that subject... is there a plan to cope when users do create a domain that isn't theirs, and then the legitimate owner wants to create it as well? | 15:15 |
| *** justinsb has quit IRC | 15:47 | |
| *** justinsb has joined #openstack-dns | 15:48 | |
| *** vinodmr has quit IRC | 15:53 | |
| *** tsimmons has joined #openstack-dns | 16:02 | |
| *** tsimmons has quit IRC | 16:02 | |
| *** cflmarques has quit IRC | 16:04 | |
| *** tsimmons has joined #openstack-dns | 16:04 | |
| *** tsimmons has quit IRC | 16:05 | |
| *** tsimmons has joined #openstack-dns | 16:05 | |
| kiall | justinsb: there's very little we can do there.. automating the process of determining who really owns a domain is .. hard. | 16:12 |
| kiall | CloudFlare have an interesting "trick" to make it doable for them, but it's just not something we could distill into Designate in a way that everyone can use it.. | 16:12 |
| *** dkehn_ has joined #openstack-dns | 16:21 | |
| *** dkehn has quit IRC | 16:22 | |
| *** cflmarques has joined #openstack-dns | 16:36 | |
| *** dkehn has joined #openstack-dns | 16:36 | |
| *** dkehn_ has quit IRC | 16:37 | |
| *** tsimmons has quit IRC | 16:52 | |
| cflmarques | hi guys. how can I enable designate-sink? | 16:53 |
| cflmarques | sorry, stupid question!!! "desigante-sink" | 17:04 |
| simonmcc | cflmarques: see https://github.com/stackforge/designate/blob/master/etc/designate/designate.conf.sample#L93 & the config that starts here: https://github.com/stackforge/designate/blob/master/etc/designate/designate.conf.sample#L113 | 17:11 |
| simonmcc | once it's configured, you just need to start the designate-sink process so that it collects the events | 17:11 |
| cflmarques | simonmcc: thank you | 17:13 |
| *** cflmarques has quit IRC | 17:17 | |
| justinsb | kiall: What's CloudFlare's trick? I was trying to think of solutions. I think we can have a large number of IPs, which sucks. Or I think we can have multiple DNS names for the same IPs, and check that the domain has set the nameservers to the matching name(s). | 17:29 |
| kiall | justinsb: their trick is to use multiple names for the same IP | 17:33 |
| kiall | then query whois data and see which 2 of the 100 possible names are in whois.. Giving them a 9.9k unique combinations to verify which end user actually made the whois changes | 17:35 |
| justinsb | kiall: That seems like a good option. Any reason that can't be implemented in Designate? | 17:35 |
| kiall | But distilling that into some anyone can do is difficult.. Basically, We can't ask customers to change their DNS entries until we're actually serving the correct zone. | 17:36 |
| kiall | I have no clue how CloudFlare manages to make it work! | 17:36 |
| kiall | If two customers register the same domain at the same time, which set of records do we publish? There will always be lag between whois updating, and Designate noticing.. | 17:37 |
| kiall | So - we have to serve something.. If we serve the wrong thing, we're in trouble :) | 17:37 |
| justinsb | Good point. I'll ponder! | 17:37 |
| kiall | Nothing like pointing a customers domain to a competitors, even for a few seconds, to feel the pain ;) | 17:37 |
| kiall | And - anyway - I'd feel awkward making that a requirement.. | 17:38 |
| justinsb | I was thinking we could have an 'approved' flag on the domain | 17:39 |
| justinsb | And then a plugin that would verify | 17:39 |
| justinsb | Some people would auto-approve, some would use whois tricks, some would use email, some would probably want a fax :-) | 17:39 |
| justinsb | I wonder if CloudFlare works because everyone gets the same IPs for HTTP load balancers | 17:40 |
| justinsb | They just use whois to determine where to redirect the HTTP requests | 17:40 |
| kiall | justinsb: interesting, I'm not sure we could make the CloudFlare trick work for that.. But we could certainly make approval based on factors other than the nameserver names work | 17:40 |
| kiall | The other option here is.. | 17:41 |
| kiall | Multiple pools of DNS servers, where domains are scheduled onto a pool.. Just like Nova instances are scheduled onto a compute node | 17:41 |
| kiall | domains with duplicate names could be scheduled to a different set of DNS servers.. | 17:41 |
| kiall | There would obv be a fairly low number of duplicates allowed (nowhere near the 10k that CloudFlare can manage..) | 17:42 |
| kiall | But, combining that with your idea would allow a domain to be suspended after, say, 7 days, should whois not be updated.. | 17:43 |
| justinsb | Oh... I like the auto-suspend idea. | 17:43 |
| justinsb | Because without that, we're sort of just kicking the can down the road | 17:43 |
| kiall | When I *finally* get a chance to get back to designate code rather than some internal stuff that's been chewing my time, pools are among the first items on my list (as part of the V2 API essentially) | 17:44 |
| justinsb | Cool - well, I look forward to seeing it! | 17:44 |
| justinsb | I might experiment with the 'approved' flag on a domain | 17:44 |
| justinsb | See what tricks I can come up with! | 17:44 |
| kiall | Yea... Once a domain is suspended, we would purge it from the backend DNS servers .. "Resuming" it would re-populate the backend.. | 17:44 |
| kiall | There's still 1 more difficutly.. If a customer zone is suspended due to, for example, non payment.. we absolutely need to resume it on the same set of DNS servers | 17:45 |
| kiall | Anyway - I don't think that would have any effect on the 'approved' (verified?) suggestion you have :) | 17:46 |
| justinsb | Another good point! I guess though, that if a customer hasn't verified, then we don't have to offer the same guarantees | 17:47 |
| kiall | Actually - This might tie in with the work mugsie is doing at the moment | 17:49 |
| kiall | 2 sec | 17:49 |
| kiall | https://dl.dropboxusercontent.com/u/1400487/graphviz-fd80799c9423325e8616080d6ae7d1af8a96b5f6.png | 17:49 |
| kiall | That was an initial state machine I drew up for domains .. | 17:50 |
| kiall | Another state, "pending verification" (or something) could be intoduced. | 17:50 |
| kiall | introduced* | 17:50 |
| kiall | mugsie: about? | 17:51 |
| *** shakayumi has joined #openstack-dns | 17:52 | |
| *** tsimmons has joined #openstack-dns | 17:52 | |
| mugsie | hey | 18:00 |
| mugsie | kiall: justinsb yeah, we could add that as part of the create domain flow | 18:01 |
| mugsie | pending_verification -> pending -> active | 18:03 |
| mugsie | or pending_verification -> active ? | 18:03 |
| kiall | Yea.. The naming get.. Confusing ;) | 18:04 |
| mugsie | well, where is the verification done? | 18:04 |
| mugsie | backend / central ? | 18:04 |
| mugsie | thats what is going to decide that | 18:05 |
| kiall | Anyway, I think the whole idea deserves some more thought.. It'd be a pretty big change :) | 18:05 |
| mugsie | yeah... every time i go to write code for this ... something else pops ;) | 18:05 |
| mugsie | pops up* | 18:05 |
| kiall | central would do it, and until the zone is verified (via some plugin), no records etc would hit the backends.. | 18:05 |
| kiall | So .. bigger change than I would have hoped! | 18:05 |
| mugsie | yeah | 18:06 |
| mugsie | i think that would be a separate blueprint to what I am currently doing | 18:06 |
| mugsie | it definitly feeds in, but maybe at a later stage | 18:06 |
| kiall | Yea, I think so too.. | 18:09 |
| *** dkehn is now known as dkehn_away | 18:44 | |
| *** tsimmons has quit IRC | 19:30 | |
| *** vipul is now known as vipul-away | 19:41 | |
| *** vipul-away is now known as vipul | 20:01 | |
| *** dmakogon_ has joined #openstack-dns | 20:53 | |
| *** dkehn_away is now known as dkehn | 21:11 | |
| *** msisk has quit IRC | 21:47 | |
| *** openstackgerrit has quit IRC | 21:48 | |
| *** openstackgerrit has joined #openstack-dns | 21:48 | |
| *** ChanServ sets mode: +v openstackgerrit | 21:48 | |
| *** tsimmons has joined #openstack-dns | 22:02 | |
| *** tsimmons has left #openstack-dns | 22:02 | |
| *** dmakogon_ has quit IRC | 23:03 | |
| *** vipul is now known as vipul-away | 23:37 | |
| *** vipul-away is now known as vipul | 23:44 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
