update overall results with newly formatted histograms
authorDavid Blacka <david@blacka.com>
Sat, 19 Sep 2009 00:20:05 +0000 (20:20 -0400)
committerDavid Blacka <david@blacka.com>
Sat, 19 Sep 2009 00:20:05 +0000 (20:20 -0400)
bin/response_sizes.py
run/.gitignore
zone_results/root_overall_response_size_results.txt

index b3d1189..f8d94ee 100755 (executable)
@@ -181,7 +181,7 @@ if __name__ == "__main__":
     print >> sys.stderr, "Referral sizes (Maximum overall sizes):"
     print >> sys.stderr, max_ref_hist.to_text()
 
-    print >> sys.stderr, "NXDOMAIN sizes (Maximum truncation sizes):"
+    print >> sys.stderr, "NXDOMAIN sizes (Maximum overall sizes):"
     print >> sys.stderr, nx_hist.to_text()
 
     print >> sys.stderr, "Other response sizes (Full response sizes):"
index 01acb08..42070df 100644 (file)
@@ -1,3 +1,4 @@
 named.pid
 nsd.pid
 nsd.log
+xfrd.state
index 65a8391..91caa4a 100644 (file)
@@ -1,18 +1,28 @@
-I have some preliminary results from my root response size research.
 
 Executive Summary:
 
-   At KSK@2048, ZSK@1024, only the ./ANY response will truncate (set
-   the TC bit), and only ./RRSIG response will change (but not set TC)
-   with a max UDP size at 1400.
+   At KSK@2048, ZSK@1024, only the ./ANY and ARPA/ANY responses will
+   truncate (set the TC bit), and only ./RRSIG and ARPA responses will
+   change (but not set TC) with a max UDP size at 1400.
 
-   Capping our UDP response size is quite safe, and most users will
-   not be able to tell that we are doing it.
+Recommendations:
+
+   1) Use the "minimal-dnskey-response" behavior for the root
+   servers.  This behavior is supported by RDNS 2.3.2 and NCDNS 1.1.1
+   (as well as BIND 9.6 and NSD 3.2.3).
+
+   2) Cap our UDP responses sizes to 1472 (or optionally less, down to
+   1400).  The results below will show that this is safe.  In fact,
+   unless a user does a ./ANY or ./RRSIG (or similar query for arpa),
+   they won't be able to tell we are capping.  This is supported by
+   RDNS 2.3.2 (via the "max_udp_size" option) and NCDNS 1.1.1 (via the
+   max_edns_response_size" PE config parameter).
 
 Methodology:
 
   * Created a testbed with a signed root with one 2048-bit KSK, one
-    1024-bit ZSK, and (for now) an unsigned root-servers.net zone.
+    1024-bit ZSK, a signed arpa with the same key sizes, and (for now)
+    an unsigned root-servers.net zone.
 
   * BIND 9.6 was used as the authoritative server (so the
     minimal-dnskey-response behavior was in effect).
@@ -21,7 +31,7 @@ Methodology:
     script would:
 
     1. Read the contents of the signed root zone file, and for every
-    name/type pair (except A/AAAA):
+    name/type pair (except A/AAAA types for root and arpa):
 
        1.1. Query for the name/type with EDNS0, DO=1, BUFSIZE=4096 via
             UDP
@@ -61,62 +71,62 @@ Methodology:
 
 Results:
 
-* "Maximum truncation size" is basically the size of a response without
-  the additional records, but with a 255-byte qname.  Note that
-  NXDOMAIN responses don't have additional section records.
 * "Maximum overall size" is the size of a response *with* the
   additional records and with a 255-byte qname.
 * "Full response size" is the size of the response with the additional
   section (if any), but with the given qname.
 
-Referral sizes (Maximum truncation sizes):
-range [501 - 717] min: NF/NS, max: AN/NS
-[448 - 511] : 7
-[512 - 575] : 98
-[576 - 639] : 128
-[640 - 703] : 45
-[704 - 767] : 3
-
 Referral sizes (Maximum overall sizes):
-range [533 - 1057] min: NF/NS, max: AERO/NS
-[512 - 575] : 16
-[576 - 639] : 59
-[640 - 703] : 55
-[704 - 767] : 60
-[768 - 831] : 26
-[832 - 895] : 42
-[896 - 959] : 14
-[960 - 1023] : 6
-[1024 - 1087] : 3
-
-NXDOMAIN sizes (Maximum truncation sizes):
+range [522 - 1057] min: root-servers.net./NS, max: AERO/NS
+         [512 - 576) : 17
+         [576 - 640) : 63
+         [640 - 704) : 56
+         [704 - 768) : 59
+         [768 - 832) : 27
+         [832 - 896) : 41
+         [896 - 960) : 15
+        [960 - 1024) : 8
+       [1024 - 1088) : 3
+
+NXDOMAIN sizes (Maximum overall sizes):
 range [697 - 914] min: @_/A, max: XN--HGBK6AJ7F53BBA_/A
-[640 - 703] : 1
-[832 - 895] : 270
-[896 - 959] : 10
+         [640 - 704) : 22
+         [832 - 896) : 270
+         [896 - 960) : 10
 
 Other response sizes (Full response sizes):
-range [282 - 1906] min: NF/ANY, max: @/ANY
-[256 - 319] : 32
-[320 - 383] : 112
-[384 - 447] : 106
-[448 - 511] : 122
-[512 - 575] : 60
-[576 - 639] : 82
-[640 - 703] : 28
-[704 - 767] : 15
-[768 - 831] : 4
-[960 - 1023] : 282
-[1536 - 1599] : 1
-[1856 - 1919] : 1
-
-The two responses over 1500 are ./RRSIG and ./ANY:
+range [105 - 1906] min: A.ROOT-SERVERS.NET./NSEC, max: @/ANY
+          [64 - 128) : 14
+         [256 - 320) : 62
+         [320 - 384) : 125
+         [384 - 448) : 122
+         [448 - 512) : 123
+         [512 - 576) : 60
+         [576 - 640) : 80
+         [640 - 704) : 30
+         [704 - 768) : 16
+         [768 - 832) : 4
+         [896 - 960) : 1
+        [960 - 1024) : 295
+       [1024 - 1088) : 13
+       [1536 - 1600) : 3
+       [1856 - 1920) : 3
+
+The six responses over 1500 are variations of apex RRSIG and ANY
+queries:
 
 full    min     qname   label
 ---     ---     -----   -----
+1549   1189    249     ARPA/RRSIG
+1549   1189    249     ARPA./RRSIG
 1561   1157    254     @/RRSIG
+1899   1539    249     ARPA/ANY
+1899   1539    249     ARPA./ANY
 1906   1502    254     @/ANY
 
-The ./RRSIG response will shrink to 1157 bytes before setting TC, but the
-./ANY response will always set TC.
+Note that the duplicate arpa queries exist because of the arpa entry
+in both the root zone and the arpa zone.
+
+The RRSIG responsed will shrink to 1189 or 1157 bytes before setting
+TC, but the ANY responses will always set TC.