Policies and Best Practices
We will not project Stanford’s IP space into the cloud. The current campus and Livermore spaces will stay as they are.
Many of the AS services are currently architected with private addresses. Some services, like PCI or video security cameras, are special cases in that they may require a dedicated network.
Any servers on campus that need to receive connections from off-campus will get public IPs.
Use NetDB to register subdomain hosts in the cloud. Work to enhance NetDB to better track this information is scheduled for this year.
- Don’t use VPN when you can use native encryption and strong authentication. VPN should be used only when the native application transport is not secure OR when there isn’t any other way to connect.
- Do not set up an application in such a way that it must be single-path. Network connectivity should not be designed to be single path. Design an application to have as much resiliency as possible.
- Do not build in a dependency to an on-campus service for any cloud apps.
- Applications should use DNS resolution names when possible.
- Only use FQDN based firewall rules when addresses can not be static and never for services requiring interactive sessions (e.g. login, ldap, ad, kerberos, axess, ofweb, www, webmail).
Diverse High Bandwidth Connectivity to the Cloud
Stanford University maintains a high bandwidth, direct connection with a commercial internet provider and multiple high bandwidth, direct connections with the California Research and Education Network (CalREN) to provide diverse routing for cloud service providers. Our providers have established high bandwidth connectivity to cloud service providers as well as to other Internet Service Providers that generally have established high bandwidth connectivity to cloud service providers within their Internet region.
See Network Information for IT Providers for additional information.
Stanford Campus Firewall Service
Stanford University maintains network firewall hardware that filters inbound and outbound traffic for systems at Stanford. Firewall policies are configured to allow or block traffic between systems that are in different firewall zones. Firewall policies explicitly identify source and destination Internet addresses and application service ports. Fully Qualified Domain Names (FQDN) for systems that are not static may be used in firewall policies. The use of domain names in firewall policies will be reviewed prior to implementation. Each firewall zone has a set of policy approvers. Firewall policies are created or modified only after requests have been approved.
See Firewall Service for additional information.
Bidirectional connectivity is provided through encrypted tunnels between Stanford University’s central VPN gateway and remote VPN gateways. Traffic through the tunnel is allowed between hosts at Stanford University and hosts at remote locations that are configured with globally unique, non-Stanford University public Internet addresses or Stanford University assigned RFC 1918 addresses not already in use on campus.
Site to site VPN connectivity is provisioned on a per request basis.
See EVPN (Enterprise VPN) for additional information.
Domain Name Services (DNS)
DNS is the network service that maps Internet domain names to numerical Internet addresses. For example, a machine looking for name.stanford.edu would request name.stanford.edu’s Internet address from a DNS server. The DNS server would return the Internet address associated with the domain name.
DNS queries will return Internet addresses in random order when a DNS registration has multiple addresses assigned.
DNS registrations can have associated alias names. For example, name.stanford.edu can have an alias of myname.stanford.edu where DNS queries for myname.stanford.edu will return name.stanford.edu’s Internet address. As another example, Stanford University’s domain registry can contain a record for service.cloudprovider.com that has an alias of myname.stanford.edu. DNS queries for myname.stanford.edu would return service.cloudprovider.com’s Internet address. Simple reverse DNS queries for addresses associated with an alias will return the registered DNS name, not the alias name.
Stanford University DNS registration is managed with the NetDB application and is generated every 30 minutes, including the delegations.
See NetDB for additional information.
Internet Subdomain Delegation
By default, all requests for domain names ending with .stanford.edu and .stanford.org will be resolved by Stanford University’s domain name servers.
Domain names can be registered in DNS to be resolved by third party domain name servers. For example school.stanford.edu can be set to be resolved by nameserver.thirdpartydns.com. Once set, the domain name school.stanford.edu and all domain names ending with .school.stanford.edu will be resolved by nameserver.thirdpartydns.com and registration of domain names for that subdomain would be managed by the registration service provided by the third party.