Steve Atkins wrote:
Wildcards are something of a hack, and I understand
there are significant incompatibilities in wildcard handling of
some records between different authoritative servers. I
think we'd be fine with simple usage, but anything subtle
should not[2] be suggested by anyone who isn't intimately
familiar with the operational issues with the various authoritative
servers out there.
hmmmmmm, interesting comment.
I think you got the wrong perception of me. Nonetheless, from the
start, I said I wasn't a "DNS administrator," but I am an seasoned
systems engineer and manager and when I don't see the "DNS
administrators" offering a solution themselves, then I will attempt to
provide input myself.
I think the "suggestions" I provided is the best so far.
First you said it doesn't work "at all." You were proven wrong.
Client resolving the gTLD/ccTLD cut off for the query question would be
the ideal solution for these requirements.
You say it is impossible.
Well, you haven't convince me that it is impossible.
I also said I will be studying the wildcard behavior of servers,
starting with Bind, by digging straight into the source.
Now you are basically implying we are beating on a dead horse because
the authoritative servers may not behave the same in this regard.
Well, if all this is true, we should stop wasting time and go straight
to a Wildcard/Masking definition concept at the TXT data itself, similar
to a SPF commands.
Do you have a suggestion for a TXT record format that offers subdomain
policy masking?
BTW, I wouldn't call it a hack if popular server like BIND has wildcard
masking logic built-in all over its lookup code. It is simple though:
file: bin\named\ns_init.c:
int
ns_wildcard(const char *name) {
if (*name != '*')
return (0);
return (*++name == '\0');
}
ns_wildcard() is used quite extensively, I would not call that a hack.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html