Subject: Re: Draft: non-wildcard bit.

From: Paul Vixie <[email-masked]>
Date: Thu, 23 Oct 2003 21:58:56 +0000

> With all the fuss on the unannounced addition of a wildcard record to the
> .com and .net zones, it is obvious that many applications need a clear and
> reliable method of knowing whether a response is 'real', or whether it has
> been synthesised.

that's not obvious at all.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Oct 2003 14:42:03 +0000

> > > With all the fuss on the unannounced addition of a wildcard record
> > > to the .com and .net zones, it is obvious that many applications
> > > need a clear and reliable method of knowing whether a response is
> > > 'real'
> 
> vix> that's not obvious at all.

about twice a year since 1994 i have begun planning an rfc called "what
the dns is not".  the opening paragraph always has these words: "DNS is
a distributed, hierarchical, reliable, autonomous database.  DNS deals
in facts, not values, and data carried in the DNS are facts, not opinions."

but then i always calm down before i can get the full rant figured, which
would include diatribes against DNS NAT and "middleboxes" of all kinds,
especially DNS-based load balancing appliances.

> A lot of the complaints regarding the wildcard deployment can be
> summed up as 'people do not trust' (verisign).  Hence, there is a need
> for people to have an assurance[1] that they are getting a response
> that does not point back to a service which is unsuited to their
> application/customer base/personal preference.

if the world doesn't trust verisign then the world ought to negotiate a
better contract or find a different registry.  it's bad enough that BIND
now has a feature which allows client-side content editing (delegation-only)
but let's not make our situation even worse by complicating the protocol
itself to cope with what's actually a layer 9 problem.

> In short, for each application, there are good and bad locations for a
> wildcard, and it is up to each site to define them.

an application should not behave differently because synthesis was used,
even if a more robust protocol would in fact move the act of synthesis
into the client-side for a number of unrelated but perfectly valid
reasons.