[dns-operations] [QUAR] Reducing AS112 traffic

[Joe Abley]

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  
> serve
> (the most popular external DNS service is often 4.2.2.1,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  
it's dumb.

> 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  
> their
> 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  
those enterprises?

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  
successfully authenticate.

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  
> DNS
> 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.


Joe