[dns-operations] Does this make sense?

[Michael Sinatra]

Hi,

Within our organization, we are using locally-routable RFC1918 addresses
for infrastructure and other local uses.  In other words, we route these
addresses within our AS, but (obviously) not outside of the AS, and we
don't do NAT on a large scale.

As more and more campus-only services use RFC1918 to conserve
globally-routable IP address space, it will of course be necessary to
resolve DNS for the RFC1918 address space.

We currently configure our organization's centrally-supported DNS
servers to only answer queries (either for PTR records or forward A
records) involving RFC1918 addresses that come from local clients.
(Forward records for RFC1918 addresses are kept in local-only subdomains.)

Here's the issue: Of course, a number of system administrators run their
own caching nameservers--either server-based caching resolvers that only
listen to localhost on a given server or standalone caching nameservers.
For the big clients, I have asked them to configure their servers to
reference the campus nameservers, either via zone transfer, stub zones,
forward zones, etc., for the RFC1918 reverse zones.  (The local-only
subdomains are in berkeley.edu so a caching resolver will be pointed to
our authoritative nameservers via delegation.)  However, for those who
set up local caching resolvers using essentially 'default'
configurations (i.e. no forwarding to our resolvers), they will not see
our authoritative nameservers for the reverse RFC1918 zones, even if
they are on campus.

For this reason, I would like to announce the AS112 addresses in our IGP
*only*, so that all caching resolvers will point to our nameservers to
resolve RFC1918 in-addr.arpa DNS.  One method would be for me to set up
our own standalone AS112 servers and have them announce the routes for
the well-known AS112 addresses.  But what would be even simpler would be
to simply place the AS112 addresses in the existing anycast
configuration of our anycast-configured authoritative nameservers and
let them announce those addresses (again, *only* within the IGP).

In the various AS112 documentation I have seen (as112.net, the two Joe
Abley internet-drafts, and some googling) there are references to
site-local AS112 servers, but very little specification of best
practices.  My own thoughts on this are that I will need to make sure
that our authoritative servers will need to serve *all* of the zones
that are served by the AS112 servers, including ones we currently don't
use, so that they will properly get authoritative NXDOMAINs.  I will
also ensure that the routes are ONLY announced in our IGP and DO NOT
leak into the global internet.

I will continue to advise operators of their own servers to configure
their caching resolvers to point directly to the campus's caching
resolvers, thereby preventing the first queries from hitting the root
servers before they cache the AS112 nameserver information.

I can't think of any problem that would arise if the well-known AS112
addresses on campus are actually authoritative for more than what's
actually delegated to them, since nobody would query them for that
information anyway.

Does anyone see any other gotchas, or is this just a stupid idea?


thanks,
michael