On Sat, 15 Jan 2005, Julian Mehnle wrote:
Are there any other known use-cases for a new wildcard beyond
SPF zone cut defaulting?
Permit to to answer this first.
If new wildcards were to be interpreted as "prefix.**" then this would
allow for SRV record wildcards which people do want and from time-time
talked about. Even without it for MX it becomes possible to specify
default mail forwarding for all subdomains which also has some use.
It is probably of direct use with LOC and GPOS (location data) and there
might be some use for it with NAPTR. For inaddr it becomes possible
to specify default info for entire ip block (this BTW makes it a lot
easier to use MTAMARK to distinguish mail hosts from other hosts). There
maybe other uses too.
What have the namedroppers guys been saying about introducing a new
wildcard?
This is part of the response to my private email on this subject from Paul
Vixie, back from May 2004:
| > Also I'm forwarding my message on this subject (actually wider than just
| > MARID) expanding on idea of creating "default" wildcard-like record for
| > each authoritive zone and having dns servers synthesize response based on
| > it just like it is done with normal wildcard (but this default would only
| > apply to particular TYPE and would be based on "reverse" wildcard notation)
| > My view is that it should be possible to add this functionality to BIND
| > without requiring change to dns protocol, but perhaps I'm wrong and I've
| > bad feeling that this may have problems with non-bind implementations if
| > they dont have concept of authority zone and possibly have issues with
| > caching servers as well.
|
| there's no way you're going to get a dns protocol extension added in time
| to help MARID, unless your development cycle is about five years.
This is what he said on namedroppers to days ago in
http://article.gmane.org/gmane.ietf.dnsext/6435
| > Should I take as that you're willing to support such a feature (synthetic
| > wildcard for existing hostname but without needed RR) in future versions
| > of bind?
|
| no. i misspoke. BIND will implement the dns protocol as defined by the
| ietf, with occasional experimental features if those do not violate the
| protocol defined by the ietf.
|
| > In that case it makes sense for this to become a new dns protocol
| > feature so that other dns servers would know how to support it too, so
| > I think it would be good idea to write it out as ietf document
| > (separate and not just part of spf draft).
|
| even though i misspoke, there's a path forward illuminated by the mistake.
| if you want rrtype-specific wildcards, like for example an "**" label in
| a zone file should be a wildcard but only for the rrtypes at the "**"
| node, then go ahead and propose it. if ietf approved such a standard,
| then BIND will implement it. i suspect that the process would be too
| long for SPF'srequirements.
I'm not seeing a "NO" answer, if anything I view this as invitation to
go ahead and write a draft to be discussed at namedroppers. We could
could try to get this ready by IETF62 but there is now only about month
left before draft's publication deadline, so planning this for IETF63
(Paris meeting in the summer) would probably be better and I imagine
at least one person with great interest in spf and who happens to have
lots of experience in dns would be there...
Of course, a warning is in order - if you think its hard to get new feature
or extension passed at IETF in general and that it takes quite long, then
its several times harder and takes longer at namedroppers and of course
that list is notorious for heated discussions, polarizing views and often
has difficult time reaching consensus on issues. I've personally tried
subscribing to that list 3 times over last 4 years, each time (except
currently) I left after about 2 months when the discussions there got
too much for me...
And all that is despite (or possible because of) that there is moderation
on the list which is also know for being kind heavy-handed (you even see
complaints about it on main ietf list), in fact just couple days ago
one of my messages got flagged down with moderator writing:
| As moderator I'm not approving this long message as it is too hard to
| read please fell free to repost after condensing the contents and get
| rid of all the fluff (like header flag lines etc.)
As you image my reaction to "fluff" and to the suggestion of removing
dns header flags from DIG which are essential for dns debugging was
rather negative to say the least ...
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net