Distributed Naming & Virtualization: Namespaces, DNS, Virtualization, and Abstraction

TAKEAWAYS:

• Distributed naming resolves ambiguity by mapping logical names (e.g., user@bank.com) to physical addresses (IPs) via hierarchical schemes like DNS.
• Virtualization (hardware/software) decouples resources (CPU, storage) from physical machines, enabling resource pooling and efficient allocation.
• Transparency (e.g., location, migration, replication) hides distributed complexity from users, making systems behave like centralized ones.
• Naming services (DNS, LDAP) and virtualization (containers, VMs) are foundational for cloud services (e.g., Daraz’s microservices, NTC’s network virtualization).
• Trade-offs exist: virtualization improves efficiency but adds overhead; naming schemes must balance scalability and resolution speed.
• Security risks (e.g., DNS spoofing, virtual machine escape) require encryption, access controls, and isolation mechanisms.

1. Distributed Naming: Why Names Matter in Distributed Systems

In distributed systems, resources (processes, files, services) must be uniquely identified and located. Unlike centralized systems, where a single address space suffices, distributed systems use logical names (e.g., https://www.daraz.com) that map to physical addresses (IPs, ports). This avoids ambiguity and enables scalability.

1.1 Definitions: Name vs. Address vs. Identifier

Visualization:

1.2 Naming Schemes: Hierarchical vs. Flat

• Hierarchical Naming (e.g., DNS, file systems):

  • Uses dots/slashes to organize names (e.g., www.daraz.com → com → daraz → www).
  • Enables locality: queries can be resolved incrementally (e.g., daraz.com asks its DNS server first).
  • Example: DNS resolves google.com by querying root → TLD (.com) → authoritative server.

  graph TD
      A["User Requests: google.com"] --> B["Root DNS Server"]
      B --> C["TLD Server (.com)"]
      C --> D["Authoritative Server for google.com"]
      D --> E["Returns IP: 142.250.190.46"]

• Flat Naming (e.g., UUIDs, MAC addresses):

  • No hierarchy; each name is unique globally.
  • Used for stateless resources (e.g., cloud objects in AWS S3).
  • Disadvantage: No locality; every lookup requires a full network scan.

1.3 Worked Example: How Daraz Resolves daraz.com

1. User types daraz.com in a browser.
2. Local DNS resolver (e.g., NTC’s DNS) checks its cache. If missing:
   • Queries root DNS server for .com TLD.
   • Root replies with .com TLD server address.
   • Contacts .com server, which returns Daraz’s authoritative DNS (ns1.daraz.com).
   • Authoritative server returns IP: 52.74.215.112.
3. Browser connects to this IP, fetching Daraz’s website.

Why this matters: Without DNS, every website would require hardcoding IPs—impossible at scale.

2. Distributed Naming Services: DNS and Beyond

2.1 Domain Name System (DNS)

DNS is the phonebook of the internet, translating human-readable names to IPs. It uses a hierarchical, decentralized model with:

• Root DNS servers (13 global, e.g., a.root-servers.net).
• Top-Level Domains (TLDs) (.com, .np, .org).
• Authoritative DNS servers (hosts for specific domains, e.g., ns1.daraz.com).

DNS Record Types (for TU exams, memorize these 3):

DNS Caching:

• Local cache (browser/OS) stores recent resolutions to speed up future queries.
• TTL (Time-to-Live): Determines how long a record is cached (e.g., TTL=3600 = 1 hour).

Attack: DNS Spoofing (Cache Poisoning)

• How: Malicious server sends fake IP for a domain (e.g., banknepal.com → attacker’s IP).
• Impact: User’s browser connects to the attacker instead of the real bank.
• Mitigation: DNSSEC (Digital Signature), validating responses cryptographically.

2.2 Other Naming Services

3. Virtualization: Abstraction for Scalability

Virtualization hides physical complexity by creating virtual resources (VMs, containers, storage) that mimic physical ones. This enables:

• Resource pooling: Multiple virtual machines (VMs) run on a single physical server.
• Isolation: Failures in one VM don’t crash others.
• Portability: VMs can migrate across hosts without downtime.

3.1 Types of Virtualization

3.2 How Virtualization Works: The Hypervisor

A hypervisor (Type 1 or Type 2) manages VMs:

• Type 1 (Bare-metal): Runs directly on hardware (e.g., VMware ESXi).
• Type 2 (Hosted): Runs on top of an OS (e.g., VirtualBox on Windows).

graph TD
    A["Physical Server"] --> B["Type 1 Hypervisor (Bare-metal)"]
    B --> C["VM 1: Linux"]
    B --> D["VM 2: Windows Server"]
    B --> E["VM 3: Database Server"]
    A --> F["Type 2 Hypervisor (Hosted)"]
    F --> G["Host OS: Ubuntu"]
    G --> H["VM: Windows 10"]

3.3 Worked Example: NTC’s Network Virtualization

Nepal Telecom (NTC) uses network virtualization to:

1. Segment traffic: Separate corporate, residential, and mobile data using VLANs.
2. Optimize bandwidth: Prioritize VoIP (Pathao’s ride-hailing) over file downloads.
3. Isolate failures: A VLAN outage doesn’t crash the entire network.

Why this matters: Without virtualization, NTC would need separate physical networks for each service—costly and inflexible.

4. Transparency in Distributed Naming and Virtualization

Transparency hides distributed complexity from users. Key types:

Trade-off: More transparency → harder to implement (e.g., replication requires consistency protocols like Paxos).

5. Challenges and Security Risks

5.1 Naming Challenges

• Scalability: DNS must handle millions of queries/second (Google’s DNS processes ~100M queries/day).
• Dynamic Updates: Services (e.g., Pathao’s driver locations) change frequently; naming must adapt.
• Ambiguity: What if user123 exists in multiple databases? Use qualified names (e.g., user123@banknepal.com).

5.2 Virtualization Security Risks

Example: In 2017, Meltdown/Spectre exploits exposed data from VMs by reading CPU cache. Fixes included hypervisor patches and hardware updates.

6. Real-World Applications

In the real world

1. eSewa’s Payment Gateway:

   • Naming: Uses a service discovery system to route payments to the correct bank’s API (e.g., banknepal-payment-service).
   • Virtualization: Runs payment processors in Docker containers on cloud servers, scaling dynamically during festivals.

2. Daraz’s Microservices:

   • Naming: Each service (checkout, inventory, shipping) has a unique logical name (e.g., checkout-service:8080) resolved via Consul.
   • Virtualization: Uses Kubernetes to orchestrate containers, ensuring high availability during Black Friday sales.

3. NTC’s SDN (Software-Defined Networking):

   • Virtualization: NTC’s core network uses OpenFlow to dynamically route traffic, isolating corporate and residential users without physical hardware changes.

Exam Tip

This unit tests conceptual understanding and application of naming/virtualization. Focus on:

1. Definitions: Know the difference between name, address, and identifier. Draw the DNS resolution flow.
2. Virtualization Layers: Memorize the 4 types (hardware, network, OS, application) and their examples.
3. Transparency Types: Explain location transparency with an example (e.g., CDN).
4. Security Risks: For DNS, mention spoofing and DNSSEC. For virtualization, highlight VM escape and side-channel attacks.
5. Real-World Links: Connect concepts to eSewa, Daraz, NTC (e.g., "Daraz uses Kubernetes for container orchestration").
6. Diagrams: Always include a DNS resolution flow or hypervisor architecture in answers.

Common Pitfalls:

• Confusing DNS with LDAP (DNS is for names → IPs; LDAP is for user directories).
• Forgetting that virtualization adds overhead (e.g., VMs are slower than bare-metal).
• Not explaining why transparency matters (e.g., "users shouldn’t care where a service is hosted").

Sample Answer Structure for 20 Marks:

1. Define distributed naming (2 marks).
2. Compare hierarchical vs. flat naming with examples (4 marks).
3. Explain DNS resolution with a diagram (6 marks).
4. Describe virtualization types and their use cases (4 marks).
5. Discuss security risks in virtualization (4 marks).

Final Note: This unit is highly visual. For exams, draw the DNS flow and label the hypervisor layers. Use real examples (eSewa, Daraz) to show how theory applies. Avoid vague answers—always tie concepts to scalability, transparency, or security.