Re: [apps-discuss] "finding registered domains"

[Phillip Hallam-Baker <[e-mail]>]

I was not there for John's comments but from what I gather of them
second hand I completely disagree.

It does not matter what the DNS was designed to do twenty years ago.
That is a debate for historians. What the DNS was intended to be has
never been the same as what people used it for or found value in. The
fact that people use the DNS in ways that were not anticipated by the
designers is not a bug, not something to be corrected.


How the users of the Internet use the DNS is all that matters now.
Telling people that they don't want to do what they are trying to do
is silly and insulting.

There is an implicit administrative hierarchy in DNS. There is a real
world distinction between DNS delegations that are private and those
that are public. The applications layer of the Internet has built on
those assumptions for the past twenty years


What would be a mistake is to propose the use of any infrastructure
that is not DNS to publish authoritative statements about DNS names.
That would be a violation of the Internet architecture. Please, no
more talk about WEIRDS or whatever other protocol someone might see a
chance to find a use case for.

I do not need the full capabilities expressed in Andrew's draft. In
fact I only need two statements, both of which could be specified in a
new DNS RR or if we don't want to add new RRs we could even use the
existing CAA record and express them as properties.


The properties I need to be able to express in a domain are:

PUBLIC - This domain is a public delegation point
PRIVATE - This domain is not a public delegation point
EXCLUDED - This domain is excluded from the enclosing private space.


So taking the example of ai.mit.edu we would have:

edu          PUBLIC
mit.edu    PRIVATE
ai.mit.edu   EXCLUDED

edu is a public delegation point. Anyone with a school can get a domain.

mit.edu has domains registered below it but it is not a public
delegation point. You have to be affiliated to MIT to get a domain.
There is an accountability infrastructure in place.

ai.mit.edu was a sub domain but one that always had a separate network
administration which might mean that it was appropriate for it to be
declared as being separate from the rest of the *.mit.edu space so
that cross site issues were avoided in both directions.

Note that all the above information are simple statements of fact that
the administrators of the domain might make. Interpretation of those
statements is a completely different matter.


The mere fact that a domain has an assertion in the DNS at issue time
does not mean that I am automatically going to rely on it when issuing
certificates. We crawl the web constantly. If the information being
published now is inconsistent with the information published
consistently for the past 4 years, that may require a closer look.

I would expect that the information proposed would be used to inform
the compilation of 'public prefix lists' but those are going to remain
a curated resource. Publication in DNS is not ideal but a lot better
than an open access wiki (see error 81).


We have in the next 12 months an opportunity to tell ICANN that we
would like the winners of the new TLDs to publish records declaring
the public delegation points. This has essentially zero cost to ICANN
but allows the maintenance of public prefix lists to scale in the wake
of the TLD expansion.

All that is necessary to make that happen is to provide a clear and
simple specification for those TLD operators to deploy. If we miss
that window it will be a lot harder.


When I started this note I was thinking that re-use of CAA was a bit
of a hack. But considering the fact that the division between public
and private was one of the main design issues we ended up having
problems with, it actually looks like a pretty clean fit to me right
now.