Page MenuHomePhabricator

Move some of wikimediacloud.org 185.15.56.0/23 to Netbox
Open, LowPublic

Description

From https://raw.githubusercontent.com/wikimedia/operations-dns/master/templates/wikimediacloud.org

I suggest:

codfw:

nat.cloudgw         5M  IN A      185.15.57.1  <- Move to Netbox
wan.cloudgw         5M  IN A      208.80.153.190 <- move to a wikimedia.org FQDN (as it's a 208.80.153.x IP) - https://netbox.wikimedia.org/ipam/ip-addresses/7044/
virt.cloudgw        5M  IN A      185.15.57.9  <- Move to Netbox

; neutron virtual router cloudinstances2b-gw
cloudinstances2b-gw 5M  IN A      185.15.57.10  <- Move to Netbox

Also I don't think there is any reason for the 5M TTL? and the default 1H is fine?

eqiad:

; neutron virtual router cloudinstances2b-gw
cloudinstances2b-gw 5M  IN A      185.15.56.244  <- move to Netbox
; general outgoing/egress NAT address (routing_source_ip)
nat                 5M  IN A      185.15.56.1  <- move to Netbox

Same question for the TTL.

The ns/ns-recursor A/AAAA records are more complex.

Ideally there should be no services records pointing to host IPs. For example "ns0.wikimedia.org" is a VIP hosted on hosts with different host IPs.
One of the advantage, is that decommissioning an host will not required moving DNS records. It's also less snowflakes in the infra.
As they point to prod IPs (208.80...) we could move them there, so they end in a .wikimedia.org FQDN.

But in the meantime, to make some progress it's fine to keep them as it, in the operations/dns file.

Event Timeline

ayounsi created this task.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Note that 185.15.56.0/24 is delegated to designate directly from the RIPE, so the PTR is out of scope here.

@nskaggs I'm triaging the netbox tasks. Does WMCS has an opinion on that task or it's fine to proceed?

It is fine to proceed. Moreover, after the cloudgw project, some of this may be already on netbox anyway! see https://netbox.wikimedia.org/search/?q=cloudgw#ip%20addresses

The other topics you mentioned:

  • Regarding the service FQDNs. We don't need them. These FQDNs related to the edge network are mostly here to help us make sense of the network topology (traceroute, tcpdump, ping, etc) there aren't any services listening on them (not a DNS server definitely)
  • regarding 208.80.153.190 that whole range should probably be replace with the cloud-specific range in codfw. That's for another task though.
  • regarding the DNS server addresses. You are right, an intermediate service FQDN might be in order here.