idnits 2.17.1 draft-dulaunoy-dnsop-passive-dns-cof-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 4, 2021) is 1086 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'WEIMERPDNS' is mentioned on line 485, but not defined == Missing Reference: 'REST' is mentioned on line 481, but not defined == Missing Reference: 'DNSDB' is mentioned on line 450, but not defined == Missing Reference: 'DNSDBQ' is mentioned on line 453, but not defined == Missing Reference: 'PDNSCERTAT' is mentioned on line 462, but not defined == Missing Reference: 'PDNSCIRCL' is mentioned on line 468, but not defined == Missing Reference: 'PDNSCOF' is mentioned on line 477, but not defined == Missing Reference: 'PDNSCLIENT' is mentioned on line 472, but not defined == Missing Reference: 'BAILIWICK' is mentioned on line 440, but not defined == Missing Reference: 'CACHEPOISONING' is mentioned on line 445, but not defined == Unused Reference: 'RFC5001' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 498, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations A. Dulaunoy 3 Internet-Draft CIRCL 4 Intended status: Informational A. Kaplan 5 Expires: November 5, 2021 6 P. Vixie 7 H. Stern 8 Farsight Security, Inc. 9 May 4, 2021 11 Passive DNS - Common Output Format 12 draft-dulaunoy-dnsop-passive-dns-cof-08 14 Abstract 16 This document describes a common output format of Passive DNS Servers 17 which clients can query. The output format description includes also 18 in addition a common semantic for each Passive DNS system. By having 19 multiple Passive DNS Systems adhere to the same output format for 20 queries, users of multiple Passive DNS servers will be able to 21 combine result sets easily. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 5, 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Common Output Format . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. ABNF grammar . . . . . . . . . . . . . . . . . . . . . . 4 63 3.3. Mandatory Fields . . . . . . . . . . . . . . . . . . . . 5 64 3.3.1. rrname . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.3.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.3.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3.4. time_first . . . . . . . . . . . . . . . . . . . . . 6 68 3.3.5. time_last . . . . . . . . . . . . . . . . . . . . . . 6 69 3.4. Optional Fields . . . . . . . . . . . . . . . . . . . . . 6 70 3.4.1. count . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.4.2. bailiwick . . . . . . . . . . . . . . . . . . . . . . 6 72 3.5. Additional Fields . . . . . . . . . . . . . . . . . . . . 6 73 3.5.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . 6 74 3.5.2. zone_time_first . . . . . . . . . . . . . . . . . . . 7 75 3.5.3. zone_time_last . . . . . . . . . . . . . . . . . . . 7 76 3.5.4. origin . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.5.5. time_first_ms . . . . . . . . . . . . . . . . . . . . 7 78 3.5.6. time_last_ms . . . . . . . . . . . . . . . . . . . . 7 79 3.6. Additional Fields Registry . . . . . . . . . . . . . . . 7 80 3.7. Additional notes . . . . . . . . . . . . . . . . . . . . 8 81 3.8. Suggested MIME Types . . . . . . . . . . . . . . . . . . 8 82 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 88 8.2. References . . . . . . . . . . . . . . . . . . . . . . . 10 89 8.3. Informative References . . . . . . . . . . . . . . . . . 11 90 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 93 1. Introduction 95 Passive DNS is a technique described by Florian Weimer in 2005 in 96 Passive DNS replication, F Weimer - 17th Annual FIRST Conference on 97 Computer Security [WEIMERPDNS]. Since then multiple Passive DNS 98 implementations were created and evolved over time. Users of these 99 Passive DNS servers may query a server (often via WHOIS [RFC3912] or 100 HTTP REST [REST]), parse the results and process them in other 101 applications. 103 There are multiple implementations of Passive DNS software. Users of 104 passive DNS query each implementation and aggregate the results for 105 their search. This document describes the output format of four 106 Passive DNS Systems ([DNSDB], [DNSDBQ], [PDNSCERTAT], [PDNSCIRCL] and 107 [PDNSCOF]) which are in use today and which already share a nearly 108 identical output format. As the format and the meaning of output 109 fields from each Passive DNS need to be consistent, we propose in 110 this document a solution to commonly name each field along with their 111 corresponding interpretation. The format follows a simple key-value 112 structure in JSON [RFC4627] format. The benefit of having a 113 consistent Passive DNS output format is that multiple client 114 implementations can query different servers without having to have a 115 separate parser for each individual server. passivedns-client 116 [PDNSCLIENT] currently implements multiple parsers due to a lack of 117 standardization. The document does not describe the protocol (e.g. 118 WHOIS [RFC3912], HTTP REST [REST]) nor the query format used to query 119 the Passive DNS. Neither does this document describe "pre-recursor" 120 Passive DNS Systems. Both of these are separate topics and deserve 121 their own RFC document. The document describes the current best 122 practices implemented in various Passive DNS server implementations. 124 1.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 2. Limitation 132 As a Passive DNS servers can include protection mechanisms for their 133 operation, results might be different due to those protection 134 measures. These mechanisms filter out DNS answers if they fail some 135 criteria. The bailiwick algorithm [BAILIWICK] protects the Passive 136 DNS Database from cache poisoning attacks [CACHEPOISONING]. Another 137 limitation that clients querying the database need to be aware of is 138 that each query simply gets a snapshot-answer of the time of 139 querying. Clients MUST NOT rely on consistent answers. Nor must 140 they assume that answers must be identical across multiple Passive 141 DNS Servers. 143 3. Common Output Format 145 3.1. Overview 147 The formatting of the answer follows the JSON [RFC4627] format. In 148 fact, it is a subset of the full JSON language. Notable differences 149 are the modified definition of whitespace ("ws"). The order of the 150 fields is not significant for the same resource type. 152 The intent of this output format is to be easily parsable by scripts. 153 Each JSON object is expressed on a single line to be processed by the 154 client line-by-line. Every implementation MUST support the JSON 155 output format. 157 Examples of JSON (Appendix A) output are in the appendix. 159 3.2. ABNF grammar 161 Formal grammar as defined in ABNF [RFC2234] 163 answer = entries 164 entries = * ( entry CR) 165 entry = "{" keyvallist "}" 166 keyvallist = [ member *( value-separator member ) ] 167 member = qm field qm name-separator value 168 name-separator = ws %x3A ws ; a ":" colon 169 value = value ; as defined in the JSON RFC 170 value-separator = ws %x2C ws ; , comma. As defined in JSON 171 field = "rrname" | "rrtype" | "rdata" | "time_first" | 172 "time_last" | "count" | "bailiwick" | "sensor_id" | 173 "zone_time_first" | "zone_time_last" | "origin" | 174 futureField 175 futureField = string 176 CR = %x0D 177 qm = %x22 ; " a quotation mark 178 ws = *( 179 %x20 | ; Space 180 %x09 ; Horizontal tab 181 ) 183 Note that value is defined in JSON [RFC4627] and has the exact same 184 specification as there. The same goes for the definition of string. 186 3.3. Mandatory Fields 188 Implementation MUST support all the mandatory fields. 190 Uniqueness property: the tuple (rrname,rrtype,rdata) will always be 191 unique within one answer per server. While rrname and rrtype are 192 always individual JSON primitive types (strings, numbers, booleans or 193 null), rdata MAY return multiple resource records or a single record. 194 When multiple resource records are returned, rdata MUST be a JSON 195 array. In the case of a single resource record is returned, rdata 196 MUST be a JSON string or a JSON array containing one JSON string. 197 Senders SHOULD send an array for rdata, but receivers MUST be able to 198 accept a single-string result for rdata. 200 3.3.1. rrname 202 This field returns the name of the queried resource. JSON [RFC4627] 203 string. 205 3.3.2. rrtype 207 This field returns the resource record type as seen by the passive 208 DNS. The key is rrtype and the value is in the interpreted record 209 type represented as a JSON [RFC4627] string. If the value cannot be 210 interpreted, the decimal value is returned following the principle of 211 transparency as described in RFC 3597 [RFC3597]. Then the decimal 212 value is represented as a JSON [RFC4627] number. The resource record 213 type can be any values as described by IANA in the DNS parameters 214 document in the section 'Resource Record (RR) TYPEs' 215 (http://www.iana.org/assignments/dns-parameters). Supported textual 216 descriptions of rrtypes include: A, AAAA, CNAME, etc. A client MUST 217 be able to understand these textual rrtype values represented as a 218 JSON [RFC4627] string. In addition, a client MUST be able to handle 219 a decimal value (as mentioned above) answer represented as a JSON 220 [RFC4627] number. 222 3.3.3. rdata 224 This field returns the resource records of the queried resource. 225 When multiple resource records are returned, rdata MUST be a JSON 226 array containing JSON strings. In the case of a single resource 227 record is returned, rdata MUST be a JSON string or a JSON array 228 containing one JSON string. Each resource record is represented as a 229 JSON [RFC4627] string. Each resource record MUST be escaped as 230 defined in section 2.6 of RFC4627 [RFC4627]. Depending on the 231 rrtype, this can be an IPv4 or IPv6 address, a domain name (as in the 232 case of CNAMEs), an SPF record, etc. A client MUST be able to 233 interpret any value which is legal as the right hand side in a DNS 234 master file RFC 1035 [RFC1035] and RFC 1034 [RFC1034]. If the rdata 235 came from an unknown DNS resource records, the server must follow the 236 transparency principle as described in RFC 3597 [RFC3597]. 238 3.3.4. time_first 240 This field returns the first time that the record / unique tuple 241 (rrname, rrtype, rdata) has been seen by the passive DNS. The date 242 is expressed in seconds (decimal) since 1st of January 1970 (Unix 243 timestamp). The time zone MUST be UTC. This field is represented as 244 a JSON [RFC4627] number. 246 3.3.5. time_last 248 This field returns the last time that the unique tuple (rrname, 249 rrtype, rdata) record has been seen by the passive DNS. The date is 250 expressed in seconds (decimal) since 1st of January 1970 (Unix 251 timestamp). The time zone MUST be UTC. This field is represented as 252 a JSON [RFC4627] number. 254 3.4. Optional Fields 256 Implementations SHOULD support one or more fields. 258 3.4.1. count 260 Specifies how many authoritative DNS answers were received at the 261 Passive DNS Server's collectors with exactly the given set of values 262 as answers (i.e. same data in the answer set - compare with the 263 uniqueness property in "Mandatory Fields"). The number of requests 264 is expressed as a decimal value. This field is represented as a JSON 265 [RFC4627] number. 267 3.4.2. bailiwick 269 The bailiwick is the best estimate of the apex of the zone where this 270 data is authoritative. 272 3.5. Additional Fields 274 Implementations MAY support the following fields: 276 3.5.1. sensor_id 278 This field returns the sensor information where the record was seen. 279 It is represented as a JSON [RFC4627] string. 281 If the data originate from sensors or probes which are part of a 282 publicly-known gathering or measurement system (e.g. RIPE Atlas), a 283 JSON [RFC4627] string SHOULD be prefixed. 285 3.5.2. zone_time_first 287 This field returns the first time that the unique tuple (rrname, 288 rrtype, rdata) record has been seen via master file import. The date 289 is expressed in seconds (decimal) since 1st of January 1970 (Unix 290 timestamp). The time zone MUST be UTC. This field is represented as 291 a JSON [RFC4627] number. 293 3.5.3. zone_time_last 295 This field returns the last time that the unique tuple (rrname, 296 rrtype, rdata) record has been seen via master file import. The date 297 is expressed in seconds (decimal) since 1st of January 1970 (Unix 298 timestamp). The time zone MUST be UTC. This field is represented as 299 a JSON [RFC4627] number. 301 3.5.4. origin 303 Specifies the resource origin of the Passive DNS response. This 304 field is represented as a Uniform Resource Identifier [RFC3986] 305 (URI). 307 3.5.5. time_first_ms 309 Same meaning as the field "time_first", with the only difference, 310 that the resolution is in milliseconds since 1st of January 1970 311 (UTC). 313 3.5.6. time_last_ms 315 Same meaning as the field "time_last", with the only difference, that 316 the resolution is in milliseconds since 1st of January 1970 (UTC). 318 3.6. Additional Fields Registry 320 In accordance with [RFC6648], designers of new passive DNS 321 applications that would need additional fields can request and 322 register new field name at https://github.com/adulau/pdns-qof/wiki/ 323 Additional-Fields. 325 3.7. Additional notes 327 An implementer of a passive DNS Server MAY chose to either return 328 time_first and time_last OR return zone_time_first and 329 zone_time_last. In pseudocode: (time_first AND time_last) OR 330 (zone_time_first AND zone_time_last). In this case, 331 zone_time_{first,last} replace the time_{first,last} fields. 332 However, this is not encouraged since it might be confusing for 333 parsers who will expect the mandatory fields time_{first,last}. See: 334 [github_issue_17] 336 3.8. Suggested MIME Types 338 An implementer of a passive DNS Server SHOULD server a document in 339 this Common Output Format with a MIME header of "application/ 340 x-ndjson". 342 4. Acknowledgements 344 Thanks to the Passive DNS developers who contributed to the document. 346 5. IANA Considerations 348 This memo includes no request to IANA. 350 6. Privacy Considerations 352 Passive DNS Servers capture DNS answers from multiple collecting 353 points ("sensors") which are located on the Internet-facing side of 354 DNS recursors ("post-recursor passive DNS"). In this process, they 355 intentionally omit the source IP, source port, destination IP and 356 destination port from the captured packets. Since the data is 357 captured "post-recursor", the timing information (who queries what) 358 is lost, since the recursor will cache the results. Furthermore, 359 since multiple sensors feed into a passive DNS server, the resulting 360 data gets mixed together, reducing the likelihood that Passive DNS 361 Servers are able to find out much about the actual person querying 362 the DNS records nor who actually sent the query. In this sense, 363 passive DNS Servers are similar to keeping an archive of all previous 364 phone books - if public DNS records can be compared to phone numbers 365 - as they often are. Nevertheless, the authors strongly encourage 366 Passive DNS implementors to take special care of privacy issues. 367 bortzmeyer-dnsop-dns-privacy is an excellent starting point for this. 368 Finally, the overall recommendations in RFC6973 [RFC6973] should be 369 taken into consideration when designing any application which uses 370 Passive DNS data. 372 In the scope of the General Data Protection Regulation (GDPR - 373 Directive 95/46/EC), operators of Passive DNS Server needs to ensure 374 the legal ground and lawfulness of its operation. 376 7. Security Considerations 378 In some cases, Passive DNS output might contain confidential 379 information and its access might be restricted. When a user is 380 querying multiple Passive DNS and aggregating the data, the 381 sensitivity of the data must be considered. 383 8. References 385 8.1. Normative References 387 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 388 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 389 . 391 [RFC1035] Mockapetris, P., "Domain names - implementation and 392 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 393 November 1987, . 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, 397 DOI 10.17487/RFC2119, March 1997, 398 . 400 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 401 Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, 402 November 1997, . 404 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 405 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 406 2003, . 408 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 409 DOI 10.17487/RFC3912, September 2004, 410 . 412 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 413 Resource Identifier (URI): Generic Syntax", STD 66, 414 RFC 3986, DOI 10.17487/RFC3986, January 2005, 415 . 417 [RFC4627] Crockford, D., "The application/json Media Type for 418 JavaScript Object Notation (JSON)", RFC 4627, 419 DOI 10.17487/RFC4627, July 2006, 420 . 422 [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", 423 RFC 5001, DOI 10.17487/RFC5001, August 2007, 424 . 426 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 427 "Deprecating the "X-" Prefix and Similar Constructs in 428 Application Protocols", BCP 178, RFC 6648, 429 DOI 10.17487/RFC6648, June 2012, 430 . 432 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 433 Morris, J., Hansen, M., and R. Smith, "Privacy 434 Considerations for Internet Protocols", RFC 6973, 435 DOI 10.17487/RFC6973, July 2013, 436 . 438 8.2. References 440 [BAILIWICK] 441 Edmonds, R., "Passive DNS Hardening", 2010, 442 . 445 [CACHEPOISONING] 446 Kaminsky, D., "Black ops 2008: It's the end of the cache 447 as we know it.", 2008, 448 . 450 [DNSDB] Security, F., "DNSDB API", 2013, 451 . 453 [DNSDBQ] Vixie, P., "DNSDB API Client, C Version", 2018, 454 . 456 [github_issue_17] 457 et.al, P. V. W. A. K., "Discussion on the existing 458 implementations of returning either zone_time{first,last} 459 OR time_{first,last}", 2020, 460 . 462 [PDNSCERTAT] 463 CERT.at, "pDNS presentation at 4th Centr R&D workshop 464 Frankfurt Jun 5th 2012", 2012, 465 . 468 [PDNSCIRCL] 469 Luxembourg, C. -. I. R. C., "CIRCL Passive DNS", 2012, 470 . 472 [PDNSCLIENT] 473 Lee, C., "Queries 5 major Passive DNS databases: BFK, 474 CERTEE, DNSParse, ISC, and VirusTotal.", 2013, 475 . 477 [PDNSCOF] Dulaunoy, D. P. A., "Passive DNS server interface using 478 the common output format", 2019, 479 . 481 [REST] Fielding, R. T., "Representational State Transfer (REST)", 482 2000, . 485 [WEIMERPDNS] 486 Weimer, F., "Passive DNS Replication", 2005, 487 . 490 8.3. Informative References 492 [I-D.narten-iana-considerations-rfc2434bis] 493 Narten, T. and H. Alvestrand, "Guidelines for Writing an 494 IANA Considerations Section in RFCs", draft-narten-iana- 495 considerations-rfc2434bis-09 (work in progress), March 496 2008. 498 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 499 Text on Security Considerations", BCP 72, RFC 3552, 500 DOI 10.17487/RFC3552, July 2003, 501 . 503 Appendix A. Examples 505 The JSON output are represented on multiple lines for readability but 506 each JSON object should be on a single line. 508 If you query a passive DNS for the rrname www.ietf.org, the passive 509 dns common output format can be: 511 {"count": 102, "time_first": 1298412391, "rrtype": "AAAA", 512 "rrname": "www.ietf.org", "rdata": "2001:1890:1112:1::20", 513 "time_last": 1302506851} 514 {"count": 59, "time_first": 1384865833, "rrtype": "A", 515 "rrname": "www.ietf.org", "rdata": "4.31.198.44", 516 "time_last": 1389022219} 518 If you query a passive DNS for the rrname ietf.org, the passive dns 519 common output format can be: 521 {"count": 109877, "time_first": 1298398002, "rrtype": "NS", 522 "rrname": "ietf.org", "rdata": "ns1.yyz1.afilias-nst.info", 523 "time_last": 1389095375} 524 {"count": 4, "time_first": 1298495035, "rrtype": "A", 525 "rrname": "ietf.org", "rdata": "64.170.98.32", 526 "time_last": 1298495035} 527 {"count": 9, "time_first": 1317037550, "rrtype": "AAAA", 528 "rrname": "ietf.org", "rdata": "2001:1890:123a::1:1e", 529 "time_last": 1330209752} 531 Please note that the examples imply that a single query returns a 532 single set of JSON objects. For example, two queries were made; one 533 query returned a set of two JSON objects and the other query returned 534 a set of three JSON objects. This specification requires each JSON 535 object individually MUST conform to the common output format, but 536 this specification does not require that a query will return a set of 537 JSON objects. 539 Please note that in the examples above, any backslashes "\" can be 540 ignored and are an artifact of the tools which produced this 541 document. 543 Authors' Addresses 545 Alexandre Dulaunoy 546 CIRCL 547 16, bd d'Avranches 548 Luxembourg L-1160 549 Luxembourg 551 Phone: (+352) 247 88444 552 Email: alexandre.dulaunoy@circl.lu 553 URI: http://www.circl.lu/ 554 L. Aaron Kaplan 556 Vienna A-1170 557 Austria 559 Email: aaron@lo-res.org 561 Paul Vixie 562 Farsight Security, Inc. 563 11400 La Honda Road 564 Woodside, California 94062 565 U.S.A. 567 Email: paul@redbarn.org 568 URI: https://www.farsightsecurity.com/ 570 Henry Stern 571 Farsight Security, Inc. 572 11400 La Honda Road 573 Woodside, California 94062 574 U.S.A. 576 Phone: +1 650 542-7836 577 Email: henry@stern.ca 578 URI: https://www.farsightsecurity.com/