is reverse dns required? (policy question)

william(at)elan.net william at elan.net
Sat Dec 4 15:41:07 UTC 2004



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
william at elan.net




More information about the NANOG mailing list