Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt

["John R. Levine" <[e-mail]>]

> If bootstrapping via DNS is sufficient for the reverse DNS domain 
> queries, is query load the main reason it isn't also sufficient for IP 
> network queries?

I could have sworn we went over all this last week, but anyway, ...

Query load is only part of the reason.

Domain names are allocated a TLD at a time, so a reasonable boostrap is to 
use the TLD name as the handle.  It doesn't matter that the .COM server 
gets 3000 queries/sec, since the vast majority of bootstrap queries for 
com.domain.rdap.arpa will be satisfied from local caches.  Due to both the 
ICANN new TLD program and the number of existing TLDs, it seems likely 
that the bootstrap data will change fairly often, so we need something 
that automatically updates clients when there's a change, hence DNS.

Marc's draft says "longest match", but in fact the IANA domain registry is 
all TLDs so just doing the TLD lookup rather than the whole name is 
adequate and makes the DNS caches work.

Numbers are different.  For IPv4 you could fake it by using the top octet 
of the address, but for IPv6 and ASNs the allocation structure is 
extremely irregular and I don't see any way to represent it in the DNS 
with reasonable performance.

If you do the obvious thing for IPv4 and IPv6 and use something that looks 
like rDNS, e.g. 4.3.2.1.ip4.rdap.arpa. or 
f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.ip6.rdap.arpa, 
and cover the DNS namespace with DNS wildcards, you get pessimal DNS cache 
behavior, i.e., none at all.  Each query for a different address goes back 
to the bootstrap server which synthesizes a unique response per address, 
which means vast traffic on the rdap.arpa servers, and DNS caches filling 
up with useless junk, since a cache entry is only reused if it exactly 
matches a previous query.

The longest allocated IPv6 prefix is a /23, but even if you truncate the 
bootstrap queries to 24 bits (for 4 bit rDNS boundaries) you're still 
going to need 4096 real or synthesized entries for each allocated /12, 
with basically the same problems.

Even worse, the ASN space is flat, with allocated numbers ranging from 1 
to 394,239 with some large unallocated holes.  A DNS zone of that size is 
not going to make DNS servers or DNS caches happy.  Even if we invented a 
rDNS like representation to make it easier to cover ranges with wildcards, 
it'd have the same performance problems.

It's perfectly possible to represent the allocation information in a 
compact and efficiently searchable form (it is, after all, on three pages 
at IANA), but not by using the formats that the DNS provides.  The number 
bootstrap data changes very rarely, like once a year or less, so it's OK 
for the update not to be automatic.  Hence the per-TLD DNS lookup for the 
regularly named but frequently updated and uncoordinated DNS registries, 
and the vague baked-in bootstrap hack for the irregularly named, but 
rarely updated and well coordinated RIRs.

Does that make more sense?

R's,
John