> > you're right. neither does this one.
>
> I'm having imagination failure. How can your scheme work with traditional
> wildcards? (i.e. without rewriting the wildcard semantics).

since noone is currently querying for names under _app.$DOMAIN, we have the
opportunity to require multiple queries. therefore to simulate the effect
of a nonterminal wildcard such as:

mail_exchanger._app.**.VIX.COM.

we can put in nodes of the form:

mail_exchanger._app.VIX.COM.
*.mail_exchanger._app.VIX.COM.

and clients can be told that if they're looking for a mail_exchanger._app
for a service name of FOO.VIX.COM, they should look up two DNS names:

mail_exchange._app.FOO.VIX.COM.
FOO.mail_exchange._app.VIX.COM.

this is NOT AS CLEAN and relies heavily on negative caching, which is ill
supported in the current dns ecosphere. but it would work using current
wildcard semantics. i'd rather add nonterminal wildcards, move all wildcard
and other synthesis to clients, and add subtypes. but that's a ten year
project and we probably have a one month budget, just like always.

> > the type-covered field in RRSIG functions effectively as a subtype,
> > and when we were discussing it we didn't try to generalize it. very
> > sad, but not too late. if you think a subtype would be easier to
> > shoehorn in than a subdomain, i'm listening. frankly, i'd like to
> > have both, but i consider the subtype or any other change to the
> > q-tuple to be even more violent than moving the synthesis processing
> > would be.
>
> Agree - that's what I meant by invasive. But it is probably "the right
> thing to do" (tm).

if we succeed in injecting some money and coherency into this field, using
MODA and perhaps other efforts, then we could reasonably "do both". we all
know that DNS could never have been designed under a regime like the current
IETF, nor SMTP or NNTP or probably TCP or IP. i recommend that we work
toward putting more boats in the water to see which ones really float, and
that we put better boats in the water to get a better idea of "why".

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: