[dns-operations] [QUAR] Reducing AS112 traffic
jabley at ca.afilias.info
Tue Nov 13 13:24:59 UTC 2007
On 12-Nov-2007, at 18:06, Sidney Faber wrote:
> First, there's the large corporate network where HQ has control of the
> routing infrastructure, but not the DNS infrastructure. HQ acts as an
> ISP for its branch offices. They can not configure empty zones to
> (the most popular external DNS service is often 188.8.131.52,2).
My immediate reaction to that is that the enterprise is broken.
Relying on the availability of two random open resolvers in remote
networks is hardly sensible, and it seems very wrong for any advice to
enterprises to accommodate that practice rather than pointing out that
> They can
> potentially stand up a site-local AS112 node, but it's not easy.
I'm interested in precisely what is difficult about this. If you have
any insight, I'd like to hear it.
> It is
> easy for them to ACL addresses, they do it all the time to protect
> infrastructure. Is it a legitimate alternative to recommend they ACL
> the traffic?
I don't hear any of the AS112 operators complaining about the traffic
they are sinking, so presumably the motivation here is for enterprises
to stop leaking internal traffic onto the Internet for the benefit of
Changing the manner in which DNS queries are answered for any client
has the potential to have strange consequences. A client which
operates one way when it gets an NXDOMAIN from an AS112 server might
act in a very different way if the same query leads to a timeout, or
to a host unreachable reply.
For example, there was a period some years ago after Bill Manning
turned down the 10.in-addr.arpa (and friends) authority server he was
running and before the AS112 service went live in which the RFC1918
delegations from the IN-ADDR.ARPA zone became lame.
The unusual consequence I saw was that many DSL services in New
Zealand stopped working: the telco was originating a RADIUS request to
ISP authentication servers using an RFC 1918 address, and the RADIUS
timeout for the client was shorter than the reverse DNS timeout on
ISPs' RADIUS servers, with the result that suddenly nobody could
Clearly the dependency on reverse DNS working in ISPs' RADIUS servers
was not sensible, and the fix was to remove it. However, the
dependency was not obvious before the the queries stopped failing.
Advice to enterprises which exposes other unexpected problems might be
philosophically sound, but it's going to have the practical effect
that the advice won't be followed because "it breaks things".
> Second, there's the wandering laptop. Granted, not a big traffic
> generator, perhaps not a big deal, but perhaps something we can deal
> with. The laptop's configured by policy to dynamically register its
> connection to prisoner.
So, perhaps the laptop's configuration should be fixed? Again,
recommending ways to mitigate the effects of broken configuration
seems ultimately less helpful than suggesting that broken
configurations should be fixed.
More information about the dns-operations