The problem is that you've just spec'ed SSP to use a protocol that
is not DNS. It's fairly similar to DNS, but it's not DNS. I can't
imagine the IESG accepting that in a standards track document.
No, it's perfectly compliant DNS. Really, it is.
Unfortunately, it's not, because AXFR is part of the DNS spec. We now
know that they should have separated out the part about query
resolution, which has to interoperate everywhere, and server side
database management which doesn't. But they didn't, and if you can't
do it with AXFR and IXFR, it's not official DNS. Also don't forget
the DNSSSEC issues, which I gather have to do with walking the tree of
names, something that internal wildcards makes more difficult.
The question of wildcards internal to names has been around for years.
Everyone except extreme DNS fundamentalists agrees that they would be
very useful, but they haven't converged on a workable design and we're
unlikely to do it here.
I think I'm a DNS fundamentalist, and I think it's a fine idea.
No, if you were a DNS fundamentalist, you'd be saying it's trivial to
add ten million explicit records to a zone so it's not a problem that
wildcards for one type don't cover nodes with data of another type,
and new record types are easy to add so you don't need anything more
than the current wildcards. (I.e.., if I were AOL, I would like to
tell the world that my dialup farm doesn't receive mail via:
*.AOL.COM MX .
but since they have all those A records for the addresses in the farm
you need to put an explicit MX next to every A record.)
How is "MX ." working out for you? Not a rhetorical question - it's
likely the closest we have to a standard for "I don't send email"
today
Actually, I haven't tried it, but I should. Doesn't have much to do
with SSP, though, other than that it does the useful part of what SSP
proposes to do.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html