Subject: Re: Draft: non-wildcard bit.

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Oct 2003 22:45:11 -0000

Bruce Campbell writes:
> 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'

Exactly which applications are you talking about? What exactly is the
definition of a ``real'' DNS record? What exactly do you want these
applications to do with non-``real'' records?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

--
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: Chris Yarnell <[email-masked]>
Date: Thu, 23 Oct 2003 22:22:22 -0700 (PDT)

> reliable method of knowing whether a response is 'real', or whether it has

it is?  please explain.

---

From: Bruce Campbell <[email-masked]>
Date: Mon, 27 Oct 2003 14:07:54 +0100 (CET)

> > reliable method of knowing whether a response is 'real'

vix> that's not obvious at all.

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.

( Or, while wildcards and other synthesis methods are great ways of
  shooting off feet, one single entity should not be able to make the
  world dance. )

djb> Exactly which applications are you talking about?

I don't think that an 'exact' answer is possible, as the effects of this
wildcard deployment has not been understood on all applications.  In
general terms, I'm presuming that administrators of applications want
their applications to either talk only to the expected end host, or fail
immediately if a non-existing end host is supplied.  They do not want to
talk to an arbitary man in the middle in the latter case.

( Or, 'did you mean' is absolutely useless to most services except for
  those where human eyeballs are involved (web). )

djb> What exactly is the definition of a ``real'' DNS record?

In the draft, I've referred to 'real' DNS records as being
'non-synthesised'.  In more specific terms, a 'real' DNS record is one
which the nameserver software has done a straight read from the zone
file/database/etc to find the relevant label, and has not applied any
synthesis rules (wildcard processing or something else) to generate the
result.

( Or, if someone has manually put it into a file, its real )

djb> What exactly do you want these applications to do with non-``real''
djb> records?

'It depends'.

It depends on two things.  The specific application in use (eg, user
authentication vs random web browsing), and the location in the tree where
the wildcard has been detected (*.example.com is ok, *.com.au is not ok).
See section 5 of the draft for further commentary on this.

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

-- 
                             Bruce Campbell          I speak for myself

[1] Another way of getting that assurance is to follow the DNSSEC path.

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 27 Oct 2003 14:43:29 +0000 (Africa/Tunis)

> it is obvious that many applications need a clear and reliable
> method of knowing whether a response ... has been synthesised.

If zone owners really want to mark synthesized records, the protocol
already has a technique for doing that -- it's called signing the
zone.  I'm not inclined to spend more time developing another one.

If there's really demand for flagging synthesized answers, then
perhaps we should put forth a document requiring that any zone with
wildcards be signed.

-- Sam