DEV Community: Jino R Krishnan

DNS Explained: How Your Browser Decodes Website Addresses

Jino R Krishnan — Fri, 26 Jun 2026 12:25:46 +0000

You type www.google.com into your browser and hit Enter. The page loads in under a second.

But stop and think about what just happened. Your browser didn't know where Google lives on the internet. It had to ask. And in that fraction of a second, a surprisingly elegant chain of lookups took place behind the scenes.

That system is called DNS — the Domain Name System. Think of it as the internet's phonebook: it translates human-friendly names like www.google.com into machine-friendly IP addresses like 142.250.80.46. Without it, you'd have to memorise numbers to visit any website.

Let's walk through exactly what happens, step by step.

Step 1: You Type a URL — But What Does It Mean?

When you type www.bing.com, you're entering a domain name. Domain names have a structure — and reading them right-to-left tells you a lot:

www . bing . com
 │      │     │
 │      │     └── Top-Level Domain (TLD): category or country
 │      └──────── Second-Level Domain (SLD): the brand/org name
 └─────────────── Subdomain: a section of the site (optional)

Some real examples:

Domain	TLD	SLD	Subdomain
`www.bing.com`	`.com`	`bing`	`www`
`news.bbc.co.uk`	`.uk`	`bbc`	`news`
`docs.github.com`	`.com`	`github`	`docs`

TLDs indicate the type or origin of a site — .com for commercial, .edu for education, .in for India, and so on.

Step 2: Your Browser Checks Locally First

Before going anywhere on the internet, your browser does a quick local check — two of them, actually.

1. Browser cache
Modern browsers cache DNS results from previous lookups. If you visited bing.com five minutes ago, the browser already knows its IP and skips the entire lookup process.

2. The hosts file
Your operating system has a plain text file that maps domain names to IPs manually. On most systems it lives at:

Windows: C:\Windows\System32\drivers\etc\hosts
Mac/Linux: /etc/hosts

It looks like this:

127.0.0.1    localhost
192.168.1.10 mydevserver.local

Developers use this all the time for local testing — mapping a production domain name to a local IP to test before going live.

If neither cache nor hosts has an answer, the real DNS lookup begins.

Step 3: Your OS Asks a Recursive Resolver

Your OS passes the query to a Recursive Resolver (sometimes called a Recursive DNS server). This is typically provided by your ISP, but you can override it with public ones:

Provider	DNS Address
Google	`8.8.8.8`
Cloudflare	`1.1.1.1`
OpenDNS	`208.67.222.222`

Pro tip: Switching to 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google) can noticeably speed up DNS resolution and improve privacy over your ISP's default resolver.

The Recursive Resolver is the workhorse. It does all the legwork of finding the answer so your device doesn't have to.

Step 4: The Resolver Walks the DNS Hierarchy

If the Recursive Resolver doesn't have the answer cached, it begins a top-down walk through the DNS hierarchy. There are three layers:

Layer 1 — Root Servers

The resolver first contacts one of the 13 root server clusters distributed worldwide (operated by IANA, Verisign, NASA, and others). These servers don't know the final answer — they just know who to ask next.

Full list of root servers → iana.org

The root server responds: "For .com domains, go talk to this TLD server."

Layer 2 — TLD Servers

The resolver contacts the TLD server for .com. Again, it doesn't have the final IP — but it knows which authoritative name server is responsible for bing.com.

.com delegation data → iana.org

Layer 3 — Authoritative Name Server

Finally, the resolver reaches the Authoritative Name Server for bing.com. This server holds the actual DNS records for the domain — and it returns the IP address.

The full journey looks like this:

Your Browser
    │
    ▼
Recursive Resolver  ──── checks cache ──► found? return it
    │ (cache miss)
    ▼
Root Server  ──────────────────────────► "ask the .com TLD server"
    │
    ▼
TLD Server (.com)  ────────────────────► "ask bing.com's name server"
    │
    ▼
Authoritative Name Server (bing.com)  ─► "the IP is 204.79.197.200"
    │
    ▼
Recursive Resolver caches the result
    │
    ▼
Your Browser connects to 204.79.197.200

Step 5: Caching Saves Everyone Time

Every response in that chain comes with a TTL (Time To Live) — a number in seconds that tells resolvers how long to cache the answer.

bing.com.   300   IN   A   204.79.197.200
               │
               └── TTL: cache this for 300 seconds (5 minutes)

Once the answer is cached at the Recursive Resolver level, subsequent queries from anyone using that resolver skip the entire walk. This is why DNS is fast at scale even though the hierarchy seems deep.

When a site's IP changes (e.g. migrating servers), admins lower the TTL beforehand so the old IP expires quickly everywhere.

Bonus: Common DNS Record Types

DNS isn't just about IP addresses. A domain can have multiple record types:

Record	Purpose	Example
`A`	Domain → IPv4 address	`bing.com → 204.79.197.200`
`AAAA`	Domain → IPv6 address	`bing.com → 2620:1ec:c11::200`
`CNAME`	Alias to another domain	`www.bing.com → bing.com`
`MX`	Mail server for a domain	`bing.com → mail.bing.com`
`TXT`	Arbitrary text (SPF, DMARC, verification)	`"v=spf1 include:..."`
`NS`	Name servers for the domain	`bing.com → ns1.msft.net`

As a developer, you'll interact with all of these — especially A, CNAME, MX, and TXT — whenever you deploy an app, configure email, or verify domain ownership.

A Word on Modern DNS: DoH and DoT

Traditional DNS queries travel in plain text — anyone on the network (your ISP, a coffee shop router) can see every domain you resolve. Two modern protocols address this:

DNS over HTTPS (DoH): Wraps DNS queries in HTTPS, making them indistinguishable from regular web traffic
DNS over TLS (DoT): Encrypts DNS on port 853

Both Chrome and Firefox support DoH natively. Cloudflare's 1.1.1.1 and Google's 8.8.8.8 support both. Worth enabling if privacy matters to your users or your app.

The Full Picture

Here's the complete DNS resolution flow in one view:

1. User types www.bing.com
2. Browser cache? → Hit: done. Miss: continue.
3. OS hosts file? → Hit: done. Miss: continue.
4. Recursive Resolver cache? → Hit: done. Miss: continue.
5. Root Server → points to .com TLD Server
6. TLD Server → points to bing.com Authoritative Server
7. Authoritative Server → returns 204.79.197.200
8. Resolver caches result (TTL)
9. Browser connects to 204.79.197.200
10. Page loads

All of this typically completes in 20–120 milliseconds.

Wrapping Up

DNS is one of those invisible foundations that the entire web sits on. As a developer you'll hit it constantly — debugging propagation delays after a deploy, setting up custom domains, configuring email records, or hardening your app's privacy with DoH.

Understanding the hierarchy (Root → TLD → Authoritative) and the role of caching and TTLs takes a lot of the mystery out of those moments when "the DNS hasn't propagated yet."

Next time you type a URL, you'll know exactly what's happening in those milliseconds.

By Jino R Krishnan — Full Stack Developer

From API to AI: Transform Your .NET + SQL App into a Conversational Web App Using NLWeb, GPT-4o, and the Microsoft Agent Framework

Jino R Krishnan — Fri, 26 Jun 2026 12:04:58 +0000

Updated for 2026 — covering NLWeb's evolution since Build 2025, the shift from Semantic Kernel to Microsoft Agent Framework, GPT-4o, and Cloudflare's managed NLWeb deployment path.

Natural language interfaces are no longer a novelty — they're the new baseline expectation. Users increasingly expect to ask your app questions the same way they'd talk to a colleague. With Microsoft's NLWeb, you can retrofit your existing .NET + SQL application with a conversational layer without rebuilding it from scratch. In this updated guide, we'll walk through the full process using the latest tooling available in mid-2026.

What is NLWeb? (2026 Update)

NLWeb is an open-source protocol from Microsoft, conceived by R.V. Guha (the creator of RSS, RDF, and Schema.org), that lets any web property respond to natural language queries directly — without a search engine acting as intermediary. Think of it as what HTML did for publishing: a universal, open standard that makes your site a first-class citizen of the emerging agentic web.

Every NLWeb instance is also a Model Context Protocol (MCP) server, exposing your content to AI agents via two key endpoints:

/ask — for human-facing conversational queries
/mcp — for agent-to-agent discovery and tool calls

Since its announcement at Build 2025, the ecosystem has matured significantly:

Cloudflare added native NLWeb support via its AutoRAG infrastructure in early 2026, offering a fully managed deployment path
Microsoft joined the MCP Steering Committee and contributed an updated authorization spec and MCP server registry design
Build 2026 featured NLWeb prominently in the Agents and Apps track, alongside .NET 11's new agentic web building blocks

NLWeb is technology-agnostic — it supports all major LLMs, vector databases, and operating systems.

What's Changed Since the Original Guide

Area	Original (May 2025)	Updated (June 2026)
Model	GPT-4	GPT-4o (default)
Orchestration	Semantic Kernel (experimental agents)	Microsoft Agent Framework (MAF) — GA in Q2 2026
.NET Version	ASP.NET Core (unspecified)	.NET 11
NLWeb Deployment	Manual self-hosted only	Manual or Cloudflare AutoRAG (managed)
Embeddings	`text-embedding-3-small`	`text-embedding-3-small` / `text-embedding-3-large`

Architecture Overview

User
 └─► NLWeb UI (/ask endpoint)
      └─► ASP.NET Core (.NET 11) Controller
           └─► Microsoft Agent Framework
                ├─► GPT-4o (Azure OpenAI)
                ├─► Embedding + Vector DB (Azure AI Search / Qdrant)
                └─► SQL Server
                     └─► Schema.org JSON response back to NLWeb UI

Prerequisites

.NET 11 Web API project (ASP.NET Core)
Microsoft SQL Server
Node.js (for the NLWeb UI demo)
Azure OpenAI access (GPT-4o + text-embedding-3-small)
A vector database: Azure AI Search (recommended), Qdrant, Pinecone, or Weaviate
Docker (optional, for deployment)

Step-by-Step Setup

Step 1: Clone NLWeb

git clone https://github.com/microsoft/NLWeb.git
cd NLWeb

Key folders:

code/ — Python reference implementation and /ask endpoint logic
demo/ — Embeddable frontend UI
docs/ — MCP protocol and Schema.org response specs

Step 2: Run the NLWeb UI

cd demo
npm install
npm start

This launches a local chat interface. Queries are POSTed to your backend's /ask endpoint. You can also embed the UI snippet directly into any webpage.

Step 3: Understand the NLWeb Request/Response Contract

Incoming request to your API:

{
  "query": "What are the top-selling products this month?",
  "context": []
}

Expected response (Schema.org JSON-LD):

{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "itemListElement": [
    {
      "@type": "Product",
      "name": "Wireless Mouse",
      "description": "Ergonomic wireless mouse",
      "offers": {
        "@type": "Offer",
        "price": "29.99",
        "priceCurrency": "USD"
      }
    }
  ]
}

NLWeb renders this structured response as a conversational answer in the UI.

Step 4: Install the Microsoft Agent Framework (MAF)

MAF is the production-ready successor to Semantic Kernel's agent layer, reaching GA in Q2 2026. It merges the best of AutoGen and Semantic Kernel into a single, cleaner SDK.

dotnet add package Microsoft.Extensions.AI
dotnet add package Microsoft.SemanticKernel
dotnet add package Microsoft.Agents.AI.OpenAI
dotnet add package Azure.AI.OpenAI

Note for existing SK users: Semantic Kernel v1.x is supported until at least one year after MAF GA. Your plugins and vector store integrations migrate cleanly — the mental model is identical, just with a cleaner API surface.

Step 5: Update Your .NET 11 API

Define the Query Model

public class NLWebQuery
{
    public string Query { get; set; } = string.Empty;
    public List<string> Context { get; set; } = new();
}

Create the Controller

[ApiController]
[Route("api")]
public class NLWebController : ControllerBase
{
    private readonly INLWebAgentService _agentService;

    public NLWebController(INLWebAgentService agentService)
    {
        _agentService = agentService;
    }

    [HttpPost("ask")]
    public async Task<IActionResult> Ask([FromBody] NLWebQuery query)
    {
        var schemaOrgResponse = await _agentService.ProcessAsync(query.Query, query.Context);
        return Ok(schemaOrgResponse);
    }
}

Step 6: Build the Agent Service with MAF

This is where the 2026 approach differs significantly. Instead of manually chaining prompt → vector search → SQL, the Microsoft Agent Framework handles orchestration.

using Microsoft.Extensions.AI;
using Microsoft.Agents.AI;
using Azure.AI.OpenAI;
using Azure.Identity;

public class NLWebAgentService : INLWebAgentService
{
    private readonly IChatClient _chatClient;
    private readonly IVectorSearchService _vectorSearch;
    private readonly IProductRepository _productRepo;

    public NLWebAgentService(
        IChatClient chatClient,
        IVectorSearchService vectorSearch,
        IProductRepository productRepo)
    {
        _chatClient = chatClient;
        _vectorSearch = vectorSearch;
        _productRepo = productRepo;
    }

    public async Task<object> ProcessAsync(string query, List<string> context)
    {
        // 1. Embed the query
        var relevantContext = await _vectorSearch.SearchAsync(query, topK: 5);

        // 2. Build prompt with retrieved context
        var systemPrompt = $"""
            You are a data analyst for an e-commerce platform.
            Based on the context below, generate a SQL query to answer the user's question.
            Return ONLY the SQL — no explanation.

            Context:
            {string.Join("\n", relevantContext)}
            """;

        var messages = new List<ChatMessage>
        {
            new(ChatRole.System, systemPrompt),
            new(ChatRole.User, query)
        };

        // Add conversation history for contextual follow-up
        foreach (var prior in context)
            messages.Insert(messages.Count - 1, new(ChatRole.Assistant, prior));

        // 3. Call GPT-4o via MAF
        var response = await _chatClient.CompleteAsync(messages);
        var sql = response.Message.Text;

        // 4. Execute SQL
        var data = await _productRepo.ExecuteQueryAsync(sql);

        // 5. Return Schema.org JSON
        return FormatAsSchemaOrg(data);
    }
}

Register Services in Program.cs (.NET 11)

var builder = WebApplication.CreateBuilder(args);

// MAF: Layer 1 - IChatClient (provider-agnostic)
builder.Services.AddSingleton<IChatClient>(_ =>
    new AzureOpenAIClient(
        new Uri(builder.Configuration["AzureOpenAI:Endpoint"]!),
        new DefaultAzureCredential())
    .GetChatClient("gpt-4o")
    .AsIChatClient());

// Vector search (Azure AI Search recommended for .NET + enterprise)
builder.Services.AddSingleton<IVectorSearchService, AzureAISearchService>();
builder.Services.AddScoped<IProductRepository, SqlProductRepository>();
builder.Services.AddScoped<INLWebAgentService, NLWebAgentService>();

builder.Services.AddControllers();
var app = builder.Build();
app.MapControllers();
app.Run();

Step 7: Prepare SQL Data for Vector Search

Before your app can do semantic retrieval, you need to embed your SQL data and store it in your vector database.

// One-time ingestion pipeline
public async Task IngestProductsAsync()
{
    var products = await _db.Products
        .Select(p => new { p.Id, p.Name, p.Description, p.Category })
        .ToListAsync();

    foreach (var product in products)
    {
        var text = $"{product.Name}: {product.Description} (Category: {product.Category})";
        var embedding = await _embeddingClient.GetEmbeddingAsync(text);

        await _vectorDb.UpsertAsync(new VectorRecord
        {
            Id = product.Id.ToString(),
            Vector = embedding,
            Metadata = new { product.Name, product.Category, SourceTable = "Products" }
        });
    }
}

Best practices for 2026:

Use hybrid search (keyword + semantic) in Azure AI Search for best recall
Embed at the right granularity — row-level for products, paragraph-level for FAQs
Store SourceTable and RowId in metadata for traceability and debugging

Step 8: Format the Response as Schema.org

private object FormatAsSchemaOrg(DataTable table)
{
    return new
    {
        @context = "https://schema.org",
        @type = "ItemList",
        itemListElement = table.Rows.Cast<DataRow>().Select(row => new
        {
            @type = "Product",
            name = row["Name"],
            description = row["Description"],
            offers = new
            {
                @type = "Offer",
                price = row["Price"],
                priceCurrency = "USD"
            }
        })
    };
}

Step 9: Test the Full Flow

Start your .NET API: dotnet run
Start the NLWeb UI: npm start in the demo/ folder
Type: "What are the top-selling products this month?"
Observe the full pipeline: query → embed → vector search → GPT-4o → SQL → Schema.org JSON → conversational answer in UI

Bonus: Add Memory and Context Persistence

For multi-turn conversations, persist chat history using Redis or SQL and pass it back with each request:

// Store turn history in Redis
await _cache.SetStringAsync($"chat:{sessionId}", JsonSerializer.Serialize(history));

MAF handles the concept of a session/conversation thread natively — no manual history wiring needed if you use its agent abstraction.

Alternative: Managed Deployment with Cloudflare AutoRAG

If you don't want to manage the NLWeb infrastructure yourself, Cloudflare now offers a one-click managed path:

Go to Cloudflare Dashboard → AI → AI Search
Select Create AI Search → Website
Choose NLWeb Worker — Cloudflare automatically deploys the /ask and /mcp endpoints
Point the NLWeb UI to your Cloudflare Worker URL

This is ideal for teams that want NLWeb running in production without managing vector DB infrastructure or NLWeb server updates manually.

Resources

Final Thoughts

A year on from NLWeb's announcement, the ecosystem has grown from a promising experiment into a solidifying standard. With Cloudflare's managed path, .NET 11's native agentic web support, and the Microsoft Agent Framework replacing the more fragmented Semantic Kernel agent APIs, the integration story is significantly cleaner in 2026.

The core idea remains the same: your existing .NET + SQL data is more valuable than you're exposing through a traditional REST interface. NLWeb, GPT-4o, and vector search give your users a natural language front door to that data — whether they're humans typing questions or AI agents making autonomous requests.

The agentic web is here. Your app should be part of it.

By Jino R Krishnan | Updated June 2026

How the Web Stays Connected

Jino R Krishnan — Fri, 26 Jun 2026 11:42:47 +0000

When you type a website address into your browser, you probably don’t think about the intricate global infrastructure that makes it all work. Behind the scenes, a handful of organizations ensure that the internet remains stable, secure, and universally accessible. Two of the most critical players in this ecosystem are ICANN and IANA.

In this blog, we’ll dive deep into:

What ICANN and IANA are
Their roles in the global internet infrastructure
The technical systems they manage
Why they are essential to the functioning of the internet

What is ICANN?

ICANN stands for the Internet Corporation for Assigned Names and Numbers. It is a non-profit organization founded in 1998 and headquartered in Los Angeles, California.

ICANN’s Core Responsibilities:

Domain Name System (DNS) Management: ICANN oversees the global DNS, which translates human-readable domain names (like example.com) into IP addresses (like 93.184.216.34).
IP Address Allocation: ICANN allocates blocks of IP addresses to Regional Internet Registries (RIRs), which then distribute them to ISPs and organizations.
Protocol Parameter Assignment: ICANN, through IANA, manages protocol identifiers used in internet protocols (like port numbers and MIME types).
Root Zone Management: ICANN coordinates changes to the DNS root zone, the top-level of the DNS hierarchy.

What is IANA?

IANA stands for the Internet Assigned Numbers Authority. It is a department within ICANN that performs the actual technical coordination of key internet resources.

IANA’s Three Main Functions:

1. IP Address Management

IANA allocates large blocks of IP addresses to the five RIRs:

ARIN (North America)
RIPE NCC (Europe, Middle East)
APNIC (Asia Pacific)
LACNIC (Latin America)
AFRINIC (Africa)

2. DNS Root Zone Management

IANA maintains the root zone database, which includes:

Top-Level Domains (TLDs) like .com, .org, .net, and country codes like .uk, .jp
Name servers for each TLD

3. Protocol Assignments

IANA manages registries for protocol numbers, port numbers, and other parameters used in internet protocols, in coordination with the Internet Engineering Task Force (IETF).

The Technical Backbone: How It All Works

The DNS Hierarchy

The Domain Name System is structured like a tree:

. (root)
├── com
│   └── example.com
├── org
│   └── wikipedia.org
└── net
    └── speedtest.net

At the top is the root zone, managed by IANA. Below that are Top-Level Domains (TLDs), and beneath them are second-level domains (like example in example.com).

Root Servers

There are 13 root server letters (A to M), operated by different organizations around the world. These are not single machines but clusters of servers using anycast routing to provide resilience and speed.

A Root: Operated by Verisign
B Root: Operated by USC-ISI
...
M Root: Operated by WIDE Project (Japan)

These servers respond to DNS queries for the root zone and direct them to the appropriate TLD name servers.

How a DNS Query Works

You type www.example.com into your browser.
Your computer asks a recursive resolver (usually your ISP).
If the resolver doesn’t know the answer, it asks a root server.
The root server replies with the address of the .com TLD server.
The resolver asks the .com server for example.com.
The .com server replies with the address of the authoritative server for example.com.
The resolver asks that server for www.example.com.
The IP address is returned, and your browser connects to the website.

Why ICANN and IANA Matter

Without ICANN and IANA:

There would be no global coordination of domain names or IP addresses.
The internet could fragment, with different regions using conflicting systems.
Security and trust in the internet would erode.

These organizations ensure that the internet remains a single, interoperable network for everyone.

Other Key Organizations

IETF (Internet Engineering Task Force): Develops and maintains internet protocols.
W3C (World Wide Web Consortium): Develops web standards like HTML and CSS.
ISOC (Internet Society): Advocates for open internet development.
RIRs (Regional Internet Registries): Distribute IP addresses regionally.

Governance and Controversies

ICANN operates under a multi-stakeholder model, involving:

Governments
Private sector
Civil society
Technical community

This model has faced criticism and praise. Some argue for more governmental control, while others defend the decentralized, community-driven approach.

Final Thoughts

ICANN and IANA are the unsung heroes of the internet. Their work is invisible to most users but absolutely essential. They ensure that when you type a URL, send an email, or stream a video, everything just works.

Understanding these organizations helps us appreciate the complexity and beauty of the internet’s design — and the importance of keeping it open, secure, and well-governed.