1. La atención. Modelos atencionales
1.7 Desarrollo de la función ejecutiva a lo largo de la edad
The virtual hardware approach assigns a unique IP address to each virtual web server. This can be done using one of the virtual machine implementations that are available for both Windows and Unix platforms. Using this approach, the physical memory, disk space and processing power in the server is apportioned between each virtual machine. It is possible to start-up and shut down virtual machine web servers independently, and it is also easy to port a virtual web server between one physical platform and another, making moves, changes and hardware upgrades fairly easy to achieve.
In Figure 20, a virtual machine application has been used to provide three virtual platforms and operating systems, and each of these hosts a separate hosting application. The virtual machine software provides virtual hardware for each virtual machine, including network interface cards, and so each virtual machine is separately addressed.
Note that each virtual machine in this case has a separate name server address entry that resolves the relevant host name to its IP address.
192.168.1.2
The main web server application supports a virtual hosting model, where multiple domains can be hosted on a single instance of the web server. In this case the server will have both global configuration settings, and settings that are specific to each domain being hosted. The virtual web server approach is typically used in a service provider context, where only web server functions are required from the platform, but for large numbers of domains.
In the example in Figure 21, a single host provides all of the domain web services, however the web server application has been configured with details of each virtual host, as shown in Figure 21. When the DNS is queried for the IP addresses of the virtual web servers, it returns the same IP address in each case. Note that a name server entry is required for each domain in order to resolve URL requests to the server IP address.
192.168.1.1
<Virtual Host>
DocumentRoot /var/www/wraycastlecom ServerName www.wraycastle.com
ServerAdmin [email protected]
</Virtual Host>
<Virtual Host>
DocumentRoot /var/www/companycouk ServerName www.company.co.uk
ServerAdmin [email protected]
</Virtual Host>
<Virtual Host>
DocumentRoot /var/www/ISPorg ServerName www.ISP.org
Virtual Web Server Hosting
Some organizations wish to have a dedicated physical server from which to host their web content. In these cases, the service provider typically offers a suitable physical server dedicated to the customer, along with WAN and LAN connectivity, and the name server facilities to make the device reachable.
Typically first level support for the platform from the service provider is part of this package; the service provider will repair faulty hardware or software on the basic platform. However web content and scripting is the responsibility of the customer.
The customer can normally access the web server securely for remote administration.
This is a common model for small to medium-sized hosting companies. They rent physical servers and infrastructure from a large data centre operator, then resell hosting and other services on these physical platforms using a virtual hosting model to their customers.
3.5 Co-location
In the co-location model, the service provider is responsible for space, power, network connectivity and basic network services such as name servers. However the customer provides their own physical servers into the rack space provided by the data centre operator. Normally this model requires operational staff from the customer to be present at the facility to provide first level support, and so is only suitable for large data centres and large customers. This approach is more popular for other than web hosting scenarios, particularly for Internet exchange Points and carriers wanting access to backbone transmission facilities for core Internet nodes.
www.wraycastle.com www.company.co.uk www.ISP.org
IN A 192.168.1.1 IN A 192.168.1.2 IN A 192.168.1.3
>whois wraycastle.com
name server ... ns1.myISP.com ..
. 192.168.1.1
www.wraycastle.com
192.168.1.2
www.company.co.uk
192.168.1.3
192.168.2.1
Router Router
to Internet www.ISP.org
ns1.myISP.com
Figure 22
Dedicated Hardware or Co-location Hosting
Requests for popular web pages are made continuously from locations across the global Internet. Since many users make the same request, it often makes sense to provide some local caching of web pages, rather than to serve these at each request from the original server. A web cache implements this function, and although various deployment models are possible, the cache itself always operates on the same basic principle; when a page is first requested (or has expired according to the page header information), the cache fetches the page from the web server on behalf of the requesting client. Subsequent requests until the expiry of the page are served directly from the cache, rather than from the original web server.
A cache can be operated in one of several modes:
• the cache may be made available on a given IP address and port, in which case the client machines must be configured to use the cache in preference to directly fetching pages from web servers
• the ISP may block outbound traffic leaving its network on port 80, so forcing clients to use the web cache
• the cache may also be implemented transparently, by redirecting traffic on port 80 to the ISP cache, without the client being reconfigured
However a cache is implemented, it typically generates several potential problems:
• web servers dislike the fact that the cache prevents them collecting statistics and data on ‘hits’ to the server. They may cause even static pages to expire instantly to thwart caching systems
• dynamic content in pages, for example CGI scripts, preclude web caching, so as pages become more dynamic, the effectiveness of caching reduces. The configuration file for a cache normally includes a setting to exclude URLs containing ‘cgi-bin’ from caching
• although cache hits (i.e. where a requested page is in the cache) are very responsive, cache misses (i.e. where the page is not in the cache) may be very unresponsive
In short, effective web caching is a difficult engineering issue.
In the simple configuration shown in Figure 23, a web cache is contacted on port 3128 (the well-known proxy port) for the requested content, and it contacts the original server on port 80 (the well-known HTTP port).
www.wraycastle.com
www.wraycastle.com GET w
ww.wraycastle.com
GET w
ww.wraycastle.com
GET www
.wraycastle.com
www.wraycastle.com
www.wraycastle.com GETwww
.wraycastle.com
GET w
ww.wraycastle.com
www.wraycastle.com Page
expiry period
. . . .
Figure 23
Web Cache Operation
For a given domain, it is a requirement of registration that at least one secondary domain server is implemented, and normally two secondary domain servers are implemented for extra resilience; without an operating name server, most transactions involving the domain will fail. These servers should be physically separate, and ideally served by completely different infrastructure, to minimize the risk of a single point of failure.
The simplest configuration of public name server services has the ISP providing entries in its name servers for the customer domain.
However, in some cases, the customer may wish to operate the primary name server, and have the ISP operate secondary name servers for resilience.
In order to implement one or more secondary name servers homed to a corporate primary name server, careful configuration of all of the servers is necessary:
• the parent domain, for example the .com domain for our example, should list all of the name servers for the domain directly
• the primary name server should permit zone transfers from the named
secondary servers, while normally (for security reasons) blocking all other zone transfers
• the secondary name servers should be configured with the details of the primary name server, specifically its IP address to allow transfers to take place
ns1.wraycastle.com
ns2.myISP.com
wraycastle.com IN NS ns1.wraycastle.com IN NS ns2.myISP.com IN NS ns3.myISP.com
Internet private
network
Figure 24
Providing Secondary Nameservers
DNS caches are operated by large enterprises as well as ISPs to speed the resolution of information from the global DNS. They are not definitive for any domain, and carry out recursive DNS queries. In other words they will request a DNS resolution on behalf of their clients. DNS software normally includes a setting that allows forwarding of requests that the DNS itself cannot resolve. This type of operation is known as recursion.
The service provided by an ISP normally includes providing a DNS cache as part of the client configuration. For dial-up accounts, the IP address of the DNS cache is normally provided as part of the Dynamic Host Configuration Protocol (DHCP) when the client machine connects.
For client networks that access the Internet via an access router, this router normally operates as a DNS forwarder. Although definitions vary, it is useful to think of a forwarder as a special case of a cache that holds no cache information. Because it holds no DNS data, all requests are forwarded to the designated name server, which in this case will normally be the ISP cache, as before.
This forwarding action can be used to implement internal and external DNS for a client within the corporate network, as follows:
• requests are sent to a local name server in the business domain, which resolves requests for hosts internally
• because the corporate DNS cannot resolve Internet addresses, these are passed to the Internet DNS for resolution
Figure 25 shows this scheme for as dial-up network, where DHCP from the ISP is used to assign the public dial-up router address for the client (192.168.1.1 in this example), and a DHCP server also operates within the dial-up router to provide IP addresses to the private network clients (in this example the internal address of the DHCP server is 10.0.0.1, and it assigns addresses in the range 10.0.0.0/24). Each DHCP dialogue lists the correct DNS server, so that DNS requests from internal hosts are passed to the dial-up router, which in turn forwards them on to the ISP cache for resolution.
DHCP configuration IP address: 192.168.1.1 IP address mask: 124
Gateway address: 192.168.1.254 DNS server address: 192.168.1.100
DHCP configuration IP address: 10.0.0.X IP address mask: 124 Gateway address: 10.0.0.1 DNS server address: 10.0.0.1
IP address: 192.168.1.1 IP address mask: 124 Gateway address
DNS server address: 192.168.1.100 forwarderDNS
DNS Configuration through DHCP
Any large organization will typically be operating an internal DNS, as well as making some parts of the corporate DNS visible on the public Internet. At least two Internet name servers are required for the public parts of the domain, and multiple name servers may be configured within the corporate network to provide fast and efficient name resolution between sites, or to partition the administration tasks between divisions or geographies.
This combination of public and private DNS entries requires the DNS to operate as a split DNS, for security reasons. In a split DNS architecture, the DNS is divided into two types of logical platform:
• a public name server provides resolution of the public DNS fields of the enterprise
• a private name server provides resolution from internal and trusted sources Corruption of name server data can be a very effective method of mounting DoS and masquerading attacks against a domain. It is extremely important that internal host information is not visible from the Internet. The DNS application should be hardened in various ways beyond the basic splitting described above, but this is a more detailed topic than can be covered in this introduction to the subject.
public
Authoritative for public zones
Listed in parent zones as NS records Queried by Internet name servers Non-recursive
forwarders or resolvers
Recursive for trusted sources through ISP name server cache
Figure 26
Implementing a Split DNS
2 What are the advantages of DHCP over static configuration of host IP parameters?
3 The PPP protocol is widely used in dial-up Internet access because:
a it is the most efficient link layer protocol
b it includes additional protocols to support dial-up user, including link and IP configuration
c it operates end-to-end between IP hosts, whereas other link layer protocols are limited to the access network only
d it can carry multiple network layer protocols, using its NLPID field, rather than just IP
4 Local loop unbundling may be:
a physical b logical
c neither a nor b d both a and b
5 Explain how a sending mail server would discover the IP address of the mail server it wishes to send SMTP mail to.
6 When might a business with its own Internet domain use an ISP-hosted secondary mail server? How would the MX preference records be set in this case?
7 Dynamic content can be generated for web pages using:
a server-side programming b client-side programming c neither a nor b
d both a and b