Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 15 Oct 2004 12:38:14 -0700

The claims made in section 3.2 (below) do not accurately reflect 
the situation with wildcards.

The conclusion of MARID was that wildcards are actually irrelevant
as specified since they do not in fact work for any of the use cases.

The DNS really needs at least two wildcard types,

*   The current wildcard, if www.example.com exists the
    wildcard *.example.com will NOT match for ANY record.

*?  The wildcard people think they have and mostly want,
    TXT/*.example.com will match iff www.example.com exists
    but has no other TXT record.

As a matter of history quite a few DNS servers have actually
implemented the nonstandard *? wildcard which is one reason
for the confusion.

The use cases given in the MARID case did not work, in particular
is was not possible to construct a wildcard to say 'this machine
does not send mail' since *.example.com will not match
phill.example.com if there is ANY record for the node. The
use case is real but it cannot be met without *? style wildcards.

A wildcard properly understood is merely a notational convention
that is used in the configuration of the server. In the absence
of DNSSEC there is no real interoperability issue.

Even _WITH_ DNSSEC a server can implement *? wildcards 
synthetically, it just means enumerating the additional 
records for the nodes.

To make the prefix scheme work completely all that is needed
is to allow for midpoint wildcards, i.e. match on
_prefix.*.example.com and _prefix.*?.example.com

Fixing the NSEC/NXT record to meet these needs is not at all
difficult. 

If these changes are deployed then the RR type becomes merely
a syntax container and an infinite (OK 2^124) number of semantics
may be bound thereto by defining new prefixes. It is now
possible to deploy new RR semantics without the need to
upgrade ANY infrastructure whatsoever, everything flows
through the existing infrastructure. The only parties that
need to change are those who choose to use wildcards and even
for them the software change is a one time affair.

The difference in implementation cost is vast. Even with 
DNSEXT new RRs will require new software for any party deploying 
them. In the real world 'stick hex values in the config file'
is just not a viable solution. 

The RR architecture conflates syntax and semantics. The view
of RR as being a syntax container whose semantics are defined
by means of a prefix has already been established by SRV and 
NAPTR.

Section 3.5 Fails to tell the reader that a majority of deployed
DNS servers do not in fact provide support for new DNS records.
The claims that Windows platform DNS servers provide support
neglect to mention the lack of support for creitical features
such as the ability to remember settings after a restart and
the ability to do zone transfers.

The draft admits in section 4 that the purpose of the controls
is political and not technical. As such the draft is naive,
in order to maintain control it places a ridiculous and 
unnecessary burden on proposals. This only encourages parties
with an alternative view of how the DNS should work to seek
other venues and receive endorsement and approval in those 
venues. The W3C has already defined SRV entry points for 
protocols on an ad hoc basis.

The statement made in section 5 that recent surveys show that
deplyoment of a new RR are practical is factually incorrect.
The survey if it is the one I beleive is refered to (no citations
are given) actually states the reverse

As a matter of organization there are two sections purporting 
to be conclusions, both of which introduce new claims to
support the argument in an ad hoc fashion, mostly without
references.

The only disadvantage of prefixed TXT records is the loss of
wildcarding. The disadvantage of a new RR is serious, the
majority of the deployed DNS base does not support that 
application and this will not change for at least a product 
cycle, which means three years.

Application developers should be allowed to decide if the 
deployment advantage of prefixed DNS records outweighs the
loss of wildcards. It is an entirely reasonable engineering
decision.

If wildcarding is so spectacularly important then the group
will of course be anxious to fix it.

----Excerpt---
Add a prefix to the owner name

   By adding an application-specific prefix to a domain name, we will
   get different name/class/type triples, and therefore different
   RRsets.  The problem with adding prefixes has to do with wildcards,

   especially if one has records like

   *.example.com. IN MX 1 mail.example.com.

   and one wants records tied to those names.  Suppose one creates the
   prefix "_mail".  One would then have to say something like

   _mail.*.example.com. IN X-FOO A B C D

   but DNS wildcards only work with the "*" as the leftmost token in the
   domain name.

   Even when a specific prefix is chosen, the data will still have to be
   stored in some RR type.  This RR type can either be a "kitchen-sink
   record" or a new RR type.  This implies that some other mechanism has
   to be applied as well, with implications detailed in other parts of
   this note (see also draft-ietf-dnsext-wcard-clarify [wcardclarify]

--
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: Alex Bligh <[email-masked]>
Date: Fri, 15 Oct 2004 21:06:36 +0100

> use case is real but it cannot be met without *? style wildcards.

Does the latter (*?) actually need any protocol-level specification?

By which I mean is it not possible to
a) On a strictly conformant server, emulate *? with a macro (or similar),
   so
    *? IN TXT foo
    a IN TXT bar
    b IN MX baz
   becomes
    * IN TXT foo
    a IN TXT bar
    b IN MX baz
    b IN MX bar
b) If one wants to implement a server where * means "the other thing",
   i.e. *? (and you note some servers have done this), say "* in a zone
   file means *?" (and preferably provide a way to get *).

Alex