Aller au contenu

Caascad#

DNS domains and AWS accounts#

In Caascad we use 4 second level DNS domains:

  • caascad.net: prod. used to resolve private ip addresses. Not really useful and should be un provisioned.
  • caascad.com: prod. used to resolve public ip addresses
  • cscdpriv.com: staging
  • cscdpriv.net: staging

Those domains are stored on AWS caascad-corp-aws (577372708024).

Each zone receives 2 DNS domains:

  • ${ZONE_NAME}.caascad.net
  • ${ZONE_NAME}.caascad.com

Those zones are store in two different AWS account:

  • staging: caascad (181151069204)
  • prod: caascad-prod (056386662017)

Configurations#

DNS zones are created by:

  • aws_dns_zones (PF context): provides caascad.net and caascad.com DNS domains
  • fe_base (Caascad context): provides ${ZONE_NAME}.caascad.com and ${ZONE_NAME}.caascad.net

STS endpoints#

Caascad.com and caascad.net domains are managed through STS endpoints on Vault Corp: 

export VAULT_ADDR=https://vault.corp.caascad.com
eval $(vault read aws/sts/corp-aws-power-user -format=json| jq -r '.data|"export AWS_ACCESS_KEY_ID=\(.access_key)\nexport AWS_SECRET_ACCESS_KEY=\(.secret_key)\nexport AWS_SESSION_TOKEN=\(.security_token)"')
cli53 list

For staging zones DNS domain: 

export VAULT_ADDR=https://vault.infra-stg.caascad.com
eval $(vault read aws/sts/power_user_infra-stg -format=json| jq -r '.data|"export AWS_ACCESS_KEY_ID=\(.access_key)\nexport AWS_SECRET_ACCESS_KEY=\(.secret_key)\nexport AWS_SESSION_TOKEN=\(.security_token)"')
cli53 list

For prod zones DNS domain: 

export VAULT_ADDR=https://vault.infra-prd.caascad.com
eval $(vault read aws/sts/power_user_infra-prd -format=json| jq -r '.data|"export AWS_ACCESS_KEY_ID=\(.access_key)\nexport AWS_SECRET_ACCESS_KEY=\(.secret_key)\nexport AWS_SESSION_TOKEN=\(.security_token)"')
cli53 list

DNS recursion#

On Caascad, a service 'myservice' on 'myzone' will be solved this way:

myservice.myzone.caascad.com -> CNAME ->  loadbalancer_name.myzone.caascad.com -> A -> loadbalancer ip

Example:

 dig git.corp.caascad.com

;; ANSWER SECTION:
git.corp.caascad.com.   95  IN  CNAME   private.corp.caascad.com.
private.corp.caascad.com. 30    IN  A   90.84.246.15

Managed assets#

Per zone:

  • one zone for public ips .com provided by fe_base
  • one zone for private ips .net provided by fe_base
  • one dns delegation for .com in caascad.com zone provided by fe_base
  • one dns delegation for .net in caascad.net zone provided by fe_base

For the whole caascad product:

  • one second level DNS domain zone caascad.net for .net zones delegations; provided by aws_dns_zones
  • one second level DNS domain zone caascad.com for .com zones delegations; provided by aws_dns_zones
  • 2 zones bought from Gandi registrar

Private zones#

For every zone in Caascad we use the Cloud provider DNS resolvers except for private zones. Private zones are specific zones with no NATGW. Caascad requires a connectivity from the client zone to the cloud zone which is normally ensured by the NAT GW. For private zones the VPC endpoint technology is used. VPC endpoint let us connect a loadbalancer port to any other subnets, even on another vpc or project. More informations about it can be found in SIRH documentation

Private zones can be found this way:

Client zones with a private link, which is the first version of private zones (sirh): 

sd get zones | jq -r'.[]|select(.parameters.network.private_link == true)|.name'

Client zones of a cloud zone having a private_link attribute, which is the second version of private zones (BNP). 

sd get zones | jq '.[]|select(.parameters.private_link)|.child_zone_names'

On private zones, the subnet DNS resolvers has been modified to request a dnsmasq instance powered on cloud zones, and reachable from a client zones through a VPC endpoint.

Those dnsmasq instances lie about the cloud zone dns records. Whereas AWS route53 will provide a public IP for a service, the dnsmasq equivalent answer will provide VPC endpoints IP and thus ensure the client zone will use VPC endpoints to talk to the Cloud zone.

Private zone

SIRH#

General dns resolution schema#

Private zone SIRH

Detailed schemas about dns resolution#

Private zone SIRH details

Managed assets#

ocb-sirh, sirh-recette and sirh-prod comes with several new assets. Some of them are automated, others provisioned manually:

  • with trackbone on ocb-sirh network: 2 supplementary loadbalancers public-(child_zone_name) (one per client zone)
  • with trackbone on ocb-sirh network: for every public.* loadbalancer a vpc endpoint service
  • with trackbone for every client zone: 2 vpc endpoints, one for a public-(child_zone_name) loadbalancer, and the other one for the public loadbalancer
  • manually one public dns zone on route53 where vpc loadbalancers fqdn are solved to vpc endpoints ips
  • manually one dns forwarding for ocb-sirh on GIN dns servers, provisioned via ticketing with Orange DNS MOE. The forwarding points to the ocb-sirh DNS zone provisioned manually (with vpc endpoints ips)

To reduce costs and simplify:

  • GIN DNS forwarding should be fixed so that MA DNS resolvers do not need an explicit forwading for that zone
  • remove DNS forwarding on MA DNS resolvers
  • remove public(child_zone_name) loadbalancer, vpc endpoint service, and vpc endpoint
  • remove dnsmasq

BNP#

DNS resolution schema#

Private zone BNP

Managed assets#

ocb-sirh, prdbnppc and ppdbnppc comes with several new assets. Some of them are automated, others provisioned manually:

  • with trackbone on ocb-bnppc network: 1 supplementary loadbalancer public_dns (child_zone_name)
  • with trackbone on ocb-bnppc network: for every public.* loadbalancer one vpc endpoint service
  • with trackbone on client the client project: for every loadbalancer one vpc endpoint
  • with trackbone on kubernetes subnetes: overrides on DNS resolvers used to point the VPC endpoint ip peered to the public_dns loadbalancer
  • manualy one dns forwarding for ocb-bnppc.caascad.com zone on BNP servers to the public_dns loadbalancer vpc endpoint ip

To reduce costs and simplify:

  • a FE DNSaaS zone should be created and mapped to the client vpc, so that the kubernetes network would be able to solve caascad.com
  • edit the BNP forwarding to point a new route53 public zone with VPC endpoint ips in it
  • remove the DNS resolvers override on kubernetes subnets
  • remove public_dns loadbalancer, vpc endpoint service, and vpc endpoint
  • remove dnsmasq