[dns-operations] Reducing AS112 traffic

Sidney Faber sfaber at cert.org
Mon Nov 12 15:44:07 UTC 2007

This is a follow-up to the AS112 presentation from the LAX OARC meeting
(http://public.oarci.net/files/workshop-2007/Faber-AS112v2.pdf).  Thanks
for the feedback, I'm working on making a stronger case for data
exfiltration via AS112 (if one exists), and I'll forward results as they

In the mean time, I know some folks would like to block AS112 traffic,
and I'd like to give them some advice.  The audience is varied, but
consider the typical medium-to-large enterprise admin.  They may have
access to any subset of workstations, DNS servers, firewalls or the
routing infrastructure.  I've tried to come up with some reasonable
solutions to implement at different layers and outline pros & cons of
each.  Do these sound reasonable?  Have I missed anything?  Thanks!

1.  Make your DNS server authoritative for:
    Any other internal-only address blocks
    Works the way the system was intended
    Doesn't cover roving clients
    Clients have to use your DNS servers

2.  Do not allow clients to perform DNS updates
    Keeps mobile clients safe when they’re roaming
    Updates are now centrally controlled at the DHCP server
    Requires enforcement on *all* IP-enabled devices
    Misconfigured mobile guest on your network may still expose
      some topology
    Only affects UPDATE records, PTR records must be controlled
      separately (see #1)

3.  Create A records in your zone for prisoner.iana.org,
    blackhole-1.iana.org and blackhole-2.iana.org to sink
    traffic locally
    Simple, easy to manage
    Requires access to DNS servers
    Clients must use your DNS servers

4.  Block all inbound and outbound traffic
    Easy to implement at network chokepoints
    Zero risk of blocking legitimate traffic
    If clients are not given a cachable negative reply, they often
       become more aggressive:  this is likely to amplify unwanted

5.  Reroute AS112 to an internal server
    This essentially creates a local AS112 anycast node
    Successful, proven solution
    Exercise caution not to become a sink for other networks
      (what if later on someone drops a T1 into your network?)
    Technically more difficult

6.  Configure IDS to alert on (or IPS to block) AS112 traffic
    Uses existing infrastructure
    Might identify unauthorized access points
    Potential for excessive alerts
    IPS blocking could cause clients to become aggressive (see #4)

Sid Faber, Member of the Technical Staff
Software Engineering Institute
Carnegie Mellon University
sfaber at cert.org

More information about the dns-operations mailing list