idnits 2.17.1 draft-dulaunoy-dnsop-passive-dns-cof-09.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 (February 2022) is 802 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'WEIMERPDNS' is mentioned on line 484, but not defined == Missing Reference: 'REST' is mentioned on line 480, but not defined == Missing Reference: 'DNSDB' is mentioned on line 449, but not defined == Missing Reference: 'DNSDBQ' is mentioned on line 452, but not defined == Missing Reference: 'PDNSCERTAT' is mentioned on line 461, but not defined == Missing Reference: 'PDNSCIRCL' is mentioned on line 467, but not defined == Missing Reference: 'PDNSCOF' is mentioned on line 476, but not defined == Missing Reference: 'PDNSCLIENT' is mentioned on line 471, but not defined == Missing Reference: 'BAILIWICK' is mentioned on line 439, but not defined == Missing Reference: 'CACHEPOISONING' is mentioned on line 444, but not defined == Unused Reference: 'RFC5001' is defined on line 421, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 499, 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: 15 August 2022 6 P. Vixie 7 H. Stern 8 Farsight Security, Inc. 9 February 2022 11 Passive DNS - Common Output Format 12 draft-dulaunoy-dnsop-passive-dns-cof-09 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 5 August 2022. 40 Copyright Notice 42 Copyright (c) 2022 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 (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Common Output Format . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. ABNF grammar . . . . . . . . . . . . . . . . . . . . . . 4 62 3.3. Mandatory Fields . . . . . . . . . . . . . . . . . . . . 5 63 3.3.1. rrname . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.3.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.3.4. time_first . . . . . . . . . . . . . . . . . . . . . 6 67 3.3.5. time_last . . . . . . . . . . . . . . . . . . . . . . 6 68 3.4. Optional Fields . . . . . . . . . . . . . . . . . . . . . 6 69 3.4.1. count . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.4.2. bailiwick . . . . . . . . . . . . . . . . . . . . . . 6 71 3.5. Additional Fields . . . . . . . . . . . . . . . . . . . . 6 72 3.5.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . 6 73 3.5.2. zone_time_first . . . . . . . . . . . . . . . . . . . 7 74 3.5.3. zone_time_last . . . . . . . . . . . . . . . . . . . 7 75 3.5.4. origin . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.5.5. time_first_ms . . . . . . . . . . . . . . . . . . . . 7 77 3.5.6. time_last_ms . . . . . . . . . . . . . . . . . . . . 7 78 3.6. Additional Fields Registry . . . . . . . . . . . . . . . 7 79 3.7. Additional notes . . . . . . . . . . . . . . . . . . . . 8 80 3.8. Suggested MIME Types . . . . . . . . . . . . . . . . . . 8 81 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 83 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 87 8.2. References . . . . . . . . . . . . . . . . . . . . . . . 10 88 8.3. Informative References . . . . . . . . . . . . . . . . . 11 89 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 Passive DNS is a technique described by Florian Weimer in 2005 in 95 Passive DNS replication, F Weimer - 17th Annual FIRST Conference on 96 Computer Security [WEIMERPDNS]. Since then multiple Passive DNS 97 implementations were created and evolved over time. Users of these 98 Passive DNS servers may query a server (often via WHOIS [RFC3912] or 99 HTTP REST [REST]), parse the results and process them in other 100 applications. 102 There are multiple implementations of Passive DNS software. Users of 103 passive DNS query each implementation and aggregate the results for 104 their search. This document describes the output format of four 105 Passive DNS Systems ([DNSDB], [DNSDBQ], [PDNSCERTAT], [PDNSCIRCL] and 106 [PDNSCOF]) which are in use today and which already share a nearly 107 identical output format. As the format and the meaning of output 108 fields from each Passive DNS need to be consistent, we propose in 109 this document a solution to commonly name each field along with their 110 corresponding interpretation. The format follows a simple key-value 111 structure in JSON [RFC4627] format. The benefit of having a 112 consistent Passive DNS output format is that multiple client 113 implementations can query different servers without having to have a 114 separate parser for each individual server. passivedns-client 115 [PDNSCLIENT] currently implements multiple parsers due to a lack of 116 standardization. The document does not describe the protocol (e.g. 117 WHOIS [RFC3912], HTTP REST [REST]) nor the query format used to query 118 the Passive DNS. Neither does this document describe "pre-recursor" 119 Passive DNS Systems. Both of these are separate topics and deserve 120 their own RFC document. The document describes the current best 121 practices implemented in various Passive DNS server implementations. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. Limitation 131 As a Passive DNS servers can include protection mechanisms for their 132 operation, results might be different due to those protection 133 measures. These mechanisms filter out DNS answers if they fail some 134 criteria. The bailiwick algorithm [BAILIWICK] protects the Passive 135 DNS Database from cache poisoning attacks [CACHEPOISONING]. Another 136 limitation that clients querying the database need to be aware of is 137 that each query simply gets a snapshot-answer of the time of 138 querying. Clients MUST NOT rely on consistent answers. Nor must 139 they assume that answers must be identical across multiple Passive 140 DNS Servers. 142 3. Common Output Format 144 3.1. Overview 146 The formatting of the answer follows the JSON [RFC4627] format. In 147 fact, it is a subset of the full JSON language. Notable differences 148 are the modified definition of whitespace ("ws"). The order of the 149 fields is not significant for the same resource type. 151 The intent of this output format is to be easily parsable by scripts. 152 Each JSON object is expressed on a single line to be processed by the 153 client line-by-line. Every implementation MUST support the JSON 154 output format. 156 Examples of JSON (Appendix A) output are in the appendix. 158 3.2. ABNF grammar 160 Formal grammar as defined in ABNF [RFC2234] 162 answer = entries 163 entries = * ( entry CR) 164 entry = "{" keyvallist "}" 165 keyvallist = [ member *( value-separator member ) ] 166 member = qm field qm name-separator value 167 name-separator = ws %x3A ws ; a ":" colon 168 value = value ; as defined in the JSON RFC 169 value-separator = ws %x2C ws ; , comma. As defined in JSON 170 field = "rrname" | "rrtype" | "rdata" | "time_first" | 171 "time_last" | "count" | "bailiwick" | "sensor_id" | 172 "zone_time_first" | "zone_time_last" | "origin" | 173 "time_first_ms" | "time_last_ms" | futureField 174 futureField = string 175 CR = %x0D 176 qm = %x22 ; " a quotation mark 177 ws = *( 178 %x20 | ; Space 179 %x09 ; Horizontal tab 180 ) 182 Note that value is defined in JSON [RFC4627] and has the exact same 183 specification as there. The same goes for the definition of string. 185 3.3. Mandatory Fields 187 Implementation MUST support all the mandatory fields. 189 Uniqueness property: the tuple (rrname,rrtype,rdata) will always be 190 unique within one answer per server. While rrname and rrtype are 191 always individual JSON primitive types (strings, numbers, booleans or 192 null), rdata MAY return multiple resource records or a single record. 193 When multiple resource records are returned, rdata MUST be a JSON 194 array. In the case of a single resource record is returned, rdata 195 MUST be a JSON string or a JSON array containing one JSON string. 196 Senders SHOULD send an array for rdata, but receivers MUST be able to 197 accept a single-string result for rdata. 199 3.3.1. rrname 201 This field returns the name of the queried resource. JSON [RFC4627] 202 string. 204 3.3.2. rrtype 206 This field returns the resource record type as seen by the passive 207 DNS. The key is rrtype and the value is in the interpreted record 208 type represented as a JSON [RFC4627] string. If the value cannot be 209 interpreted, the decimal value is returned following the principle of 210 transparency as described in RFC 3597 [RFC3597]. Then the decimal 211 value is represented as a JSON [RFC4627] number. The resource record 212 type can be any values as described by IANA in the DNS parameters 213 document in the section 'Resource Record (RR) TYPEs' 214 (http://www.iana.org/assignments/dns-parameters). Supported textual 215 descriptions of rrtypes include: A, AAAA, CNAME, etc. A client MUST 216 be able to understand these textual rrtype values represented as a 217 JSON [RFC4627] string. In addition, a client MUST be able to handle 218 a decimal value (as mentioned above) answer represented as a JSON 219 [RFC4627] number. 221 3.3.3. rdata 223 This field returns the resource records of the queried resource. 224 When multiple resource records are returned, rdata MUST be a JSON 225 array containing JSON strings. In the case of a single resource 226 record is returned, rdata MUST be a JSON string or a JSON array 227 containing one JSON string. Each resource record is represented as a 228 JSON [RFC4627] string. Each resource record MUST be escaped as 229 defined in section 2.6 of RFC4627 [RFC4627]. Depending on the 230 rrtype, this can be an IPv4 or IPv6 address, a domain name (as in the 231 case of CNAMEs), an SPF record, etc. A client MUST be able to 232 interpret any value which is legal as the right hand side in a DNS 233 master file RFC 1035 [RFC1035] and RFC 1034 [RFC1034]. If the rdata 234 came from an unknown DNS resource records, the server must follow the 235 transparency principle as described in RFC 3597 [RFC3597]. 237 3.3.4. time_first 239 This field returns the first time that the record / unique tuple 240 (rrname, rrtype, rdata) has been seen by the passive DNS. The date 241 is expressed in seconds (decimal) since 1st of January 1970 (Unix 242 timestamp). The time zone MUST be UTC. This field is represented as 243 a JSON [RFC4627] number. 245 3.3.5. time_last 247 This field returns the last time that the unique tuple (rrname, 248 rrtype, rdata) record has been seen by the passive DNS. The date is 249 expressed in seconds (decimal) since 1st of January 1970 (Unix 250 timestamp). The time zone MUST be UTC. This field is represented as 251 a JSON [RFC4627] number. 253 3.4. Optional Fields 255 Implementations SHOULD support one or more fields. 257 3.4.1. count 259 Specifies how many authoritative DNS answers were received at the 260 Passive DNS Server's collectors with exactly the given set of values 261 as answers (i.e. same data in the answer set - compare with the 262 uniqueness property in "Mandatory Fields"). The number of requests 263 is expressed as a decimal value. This field is represented as a JSON 264 [RFC4627] number. 266 3.4.2. bailiwick 268 The bailiwick is the best estimate of the apex of the zone where this 269 data is authoritative. 271 3.5. Additional Fields 273 Implementations MAY support the following fields: 275 3.5.1. sensor_id 277 This field returns the sensor information where the record was seen. 278 It is represented as a JSON [RFC4627] string. 280 If the data originate from sensors or probes which are part of a 281 publicly-known gathering or measurement system (e.g. RIPE Atlas), a 282 JSON [RFC4627] string SHOULD be prefixed. 284 3.5.2. zone_time_first 286 This field returns the first time that the unique tuple (rrname, 287 rrtype, rdata) record has been seen via master file import. The date 288 is expressed in seconds (decimal) since 1st of January 1970 (Unix 289 timestamp). The time zone MUST be UTC. This field is represented as 290 a JSON [RFC4627] number. 292 3.5.3. zone_time_last 294 This field returns the last time that the unique tuple (rrname, 295 rrtype, rdata) record has been seen via master file import. The date 296 is expressed in seconds (decimal) since 1st of January 1970 (Unix 297 timestamp). The time zone MUST be UTC. This field is represented as 298 a JSON [RFC4627] number. 300 3.5.4. origin 302 Specifies the resource origin of the Passive DNS response. This 303 field is represented as a Uniform Resource Identifier [RFC3986] 304 (URI). 306 3.5.5. time_first_ms 308 Same meaning as the field "time_first", with the only difference, 309 that the resolution is in milliseconds since 1st of January 1970 310 (UTC). 312 3.5.6. time_last_ms 314 Same meaning as the field "time_last", with the only difference, that 315 the resolution is in milliseconds since 1st of January 1970 (UTC). 317 3.6. Additional Fields Registry 319 In accordance with [RFC6648], designers of new passive DNS 320 applications that would need additional fields can request and 321 register new field name at https://github.com/adulau/pdns-qof/wiki/ 322 Additional-Fields. 324 3.7. Additional notes 326 An implementer of a passive DNS Server MAY chose to either return 327 time_first and time_last OR return zone_time_first and 328 zone_time_last. In pseudocode: (time_first AND time_last) OR 329 (zone_time_first AND zone_time_last). In this case, 330 zone_time_{first,last} replace the time_{first,last} fields. 331 However, this is not encouraged since it might be confusing for 332 parsers who will expect the mandatory fields time_{first,last}. See: 333 [github_issue_17] 335 3.8. Suggested MIME Types 337 An implementer of a passive DNS Server SHOULD serve a document in 338 this Common Output Format with a MIME header of "application/ 339 x-ndjson". 341 4. Acknowledgements 343 Thanks to the Passive DNS developers who contributed to the document. 345 5. IANA Considerations 347 This memo includes no request to IANA. 349 6. Privacy Considerations 351 Passive DNS Servers capture DNS answers from multiple collecting 352 points ("sensors") which are located on the Internet-facing side of 353 DNS recursors ("post-recursor passive DNS"). In this process, they 354 intentionally omit the source IP, source port, destination IP and 355 destination port from the captured packets. Since the data is 356 captured "post-recursor", the timing information (who queries what) 357 is lost, since the recursor will cache the results. Furthermore, 358 since multiple sensors feed into a passive DNS server, the resulting 359 data gets mixed together, reducing the likelihood that Passive DNS 360 Servers are able to find out much about the actual person querying 361 the DNS records nor who actually sent the query. In this sense, 362 passive DNS Servers are similar to keeping an archive of all previous 363 phone books - if public DNS records can be compared to phone numbers 364 - as they often are. Nevertheless, the authors strongly encourage 365 Passive DNS implementors to take special care of privacy issues. 366 bortzmeyer-dnsop-dns-privacy is an excellent starting point for this. 367 Finally, the overall recommendations in RFC6973 [RFC6973] should be 368 taken into consideration when designing any application which uses 369 Passive DNS data. 371 In the scope of the General Data Protection Regulation (GDPR - 372 Directive 95/46/EC), operators of Passive DNS Server needs to ensure 373 the legal ground and lawfulness of its operation. 375 7. Security Considerations 377 In some cases, Passive DNS output might contain confidential 378 information and its access might be restricted. When a user is 379 querying multiple Passive DNS and aggregating the data, the 380 sensitivity of the data must be considered. 382 8. References 384 8.1. Normative References 386 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 387 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 388 . 390 [RFC1035] Mockapetris, P., "Domain names - implementation and 391 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 392 November 1987, . 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 400 Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, 401 November 1997, . 403 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 404 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 405 2003, . 407 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 408 DOI 10.17487/RFC3912, September 2004, 409 . 411 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 412 Resource Identifier (URI): Generic Syntax", STD 66, 413 RFC 3986, DOI 10.17487/RFC3986, January 2005, 414 . 416 [RFC4627] Crockford, D., "The application/json Media Type for 417 JavaScript Object Notation (JSON)", RFC 4627, 418 DOI 10.17487/RFC4627, July 2006, 419 . 421 [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", 422 RFC 5001, DOI 10.17487/RFC5001, August 2007, 423 . 425 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 426 "Deprecating the "X-" Prefix and Similar Constructs in 427 Application Protocols", BCP 178, RFC 6648, 428 DOI 10.17487/RFC6648, June 2012, 429 . 431 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 432 Morris, J., Hansen, M., and R. Smith, "Privacy 433 Considerations for Internet Protocols", RFC 6973, 434 DOI 10.17487/RFC6973, July 2013, 435 . 437 8.2. References 439 [BAILIWICK] 440 Edmonds, R., "Passive DNS Hardening", 2010, 441 . 444 [CACHEPOISONING] 445 Kaminsky, D., "Black ops 2008: It's the end of the cache 446 as we know it.", 2008, 447 . 449 [DNSDB] Security, F., "DNSDB API", 2013, 450 . 452 [DNSDBQ] Vixie, P., "DNSDB API Client, C Version", 2018, 453 . 455 [github_issue_17] 456 et.al, P. V. W. A. K., "Discussion on the existing 457 implementations of returning either zone_time{first,last} 458 OR time_{first,last}", 2020, 459 . 461 [PDNSCERTAT] 462 CERT.at, "pDNS presentation at 4th Centr R&D workshop 463 Frankfurt Jun 5th 2012", 2012, 464 . 467 [PDNSCIRCL] 468 Luxembourg, C. -. I. R. C., "CIRCL Passive DNS", 2012, 469 . 471 [PDNSCLIENT] 472 Lee, C., "Queries 5 major Passive DNS databases: BFK, 473 CERTEE, DNSParse, ISC, and VirusTotal.", 2013, 474 . 476 [PDNSCOF] Dulaunoy, D. P. A., "Passive DNS server interface using 477 the common output format", 2019, 478 . 480 [REST] Fielding, R. T., "Representational State Transfer (REST)", 481 2000, . 484 [WEIMERPDNS] 485 Weimer, F., "Passive DNS Replication", 2005, 486 . 489 8.3. Informative References 491 [I-D.narten-iana-considerations-rfc2434bis] 492 Narten, T. and H. Alvestrand, "Guidelines for Writing an 493 IANA Considerations Section in RFCs", Work in Progress, 494 Internet-Draft, draft-narten-iana-considerations- 495 rfc2434bis-09, 26 March 2008, 496 . 499 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 500 Text on Security Considerations", BCP 72, RFC 3552, 501 DOI 10.17487/RFC3552, July 2003, 502 . 504 Appendix A. Examples 506 The JSON output are represented on multiple lines for readability but 507 each JSON object should be on a single line. 509 If you query a passive DNS for the rrname www.ietf.org, the passive 510 dns common output format can be: 512 {"count": 102, "time_first": 1298412391, "rrtype": "AAAA", 513 "rrname": "www.ietf.org", "rdata": "2001:1890:1112:1::20", 514 "time_last": 1302506851} 515 {"count": 59, "time_first": 1384865833, "rrtype": "A", 516 "rrname": "www.ietf.org", "rdata": "4.31.198.44", 517 "time_last": 1389022219} 519 If you query a passive DNS for the rrname ietf.org, the passive dns 520 common output format can be: 522 {"count": 109877, "time_first": 1298398002, "rrtype": "NS", 523 "rrname": "ietf.org", "rdata": "ns1.yyz1.afilias-nst.info", 524 "time_last": 1389095375} 525 {"count": 4, "time_first": 1298495035, "rrtype": "A", 526 "rrname": "ietf.org", "rdata": "64.170.98.32", 527 "time_last": 1298495035} 528 {"count": 9, "time_first": 1317037550, "rrtype": "AAAA", 529 "rrname": "ietf.org", "rdata": "2001:1890:123a::1:1e", 530 "time_last": 1330209752} 532 Please note that the examples imply that a single query returns a 533 single set of JSON objects. For example, two queries were made; one 534 query returned a set of two JSON objects and the other query returned 535 a set of three JSON objects. This specification requires each JSON 536 object individually MUST conform to the common output format, but 537 this specification does not require that a query will return a set of 538 JSON objects. 540 Please note that in the examples above, any backslashes "\" can be 541 ignored and are an artifact of the tools which produced this 542 document. 544 Authors' Addresses 546 Alexandre Dulaunoy 547 CIRCL 548 16, bd d'Avranches 549 L-1160 Luxembourg 550 Luxembourg 552 Phone: (+352) 247 88444 553 Email: alexandre.dulaunoy@circl.lu 554 URI: http://www.circl.lu/ 555 L. Aaron Kaplan 556 A-1170 Vienna 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 United States of America 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 United States of America 576 Phone: +1 650 542-7836 577 Email: henry@stern.ca 578 URI: https://www.farsightsecurity.com/