>> 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
