Enable a secondary DNS provider for DDoS resistance

@briann good catch -- and, something along the same lines with IP addresses may be a good idea.

A single unicast or anycast IP address has similar limits and it may also be good to add some more "A" records for key servers, distributed across different providers.

It may also be worth looking at the Netflix solution for this idea: Netflix Denominator for DNS

Something to also keep in mind, though it probably doesn't might matter much, is that distributing nameservices across providers will void the SLA, e.g. with AWS Route 53:

The Service Commitment does not apply to any unavailability, suspension or termination of Amazon Route 53, or any other Amazon Route 53 performance issues: ... (vii) that, with respect to public DNS only, result during a period that you were not using all four virtual name servers (for example, ns123.awsdns.com, ns123.awsdns.net, ns123.awsdns.co.uk and ns123.awsdns.org) assigned to your “hosted zone” - Amazon Route 53 Service Level Agreement

We are running a project with coredns, kubernetes, git + zone files and multiple secondary providers (DNSMadeEasy + BuddyNS). Audit, permissions via git and extendable to every provider that has secondary capabilities. Always happy to talk.

I actually meant to link to OctoDNS instead of the other tool. I've updated the issue. 😢

@rabbitfang

AFAIK gitlab.com is already using the four virtual name servers provided by Route 53 see: whois gitlab.com
I do not see a prohibition in the AWS SLA against adding a 5th (or more) name server from some other provider.

@techguru I know some domain registrars limit the number of nameservers for a domain to 4 through their user interface.

@rabbitfang yes, and the gitlab.com registrar seems to allow up to 10

Domain Name: gitlab.com
Registrar WHOIS Server: whois.gandi.net
Registrar URL: http://www.gandi.net
Registrar: GANDI SAS
Registrar IANA ID: 81

...

Name Server: NS-705.AWSDNS-24.NET
Name Server: NS-505.AWSDNS-63.COM
Name Server: NS-1644.AWSDNS-13.CO.UK
Name Server: NS-1373.AWSDNS-43.ORG
Name Server: 
Name Server: 
Name Server: 
Name Server: 
Name Server: 
Name Server:

per Gandi.net Gandi lets you use your own DNS (up to 10) if you need to.

assigned to @northrup

@northrup this is not scheduled for this week.

@briann do you think we should be working on this this week?

removed assignee

@pcarranza There is no timeline for this. Whenever you can make it happen.

changed milestone to %WoW ending 2017-05-17

assigned to @northrup

changed milestone to %WoW ending 2017-05-23

changed the description

Dyn is potentially faster, old report: http://blog.cloudharmony.com/2012/08/comparison-and-analysis-of-managed-dns.html apparently can shave 10's of ms off "load time".

removed milestone

@briann I was discussing this with @northrup , and decided to remove it from this week's milestone. He mentioned the monthly cost, which... when I put it in the risk assessment scoring on the cost of the action, drops the (risk averted)/(cost of action) ratio way down... to the point that it is not something we should be working on right now compared to other things.

Expected cost of delaying this work is on the order of ˜$500-$600/mth.

DNSperf.com just relaunched with a lot of data. Might be handy to look into that.

mentioned in issue #1284 (closed)

@briann could you assign one of those labels of yours with priorities?

removed assignee

added SL3 label

Due to changes in the Risk Assessment I'm marking this as SL3 for now, which means we should get to it in the coming months but it's no longer a priority.

@pcarranza \cc @northrup @sitschner This one has crept back up the list of actions to take based on the Risk Assessment, see https://gitlab.com/gitlab-com/infrastructure/issues/1851 . Can it be tackled in the coming month(s)?

marked the checklist item Create Route53 user w/ scoped permissions and access tokens for automation. as completed

marked the checklist item Create DynDNS user w/ API tokens for automation. as completed

assigned to @northrup

@ernstvn I've already got some work down on this one and have checked it off on the progress, I should be able to knock this out within the coming month with a little here and a little there.

marked the checklist item Slurp Route53 zone data into DynDNS using OctoDNS. as completed

marked the checklist item Validate DynDNS data in all zones. as completed

marked the checklist item Test OctoDNS generated changes for population into DynDNS & Route53. as completed

marked the checklist item Automate CI job for OctoDNS commits. as completed

@pcarranza @briann Dyn DNS servers are:

ns1.p03.dynect.net
ns2.p03.dynect.net
ns3.p03.dynect.net
ns4.p03.dynect.net

The managing project is gitlab-com/gitlab-dns that uses our own Docker image of gitlab/gitlab-dns to push changes.

Right now I have slurped the data from Route53 and loaded the initial yaml files, GitLab CI has pushed the DNS data into DynDNS.

Next step is to balance out the NS records to include both Dyn and Route53 for diversity, making the yaml data authoritative for Route53, and then letting the git repo and MR's do the rest of the work.