On Sat, 4 Dec 2004, Henning Brauer wrote:
> > The wildcards are in the DNS server zone file for interpretation by the > > DNS server itself. It would not be published as such because that obviously > > wouldn't work as you prove. But nothing is preventing BIND or whatever > > from taking this wildcard record and answering every request with the > > wildcard "_send._smtp._srv.*" RR if no more-specific exists. This should > > be relatively straight forward to code. Wouldn't want to touch the code > > base of BIND but for DJBDNS I could somewhat easily implement it. The question remains what to do when zone is transfered between different dns servers (AXFR and such). Even completely syntetic wildcard still needs to be documented in DNS specs. What is proposed above I proposed about year ago privately to Paul Vixie, he said it'll take number of years to push it through the standard, perhaps he can comment more about it now and explain problems with above approach better. > eh? > no need to... > > Thus we propose expanding the reverse DNS tree with a subdomain with > the well known name > > _srv > > This subdomain MAY be inserted at any level in the DNS tree for IPv4 > IN-ADDR.ARPA reverse zones. For IPv6, to limit the number of DNS > queries, _srv is only queried at the /128 (host), /64 (subnet) and / > 32 (site) level. That way it can either provide information for a > specific IP address or for a whole network block. More specific > information takes precedence over information found closer to the top > of the tree. So if I want to check on 127.1.2.3, I first do lookup on _srv.3.2.1.127.IN-ADDR.ARPA if that does not give any answer, I'll have to do lookup on _srv.2.1.127.IN-ADDR.ARPA if that does not give any answer, I'll have to do lookup on _srv.1.127.IN-ADDR.ARPA And if that does not work, I still have to do lookup on _srv.127.IN-ADDR.ARPA Is that how you expect it to work? If that is so, I do not like it because it forces to do these multiple lookups. -- William Leibzon Elan Networks [EMAIL PROTECTED]
