Nameserver & DNS Delegation Audit

An inventory diff flags github.com, a vendor you depend on: its eight nameservers do not all sit on the same network. Two networks serving one zone is either deliberate redundancy or the visible half of a hijack, and the diff cannot tell you which.

Do I raise a delegation-hijack ticket on this domain, and what would tell me I am wrong?

Not "how many nameservers does it have". That count is an input, and here it reads reassuring while saying nothing about what matters.

• When the delegation was observed. Each of the eight NAMESERVER_FOR edges into github.com carries source: "dns" and inferred: false, and no other property — 8 of 8, measured 2026-08-09. You learn where the record came from, never how old it is: a delegation changed this morning and one stable for years are the same row. Freshness is stated on Coverage, not on the edge.
• Whether a nameserver answered. lame means the hostname has no RESOLVES_TO edge here, not that somebody queried it and got silence. On tvmadness.pro both nameservers read lame, and both are named as addresses — 193.452.2.1 and 193.453.2.1 — which cannot be IPv4 at all, since the second octet exceeds 255. Nothing was probed; something was missing.
• The difference between "not delegated" and "never seen". Both print ns_count: 0, and an unknown name returns that row alongside an empty listing in the same run. Connections explains why this edge is traversed backwards.
• Who is allowed to change the delegation. github.com carries HAS_REGISTRAR, PREV_REGISTRAR and REGISTERED_BY edges. This audit reads none of them, and no step touches DNSSEC, so registrar state and zone signing stay outside the answer — whisper.identify() is where that half lives.

Eight nameservers, and every one resolves: four awsdns hostnames and four in the p08.nsone.net pool. Zero lame rows. The placement step returns two ASN names for those eight, AS16509 — AMAZON-02 · Amazon.com, Inc. and AS62597 — NSONE · NSONE Inc: the networks agree with the hostnames, which is the first fact arguing against a hijack.

The registry step returns com → VeriSign Global Registry Services. Its own note says a gTLD such as .com has no operator node; on 2026-08-09 it returned one, so read the row rather than the note.

A domain with no delegation on record comes back as a populated row saying 0, never as an empty result set that means "clean": zero rows is never a verdict — first hypothesis, a wrong query.

There is no score on this workflow. The number that plays its part is ns_count, and it reads 8.

Eight nameservers, two operators. count(DISTINCT asn) over the same eight returns 2, measured 2026-08-09. Redundancy against an operator failing is two, not eight — the other six fail with their pool. Run the same pair on google.com and the gap is sharper: ns_count 4, distinct ASNs 1, every one of them AS15169 — GOOGLE · Google LLC. Four nameservers, one blast radius.

That is the fact the count discards, and it settles the alert: two ASNs on one zone is the design, not the anomaly. The shape worth a ticket is a nameserver on a network with no authoritative-DNS business, and the asn_name column is the whole test.

Take the estate verdict at face value and it will mislead you. For github.com it returns COMMODITY, most_exclusive_ns_size 15,407; the busiest of the eight, dns1.p08.nsone.net, serves 386,759 hostnames, and its sample siblings come back as 1688.ag, 1688a.ag, 1688b.ag. Co-tenancy proves nothing here, which is the verdict doing its job.

The band below it is the trap. In a sample of 400 nameservers taken in graph order, every nameserver serving three domains or fewer was a bare address rather than a hostname — 194.48.203.119, 172.16.0.10, 193.452.2.1 and five more, 8 rows of 8. On this data the ATTRIBUTION-GRADE band and the lame column draw from one population: NS records written as addresses. A boutique verdict is a claim to check by hand, not to act on.

The bands are edges, not gradients. wikipedia.org returns nameserver_count 3, most_exclusive_ns_size 993, MIXED — seven domains below the boundary that would have printed COMMODITY. The queries, with their measured output, are on DNS & email security.

github.com's delegation is two independent DNS operators, not a hijack: eight nameservers, zero lame, AS16509 and AS62597 whose names match the nameserver hostnames, .com run by VeriSign. Close the ticket, and record the number the summary did not give you — operator redundancy is two.

Four things would overturn that, each a query rather than an opinion:

• a nameserver placed on an ASN with no authoritative-DNS business — the asn_name column re-read, not the ASN count;
• a lame row on a nameserver that is a real hostname, which is the delegation gap this workflow is named for;
• inferred reading true on a NAMESERVER_FOR edge — all eight read false, and a delegation the graph inferred is weaker evidence than one it read from DNS;
• registrar and transfer state, which this workflow never looked at.

One last thing: github.com is itself recorded as a nameserver for six hostnames, among them richlife.kz and 1145141919810.tech. Anyone can name your domain in their NS record, and the graph holds what was published. Every estate count inherits that.