- Test - lists.nanog.org

Weekly Routing Table Report
by cscora＠apnic.net 14 Sep '18

14 Sep '18

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Routing Table Report 04:00 +10GMT Sat 15 Sep, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 715632 Prefixes after maximum aggregation (per Origin AS): 274995 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 343809 Total ASes present in the Internet Routing Table: 61843 Prefixes per ASN: 11.57 Origin-only ASes present in the Internet Routing Table: 53396 Origin ASes announcing only one prefix: 23286 Transit ASes present in the Internet Routing Table: 8447 Transit-only ASes present in the Internet Routing Table: 259 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 36 Max AS path prepend of ASN ( 30873) 34 Prefixes from unregistered ASNs in the Routing Table: 69 Number of instances of unregistered ASNs: 69 Number of 32-bit ASNs allocated by the RIRs: 24086 Number of 32-bit ASNs visible in the Routing Table: 19447 Prefixes from 32-bit ASNs in the Routing Table: 81493 Number of bogon 32-bit ASNs visible in the Routing Table: 25 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 324 Number of addresses announced to Internet: 2853242180 Equivalent to 170 /8s, 17 /16s and 5 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.0 Total number of prefixes smaller than registry allocations: 239222 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 195042 Total APNIC prefixes after maximum aggregation: 55503 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 193100 Unique aggregates announced from the APNIC address blocks: 79556 APNIC Region origin ASes present in the Internet Routing Table: 9093 APNIC Prefixes per ASN: 21.24 APNIC Region origin ASes announcing only one prefix: 2555 APNIC Region transit ASes present in the Internet Routing Table: 1365 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 31 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4053 Number of APNIC addresses announced to Internet: 768098051 Equivalent to 45 /8s, 200 /16s and 63 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 212696 Total ARIN prefixes after maximum aggregation: 100695 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 212454 Unique aggregates announced from the ARIN address blocks: 100997 ARIN Region origin ASes present in the Internet Routing Table: 18246 ARIN Prefixes per ASN: 11.64 ARIN Region origin ASes announcing only one prefix: 6772 ARIN Region transit ASes present in the Internet Routing Table: 1809 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2431 Number of ARIN addresses announced to Internet: 1097187744 Equivalent to 65 /8s, 101 /16s and 193 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 195831 Total RIPE prefixes after maximum aggregation: 93419 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 192076 Unique aggregates announced from the RIPE address blocks: 113790 RIPE Region origin ASes present in the Internet Routing Table: 25466 RIPE Prefixes per ASN: 7.54 RIPE Region origin ASes announcing only one prefix: 11474 RIPE Region transit ASes present in the Internet Routing Table: 3521 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7397 Number of RIPE addresses announced to Internet: 714375296 Equivalent to 42 /8s, 148 /16s and 128 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 92435 Total LACNIC prefixes after maximum aggregation: 21188 LACNIC Deaggregation factor: 4.36 Prefixes being announced from the LACNIC address blocks: 93843 Unique aggregates announced from the LACNIC address blocks: 41083 LACNIC Region origin ASes present in the Internet Routing Table: 7551 LACNIC Prefixes per ASN: 12.43 LACNIC Region origin ASes announcing only one prefix: 2079 LACNIC Region transit ASes present in the Internet Routing Table: 1421 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5095 Number of LACNIC addresses announced to Internet: 172151840 Equivalent to 10 /8s, 66 /16s and 212 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 19558 Total AfriNIC prefixes after maximum aggregation: 4129 AfriNIC Deaggregation factor: 4.74 Prefixes being announced from the AfriNIC address blocks: 23835 Unique aggregates announced from the AfriNIC address blocks: 8111 AfriNIC Region origin ASes present in the Internet Routing Table: 1201 AfriNIC Prefixes per ASN: 19.85 AfriNIC Region origin ASes announcing only one prefix: 406 AfriNIC Region transit ASes present in the Internet Routing Table: 240 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 26 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 471 Number of AfriNIC addresses announced to Internet: 100971520 Equivalent to 6 /8s, 4 /16s and 180 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 4632 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4435 483 475 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2988 1154 90 VIETEL-AS-AP Viettel Group, VN 9829 2811 1495 540 BSNL-NIB National Internet Backbone, IN 4766 2804 11135 772 KIXS-AS-KR Korea Telecom, KR 45899 2746 1658 158 VNPT-AS-VN VNPT Corp, VN 9394 2610 4907 31 CTTNET China TieTong Telecommunications 9808 2264 8699 26 CMNET-GD Guangdong Mobile Communication 17974 2256 962 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2121 417 204 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3467 1324 84 SHAW - Shaw Communications Inc., CA 11492 3404 236 494 CABLEONE - CABLE ONE, INC., US 22773 3237 2971 155 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2285 4938 793 AMAZON-02 - Amazon.com, Inc., US 18566 2165 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2157 2741 512 CHARTER-NET-HKY-NC - Charter Communicat 30036 2043 347 135 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2040 5084 603 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16625 1980 1056 1472 AKAMAI-AS - Akamai Technologies, Inc., 5650 1887 3224 1320 FRONTIER-FRTR - Frontier Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 4853 1616 127 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3062 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2567 618 1912 AKAMAI-ASN1, US 12389 2049 1919 729 ROSTELECOM-AS, RU 34984 2036 336 508 TELLCOM-AS, TR 9121 1866 1691 17 TTNET, TR 13188 1604 100 43 TRIOLAN, UA 8402 1255 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5275 3339 600 Uninet S.A. de C.V., MX 10620 3221 493 777 Telmex Colombia S.A., CO 11830 2654 370 81 Instituto Costarricense de Electricidad 6503 1654 444 66 Axtel, S.A.B. de C.V., MX 7303 1431 954 205 Telecom Argentina S.A., AR 28573 1094 2231 192 CLARO S.A., BR 3816 1016 509 121 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 937 377 31 Telefonica del Peru S.A.A., PE 11172 933 128 70 Alestra, S. de R.L. de C.V., MX 18881 917 1098 28 TELEFÔNICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1195 396 48 LINKdotNET-AS, EG 37611 901 107 9 Afrihost, ZA 36903 778 391 137 MT-MPLS, MA 36992 750 1411 41 ETISALAT-MISR, EG 24835 643 818 18 RAYA-AS, EG 8452 602 1728 14 TE-AS TE-AS, EG 37492 473 470 57 ORANGE-, TN 29571 463 70 11 ORANGE-COTE-IVOIRE, CI 37342 386 32 1 MOVITEL, MZ 23889 376 231 15 MauritiusTelecom, MU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5275 3339 600 Uninet S.A. de C.V., MX 12479 4853 1616 127 UNI2-AS, ES 4538 4632 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4435 483 475 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3467 1324 84 SHAW - Shaw Communications Inc., CA 11492 3404 236 494 CABLEONE - CABLE ONE, INC., US 22773 3237 2971 155 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3221 493 777 Telmex Colombia S.A., CO 8551 3062 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 4853 4726 UNI2-AS, ES 4538 4632 4558 ERX-CERNET-BKB China Education and Research Net 7545 4435 3960 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3467 3383 SHAW - Shaw Communications Inc., CA 22773 3237 3082 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3062 3018 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 3404 2910 CABLEONE - CABLE ONE, INC., US 7552 2988 2898 VIETEL-AS-AP Viettel Group, VN 45899 2746 2588 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 4200003000 PRIVATE 47.89.98.0/24 45102 CNNIC-ALIBABA-CN-NET-AP Alibab 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/24 37500 -Reserved AS-, ZZ 41.76.141.0/24 37500 -Reserved AS-, ZZ 41.76.142.0/24 37500 -Reserved AS-, ZZ 41.76.143.0/24 37500 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:14 /9:11 /10:36 /11:98 /12:289 /13:564 /14:1097 /15:1889 /16:13340 /17:7916 /18:13812 /19:25359 /20:39533 /21:45768 /22:88785 /23:72679 /24:402263 /25:802 /26:612 /27:633 /28:36 /29:21 /30:19 /31:4 /32:52 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3602 4853 UNI2-AS, ES 6327 3255 3467 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2714 3404 CABLEONE - CABLE ONE, INC., US 8551 2524 3062 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2501 3237 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2059 2165 MEGAPATH5-US - MegaPath Corporation, US 11830 2004 2654 Instituto Costarricense de Electricidad y Telec 30036 1791 2043 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1554 1887 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1594 2:844 4:18 5:2817 6:44 7:1 8:1134 12:1868 13:211 14:1813 15:34 16:3 17:196 18:55 20:50 23:2450 24:2357 25:2 27:2481 31:1978 32:88 35:29 36:535 37:2841 38:1533 39:261 40:112 41:3234 42:708 43:1940 44:115 45:5481 46:3116 47:211 49:1347 50:1053 51:318 52:1087 54:367 55:1 56:8 57:38 58:1622 59:992 60:410 61:2114 62:1899 63:1799 64:5050 65:2219 66:4698 67:2652 68:1153 69:3366 70:1157 71:576 72:2218 74:2727 75:417 76:457 77:1635 78:1715 79:2237 80:1572 81:1398 82:1061 83:787 84:1038 85:2015 86:569 87:1419 88:926 89:2343 90:211 91:6433 92:1263 93:2384 94:2449 95:3002 96:933 97:355 98:928 99:138 100:86 101:1189 102:203 103:18653 104:3533 105:218 106:762 107:1797 108:709 109:3323 110:1647 111:1793 112:1342 113:1305 114:1143 115:1674 116:1657 117:1777 118:2206 119:1662 120:1042 121:1046 122:2424 123:1645 124:1420 125:1927 128:1122 129:677 130:492 131:1622 132:728 133:191 134:1030 135:236 136:502 137:654 138:1941 139:680 140:484 141:746 142:842 143:1034 144:819 145:481 146:1249 147:740 148:1670 149:769 150:761 151:1099 152:841 153:324 154:1703 155:804 156:1447 157:804 158:660 159:1849 160:1389 161:830 162:2662 163:607 164:1084 165:1551 166:454 167:1215 168:3211 169:846 170:3988 171:494 172:1003 173:2098 174:992 175:803 176:2077 177:3924 178:2519 179:1259 180:2183 181:2417 182:2579 183:1253 184:1078 185:14086 186:3555 187:2502 188:2898 189:1999 190:8207 191:1386 192:9832 193:6163 194:5032 195:4001 196:2728 197:1606 198:5596 199:5948 200:7332 201:4973 202:10240 203:10288 204:4589 205:2872 206:3224 207:3195 208:3921 209:4085 210:3892 211:1998 212:3022 213:2821 214:1047 215:54 216:6025 217:2128 218:866 219:566 220:1797 221:999 222:988 223:1392 End of report

1 0

QWEST you have broken DNS servers
by Mark Andrews 14 Sep '18

14 Sep '18

I know it takes some time to upgrade DNS servers to ones that are actually protocol compliant but 4+ years is ridiculous. Your servers are the only ones serving the Alexa top 1M sites or the GOV zone that still return BADVERS to EDNS queries with a EDNS option present. This was behaviour made up by your DNS vendor. The correct response to EDNS options that are not understood is to IGNORE them. This allows clients and servers to deploy support for new options independently of each other. Additionally this is breaking DNSSEC validation of the signed zones your clients have you serving. They expect you to be using EDNS compliant name servers for this role which you are not. No, we are not working around this breakage in the resolver. Mark % dig soa frc.gov. @208.44.130.121 +norec ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 59707 ;; flags: qr ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; Query time: 66 msec ;; SERVER: 208.44.130.121#53(208.44.130.121) ;; WHEN: Tue Sep 11 06:08:41 UTC 2018 ;; MSG SIZE rcvd: 23 % dig soa frc.gov. @208.44.130.121 +norec +nocookie ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec +nocookie ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16876 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;frc.gov. IN SOA ;; ANSWER SECTION: frc.gov. 86400 IN SOA sauthns2.qwest.net. dns-admin.qwestip.net. 2180320527 10800 3600 604800 86400 ;; AUTHORITY SECTION: frc.gov. 86400 IN NS sauthns1.qwest.net. frc.gov. 86400 IN NS sauthns2.qwest.net. ;; Query time: 66 msec ;; SERVER: 208.44.130.121#53(208.44.130.121) ;; WHEN: Tue Sep 11 06:19:33 UTC 2018 ;; MSG SIZE rcvd: 145 % grep ednsopt=badvers reports/alexa1m.2018-08-26T00:00:06Z | grep edns=ok | awk '{print $3}' | sort -u (sauthns1.qwest.net.) (sauthns2.qwest.net.) % grep ednsopt=badvers reports-full/gov-full.2018-09-11T00:00:06Z | grep edns=ok | awk '{print $3}' | sort -u (sauthns1.qwest.net.) (sauthns2.qwest.net.) % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

2 3

Database that netflix/hulu use to determine who is a proxy and who isnt?
by Drew Weaver 14 Sep '18

14 Sep '18

It seems like recently one of the sources for IP info that Netflix and Hulu uses was updated with erroneous information as access to both of the services was revoked pretty much at the same time. Does anyone know what source they use for that information so I can request that they fix some of their information? Thanks, -Drew

2 1

Re: Puerto Rico Internet Exchange
by Mel Beckman 14 Sep '18

14 Sep '18

Mike, But why would you want, as a content provider, to have your content hosted on the island? Backhauling it over fiber is no big deal across the short distances involved. As far as I can tell, PR has a glut of ocean floor fiber capacity, just installed a couple years ago. We're not talking stock market trades here, where milliseconds matter. We're talking Netflix movie reruns, which could be easily delivered with seconds of latency. Those who hold to the "if you build it they will come" business model forget that that model was a fantasy in a movie. A movie currently being streamed to PR without difficulty :-) -mel via cell On Sep 14, 2018, at 6:14 AM, Mike Hammett <nanog(a)ics-il.net<mailto:nanog@ics-il.net>> wrote: Agreed. Very chicken or the egg. Any recently formed IX is largely a conduit for big content to connect to local eyeballs. As some critical mass of eyeballs is achieved, local content is interested as are large networks like Hurricane Electric. In the case of PR, if there are no local content providers, an IX provides an avenue for one to form to connect to other operators on the island, avoiding underwater cables to the mainland. If I were a company in PR, I'd want my web site and other services hosted in PR, not Miami or Virginia. ----- Mike Hammett Intelligent Computing Solutions<http://www.ics-il.com/> [http://www.ics-il.com/images/fbicon.png]<https://www.facebook.com/ICSIL>[http://www.ics-il.com/images/googleicon.png]<https://plus.google.com/+IntelligentComputingSolutionsDeKalb>[http://www.ics-il.com/images/linkedinicon.png]<https://www.linkedin.com/company/intelligent-computing-solutions>[http://www.ics-il.com/images/twittericon.png]<https://twitter.com/ICSIL> Midwest Internet Exchange<http://www.midwest-ix.com/> [http://www.ics-il.com/images/fbicon.png]<https://www.facebook.com/mdwestix>[http://www.ics-il.com/images/linkedinicon.png]<https://www.linkedin.com/company/midwest-internet-exchange>[http://www.ics-il.com/images/twittericon.png]<https://twitter.com/mdwestix> The Brothers WISP<http://www.thebrotherswisp.com/> [http://www.ics-il.com/images/fbicon.png]<https://www.facebook.com/thebrotherswisp>[http://www.ics-il.com/images/youtubeicon.png]<https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> ________________________________ From: "Sander Steffann" <sander(a)steffann.nl<mailto:sander@steffann.nl>> To: "Mel Beckman" <mel(a)beckman.org<mailto:mel@beckman.org>> Cc: "nanog" <nanog(a)nanog.org<mailto:nanog@nanog.org>> Sent: Friday, September 14, 2018 8:08:58 AM Subject: Re: Puerto Rico Internet Exchange Hi, > In general an IX only makes sense when there are local resources to exchange. It doesn’t seem like PR has a lot of, if any, content providers of its own, so most consumer content is coming from offshore anyway. This can also work the other way: once there is a local IXP, it can open opportunities for local content providers. Cheers, Sander

2 1

SAFNOG-4/EANOG/tzNOG - Just Under 2 Weeks To Go!
by Mark Tinka 13 Sep '18

13 Sep '18

Hi all. This is just a reminder that with a little under 2 weeks to go the upcoming SAFNOG-4/EANOG/tzNOG meeting to be held in Dar Es Salaam, 24th - 29th September, please remember to register your attendance at http://www.safnog.org/ so you don't miss the meeting. The agenda is now up on the web site at http://www.safnog.org/#agenda with just a few slots left which are filling fast. In case you feel like you have an interesting technical and operational talk that you'd like to share with the community at this meeting, please feel free to submit it for the program committee to review as soon as possible, at: https://papers.safnog.org/user/login.php?event=76 Key talks that you would be looking forward include: * Ben Roberts (Liquid Telecom), talking about the latency realities of intra-African Internet communication. * The 3 major data centre projects that are happening in South Africa, Kenya and Uganda. * The DNSSEC key rollover due on 11th October, and what to look forward to, as explained by Amreesh Phokeer. * An IPv6 Deployathon 2-day workshop headed by Mukom Akong Tamon. * ... and so many more. There will be 2 social events where delegates can network, share a drink, some good food, and stand a chance to win either an iPhone X or AppleTV 4K. We have secured a special discount rate at the hotel venue for all SAFNOG/EANOG/tzNOG participants. More details are available at http://www.safnog.org/#venue . We look forward to seeing you in Dar Es Salaam. Mark Tinka On Behalf of the SAFNOG-4/EANOG/tzNOG Organising Committee

1 0

OpenDNS CGNAT Issues
by Darin Steffl 12 Sep '18

12 Sep '18

Hello, I have a ticket open with OpenDNS about filtering happening on some of our CGNAT IP space where a customer has "claimed" the IP as theirs so other customers using that same IP and OpenDNS are being filtered and not able to access sites that fall under their chosen filter. I have a ticket open from 6 days ago but it's not going anywhere fast. Can someone from OpenDNS contact me or point me to a contact there to help get this resolved? I believe we need to claim our CGNAT IP space so residential users can't claim IP's of their own. Thank you! -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>

14 21

Bell Canada IP transit - NID required?
by JASON BOTHE 11 Sep '18

11 Sep '18

All, Just curious if anyone uses Bell Canada for IP transit in a colo environment and whether or not you were able to obtain a traditional cross-connect without having Bell place a managed CPE device in your cage. I can’t seem to find anyone intelligent enough to tell my any different other than “it’s never been done before” and “we need remote testing capabilities.” J~

6 5

Microsoft your DNS servers are broken
by Mark Andrews 11 Sep '18

11 Sep '18

While we are talking about DNS server that are broken, Microsoft your servers are as well. As none of the zones you serve are DNSSEC signed there isn’t as much breakage possible but there are still interoperability problems and unnecessary additional traffic. It’s not like the EDNS specification is complicated. The microsoftonline servers will cause DNSSEC validation to fail if they ever serve a DNSSEC signed zone in this state. The FORMERR will cause EDNS servers to fallback to plain DNS and the validators won’t get the records they need. The azure servers cause problems for anyone deploying a new EDNS options as they have to cope with your servers incorrectly echoing back the option. Additionally if EDNS(1) is ever deployed there is a good chance that resolvers will assume the broken answers indicate that there is no data at the name. Mark cityofharrison-mi.gov. @207.46.15.59 (ns1.bdm.microsoftonline.com.) dns=ok edns=ok edns1=ok edns@512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @2a01:111:f406:1804::59 (ns1.bdm.microsoftonline.com.) dns=ok edns=ok edns1=ok edns@512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @191.232.83.138 (ns3.bdm.microsoftonline.com.) dns=ok edns=ok edns1=ok edns@512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @2a01:111:f406:b400::22 (ns3.bdm.microsoftonline.com.) dns=ok edns=ok edns1=ok edns@512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @157.56.81.41 (ns2.bdm.microsoftonline.com.) dns=ok edns=ok edns1=ok edns@512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @2a01:111:f406:3403::41 (ns2.bdm.microsoftonline.com.) dns=ok edns=ok edns1=ok edns@512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @13.107.24.7 (ns3-07.azure-dns.org.) dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @2a01:111:4000::7 (ns3-07.azure-dns.org.) dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @13.107.160.7 (ns4-07.azure-dns.info.): dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @2620:1ec:bda::7 (ns4-07.azure-dns.info.): dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @64.4.48.7 (ns2-07.azure-dns.net.) dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @2620:1ec:8ec::7 (ns2-07.azure-dns.net.) dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @40.90.4.7 (ns1-07.azure-dns.com.) dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @2603:1061::7 (ns1-07.azure-dns.com.) dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

2 1

Proofpoint Contact?
by Benoit Garcia 10 Sep '18

10 Sep '18

Hello, Could a Proofpoint e-mail blacklist contact me off list? I'm looking for some help to solve an undelivered email issue. Thanks in advance. -- Regards, Benoit.

2 1

Service provider story about tracking down TCP RSTs
by frnkblk＠iname.com 10 Sep '18

10 Sep '18

I want to share a little bit of our journey in tracking down the TCP RSTs that impacted some of our customers for almost ten weeks. Almost immediately after we turned up two new Arista border routers in late July we started receiving a trickle of complaints from customers regarding their inability to access certain websites (mostly B2B). All the packet captures showed the standard TCP SYN/SYN-ACK pair, then a TCP RST from the website after the client sent a TLS/SSL Client Hello. As the reports continued to come in, we built a Google Doc to keep track and it became clear that most of the sites were hosted by Incapsula/Imperva, but there were also a few by Sucuri and Fastly. Knowing that Incapsula provides DoS protection, we attempted to work with them (providing websites, source/destination IPs, traceroutes, and packet captures) to find out why their hosts were issuing our customers a TCP RST, but we made little progress. We moved some of the affected customers to different IP addresses but that didn't resolve the issue. We also asked our customer to work with the website to see if they would be willing to open a ticket with Incapsula. In the meantime, customers were getting frustrated! They couldn't visit Incapsula-hosted healthcare websites, financial firms, product dealers, etc. Over the weeks, a few of those customers purchased/borrowed different routers and some of those didn't have website issues anymore. And more than a few of them discovered that the websites worked fine from home or their mobile phone/hotspot, but not from their Internet connection with us. You can guess where they were applying pressure! That said, we didn't know why a small handful of companies, known for DoS protection, were issuing TCP RSTs to just some of our customers. Earlier this week we received four or five more websites from yet another affected customer, but most of those were with Fastly. By this time, we had been able to replicate the issue in our lab. Feeling desperate to make some tangible progress on this issue, I reached out to the Fastly NOC. In less than 12 hours they provided some helpful feedback, pointing out that a single traceroute to a Fastly site was hitting two of their POPs (they use anycast) and because they don't sync state between POPs the second POP would naturally issue a TCP RST (sidebar: fascinating blog article on Fastly's infrastructure here: https://www.fastly.com/blog/building-and-scaling-fastly-network-part-2-balan cing-requests). In subsequent email exchanges, the Fastly NOC suggested that it appeared that we were "spraying flows" (that is, packets related to single client session were egressing our network via different paths). Because Fastly is also present with us at an IX (though they weren't advertising their anycast IPs at the time), they suggested that we look at how our traffic egresses our network (IX versus transit) and our routers' outbound load-balancing/hashing schemes. The IX turned up to be a red herring, so I turned my attention to our transit. Each of our border routers has two BGP sessions over two circuits to transit provider POP A and two BGP sessions over two circuits to transit provider POP B, for a total of four BGP sessions per border router, a total of eight BGP sessions altogether. Starting with our core router, I confirmed that its ECMP hashing was consistent such that Fastly-bound traffic always went to border router 1 or border router 2. Then I looked at the ECMP hashing scheme on our border routers and noticed something unique - by default Arista also uses TTL: IPv4 hash fields: Source IPv4 Address is ON Protocol is ON Time-To-Live is ON Destination IPv4 Address is ON Since the source and destination IPs and protocol weren't changing, perhaps the TTL was not consistent? I opened the first packet trace in Wireshark and jackpot - the TTL value was 128 on the SYN but 127 on the TLS/SSL Client Hello. I adjusted the Arista's load-balancing profile not to use TTL and immediately my MTR in the background changed and all the sites on the lab machine that couldn't load before . were now loading. Fastly also pointed me to another article written by Joel Jaeggli (https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/) that discusses IPv6 flow labels - we removed that from the border routers' IPv6 hash fields, too. I reviewed the packet traces today and noticed that TTL values remained consistent at 128 *behind* the router CPE. In packet captures on the WAN interface of the router CPE I see that the SYN remains at 128, but the TLS/Client Hello is properly decremented to 127. So, it appears that some router CPE (and there were a variety of makes and models) are doing something special to certain packets and not decrementing the TTL. This explains why: * our customers had issues with all their devices behind their router CPE * the issue remained regardless of what public IP address their router CPE obtained via DHCP or was assigned * some customers who changed their router CPE didn't have the issue anymore - they got lucky with a router that doesn't adjust/reset the TTL * why customers who used our managed Wi-Fi router did not see the issue, because that model doesn't apparently manipulate the TTL, at least not in an inconsistent way. Lesson learned: review a device's hashing mechanism before going into production. For those interested, I have links to the packet traces below my signature, showing the inconsistent TTL values. Thanks again to the fantastic group of folk at the Fastly NOC who so ably pointed us in the right direction! Frank https://www.premieronline.net/~fbulk/example1.pcapng https://www.premieronline.net/~fbulk/example2.pcapng https://www.premieronline.net/~fbulk/example3.pcapng

11 16