Penn’s DNS Zone

Some data from a quick analysis of the contents of the University of Pennsylvania’s primary DNS zone (upenn.edu):

Zone: upenn.edu.
  Total RR     = 624221
  Total RR     = 159928 (excluding DNSSEC records)
  Total RRsets = 464295
  Total RRsets = 155165 (exluding DNSSEC records) 
  Total Names  = 154570
  TTL min, max, avg = 0, 114000, 38562
  
  RRtype             Count        %
  A                 145684    23.3%
  AAAA                 388     0.1%
  CNAME               9476     1.5%
  DNSKEY                 3     0.0%
  MX                  1363     0.2%
  NS                    10     0.0%
  NSEC              154564    24.8%
  RRSIG             309723    49.6%
  SOA                    1     0.0%
  SRV                 2961     0.5%
  SSHFP                  4     0.0%
  TXT                   41     0.0%
  TYPE65534              3     0.0%

Penn is mostly one big DNS zone (ignoring the reverse DNS zones for now). We don’t delegate subdomains to units and divisions within the university. However, we do have a home grown DNS content management system (called “Assignments”) that allows units to manage DNS records within their assigned subdomains inside the same zone. Assignments issues updates to the DNS server using the Dynamic Update protocol authenticated with a static transaction signature (TSIG) key. And DNS records are automatically signed (with generation of related DNSSEC metadata) as they are inserted into the zone. Assignments only supports a limited range of DNS record types today, and since we don’t have a lot of inhouse programming resources to continue developing it, longer term we hope to be able to migrate away from it to a more capable opensource or commercial system. One of the challenges in doing so is that the current system is very tightly intertwined with a variety of other systems unrelated to DNS (billing, security contacts, machine inventory data, etc). The authoritative DNS servers themselves run ISC’s BIND software.

There are 624,221 resource records in total, but almost three quarters of those are DNSSEC metadata records (RRSIG and NSEC). There are many more RRSIG records than NSEC (there is one NSEC per domain name, whereas there is one RRSIG for every RR set). There are 3 DNSKEY records: 1 Key Signing Key (KSK), and 2 Zone Signing Keys (ZSK). Only one of the ZSKs is active and used to sign zone records; the other is pre-published for future key rollovers. The KSK is 2048-bit RSASHA1, the ZSKs are both 1024-bit RSASHA1. The zone was first signed in August 2009, but we had to wait another year for the parent zone (EDU) and the root to be signed. A secure delegation (DS record) for Penn was installed into the EDU zone in August 2010. The 3 private type records (TYPE65534) are used by BIND to record some dynamic signing state. I gave a talk with more details about Penn’s DNSSEC deployment plans at the Summer Internet2 Joint Techs conference in July 2009.

Excluding DNSSEC, there are 159,928 records. The vast majority of them are A records (145,684). Compared to a year ago, that represents an 8% increase. By contrast, the number of AAAA records has more than doubled from 180 to 388. Most of the AAAA records are likely IPv6 enabled servers, so that’s probably a promising sign of growth. Penn currently uses stateless autoconfiguration for IPv6 client addresses, and such addresses, by and large, are not registered in the DNS. In the near future, we’re planning a limited production rollout of DHCPv6 to some campus subnets. If that happens, pools of DHCPv6 client address ranges will have pre-populated DNS records, which will drive up the AAAA record count significantly.

The TXT records are mostly used for DKIM and SPF. Although the central Penn mail servers do not currently use either, a number of departmental and school mail servers do. E-mail, like many other services at Penn, is highly decentralized.

There are 5 nameserver (NS) records at the zone apex. Two are Penn servers with both IPv4 and IPv6 address records. Two are servers operated by the University of Delaware, with whom we have a reciprocal secondary DNS service arrangement - these have IPv4 addresses only. And the last one is sns-pb.isc.org, a dualstack global anycast cloud operated by Internet Systems Consortium. SNS-PB is the public benefit version of ISC’s Secondary Name Service.

  ;; [nameserver names]
  upenn.edu.        86400    IN    NS    noc2.dccs.upenn.edu.
  upenn.edu.        86400    IN    NS    noc3.dccs.upenn.edu.
  upenn.edu.        86400    IN    NS    dns1.udel.edu.
  upenn.edu.        86400    IN    NS    dns2.udel.edu.
  upenn.edu.        86400    IN    NS    sns-pb.isc.org.

  ;; [nameserver addresses]
  dns1.udel.edu.        86400    IN    A    128.175.13.16
  dns2.udel.edu.        86400    IN    A    128.175.13.17
  noc2.dccs.upenn.edu.  86400    IN    A    128.91.254.1
  noc2.dccs.upenn.edu.  86400    IN    AAAA    2607:f470:1002::2:2
  noc3.dccs.upenn.edu.  86400    IN    A    128.91.251.158
  noc3.dccs.upenn.edu.  86400    IN    AAAA    2607:f470:1003::3:3
  sns-pb.isc.org.       7200     IN    A    192.5.4.1
  sns-pb.isc.org.       7200     IN    AAAA    2001:500:2e::1

I’m looking forward to more application use of DNSSEC signed data to verify crypto material. There are a handful of SSHFP records today (mostly my own test systems). Hopefully, we’ll see some DANE/TLSA records in the near future.