> 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(at)elan.net <william@elan.net> [2004-12-04 16:14]:
> 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
that is how it works.
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.
these lookups are cheap, and with increasing deployment I expect the
the vast majority of lookups to have matches on /32 (1st query) or /24
(2nd query). but anyway, these lookups are reasonably cheap.
> 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
that is how it works.
> 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.
these lookups are cheap, and with increasing deployment I expect the
the vast majority of lookups to have matches on /32 (1st query) or /24
(2nd query).
The problem is going to be for early adaptors - they have to do all
4 lookups because at the time nobody would have these records. There
are also problems because sometimes in-addr tree deligation is not
properly setup and lookups on it time out (and you have to wait for
timeout for each of those lookups).
but anyway, these lookups are reasonably cheap.
There are some here who may disagree if they see this deployed
(like say ARIN and other RIRs...)