RE: [sitefinder-tech-discuss] Technical issues encountered by a k 12 site

[Bruce Campbell <bruce.campbell@ripe.net>]

On Wed, 8 Oct 2003, Hollenbeck, Scott wrote:

> Wildcards have been a part of the DNS specification since standard 13 (RFCs
> 1034 and 1035) was published in 1987.

Yes.

> If I was writing code to use
> the DNS, I'd consider the possibility of receiving a synthesized response
> because the possibility is clearly outlined in the resolution algorithm
> described in RFC 1034.

4.3.3 of the same document mentions in passing that:

	The general idea (of wildcards) is that any name in that zone
	which is presented to server in a query will be assumed to exist,
	with certain properties, unless explicit evidence exists to the
	contrary.

and 4.1.1 of 1035 mentions (NXDOMAIN):

		Name Error: Meaningful only for responses from an
		authoritative name server, this code signifies that the
		domain name referenced in the query does not exist.

So most application coders would be happy with 'either the host exists, or
it does not, and I am not fussed as to whether its a synthesised existence
or not'.

> So -- with wildcards and synthesized responses being a part of the DNS specs
> for the last 16 years, why didn't your in-house code account for the
> possibility of receiving a synthesized response from the DNS if a
> synthesized response can be a problem for you?

Most application coders have implicitly trusted that there is a right
place, and a wrong place, for wildcards in the DNS tree (see my previous
post on this), and that for the most part, the existence of a wildcard
does not change the behaviour of the application; ie, if a wildcard is
there, its there for a good reason.

Once you start putting the logic of 'right' and 'wrong' wildcards into
applications, you also start running into inconsistencies between various
application's implementation of wildcard detection.  For instance,
Application Foo may consider that a 2nd-level wildcard (*.com) is not ok,
but a 3rd-level wildcard (*.example.com) is ok.

However, if you throw Application Bar, which knows that certain 3rd-level
wildcards (*.com.au) are not ok, into the mix, you now have two
wildcard-aware Applications which behave differently under certain
situations.

Hence, if you do wildcard detection, you also need to know at which level
and portion of the DNS tree the wildcard occured at, and hopefully be
consistent with the behaviour of other applications that do wildcard
detection.

> I'm trying to understand
> how others have interpreted the specifications when writing code and why
> they made the decisions they did.  If it's just a matter of "hey, we used
> existing libraries and we trust how they work", that's cool.

The most common interface used by coders, gethostbyname, essentially
returns one of 'host exists', 'host does not exist' or 'failure of some
sort'.  It would be easy to have the resolver libraries perform wildcard
detection (at the cost of a DNS lookup to the authoritative servers each
time as wildcards should not be cached (1034 4.3.3)), but what should be
done with the result?  A blanket 'wildcards not accepted' will cause the
application to not work in situations where wildcards are valid.

> I'm also asking because something that came up during yesterday's open
> meeting with ICANN's Security and Stability Committee was a question about
> whether or not the DNS protocol should be updated to provide a way for
> clients to know when a response has been synthesized.  Would that be
> something that's valuable to application developers?

It would be easier for low-level application writers to know that a
response was synthesised (thus saving a query (or queries) for a
wildcard), but it doesn't answer the question of where it was synthesised
(implying that applications that care will need to requery anyway).

-- 
                             Bruce Campbell             I speak for myself

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.elistx.com/unsubscribe>