Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

DNS Lookup Chain Error Block for Ark UI

A full-screen page for an address that can't be found: an editable address, a Run the check button, and the lookup drawn as five hops that walk one at a time and stop at the one with no answer.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Show people where a lookup failed instead of only that it did, with this DNS resolution error for React with Ark UI. It's a whole screen with the page's rails and one band across it, split in two by a hairline that meets both rules at a plus mark. At the start, a mark, the headline, a Field with an Input holding an address that doesn't exist, and the Shine Button Run the check, the only colored control. At the end, the lookup drawn as five hops down a line: your device, the local resolver, the provider's resolver, the root server and the authoritative server, each with a shape and a word. Running the check walks the hops one at a time, 150 ms apiece, and stops at the one with no answer; edit the address to the one name the demo knows and the walk completes with a time for each hop. A status line says the result. The band's rules come from Guides, and the entrance is CSS only. For an app with an in-app web view, a link checker or any page that opens addresses.

FAQ

Does it look anything up?

No. The hops, their times and the names are typed in the file: fieldcrew.example and portal.fieldcrew.example resolve, and every other well-formed address stops at the root server (FAIL_AT). The walk is a chain of 150 ms timeouts that starts when you press Run the check and ends when it reaches its stop. To wire it, call your resolver or a lookup endpoint from the handler and fill the hops from what it returns.

What if I enter something that isn't an address?

The check validates on press, never disabling the button: an empty field gets "Enter an address to check.", something that isn't a host name gets "Enter an address like fieldcrew.example.", and either way focus goes to the field. Typing clears the sentence. The field is read-only while the walk runs, and the address is shown left to right even on a right-to-left page.

Why show five hops?

Because a lookup really passes through them: the device's own cache, the network's resolver, the provider's resolver, the root servers and the server that holds the record. Where it stops tells you who to ask: a failure at the first hops points to the device or the network, one at the root or the authoritative server points to the name itself. Edit STEPS to change the chain and FAIL_AT to move the failing hop.

How can you tell the hops apart without color?

By shape and word: a solid square and a time for a hop that answered, a cross and "No answer" for the one that didn't, a dash and "Not reached" for those after it, a dashed circle and "Waiting" for those still to come, and a spinning dashed circle for the one being asked. The failing hop's name stays in the text color; its cross is the only status color.

Is it usable with a keyboard and a screen reader?

Tab reaches the address and Run the check; Enter in the address runs it too. While it walks, a polite status message says "Checking northharbor.example…", and when it stops focus moves to the result line, which names the host and the hop that had no answer, because the busy button drops focus. The hops are an ordered list, so a screen reader reads each name and its state in order.

How does it look on a phone?

The two halves stack, with the address and Run the check first so the button is on the first screen, and the chain below under its own rule. The hop names and their times keep one row each down to 320 px.