Subject: Draft: non-wildcard bit.

From: Bruce Campbell <[email-masked]>
Date: Thu, 23 Oct 2003 22:38:18 +0200 (CEST)

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.

I'd like to put forward the following draft (submitted before the
deadline, but currently in rfc-editor pre-meeting limbo) as _a_ solution
to this problem, and see any on-list discussion on this solution before
Minnie.

   http://www.ripe.net/home/bruce/draft-bcampbell-dns-non-wildcard-00.txt

   This document intends to describe a method of detecting the presence
   of a synthesised answer to a DNS query by the usage of a flag bit.
   It also suggests that the same flag be used to request that a
   synthesised answer not be returned.

Note that 'flag bit' would either be the currently reserved header bit 9,
or an EDNS option.

-- 
                             Bruce Campbell         I speak for myself.

( Of course, a perhaps far better, solution would be to have the zones
  signed and widespread deployment of DNSSEC-aware resolvers. )

--
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: Thu, 23 Oct 2003 21:58:56 +0000

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

that's not obvious at all.

---

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

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

---

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: 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'
> 

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.

> 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.

---

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