Internet Engineering Task Force T. Pusateri
Internet-Draft T. Wattenberg
Intended status: Standards Track Unaffiliated
Expires: September 5, 2019 March 4, 2019
DNS TIMEOUT Resource Record
draft-pusateri-dnsop-update-timeout-02
Abstract
This specification defines a new DNS TIMEOUT resource record (RR)
that associates a lifetime with one or more zone resource records
with the same owner name, type, and class. It is intended to be used
to transfer resource record lifetime state between a zone's primary
and secondary servers and to store lifetime state during server
software restarts.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Pusateri & Wattenberg Expires September 5, 2019 [Page 1]
Internet-Draft TIMEOUT Resource Record March 2019
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Sources of TIMEOUT Expiry Time . . . . . . . . . . . . . . . 3
4. Resource Record Composition . . . . . . . . . . . . . . . . . 3
4.1. Represented Record Type . . . . . . . . . . . . . . . . . 4
4.2. Represented Record Count . . . . . . . . . . . . . . . . 4
4.3. Method Identifiers . . . . . . . . . . . . . . . . . . . 4
4.3.1. Method Identifier 0: NO METHOD . . . . . . . . . . . 5
4.3.2. Method Identifier 1: RDATA . . . . . . . . . . . . . 5
4.4. Expiry Time . . . . . . . . . . . . . . . . . . . . . . . 5
5. TIMEOUT RDATA Wire Format . . . . . . . . . . . . . . . . . . 5
6. Primary Server Behavior . . . . . . . . . . . . . . . . . . . 7
7. Secondary Server Behavior . . . . . . . . . . . . . . . . . . 7
8. TIMEOUT RDATA Presentation Format . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Example TIMEOUT resource records . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
DNS Update [RFC2136] provides a mechanism to dynamically add/remove
DNS resource records to/from a zone. When a resource record is
dynamically added, it remains in the zone until it is removed
manually or via a subsequent DNS Update. A zone administrator may
want to enforce a default lifetime for dynamic updates (such as the
DHCP lease lifetime) or the DNS Update may contain a lifetime using
an EDNS(0) Update Lease option [I-D.sekar-dns-ul]. However, this
lease lifetime is not communicated to secondary servers and will not
endure through server software restarts. Therefore, this
specification defines a new DNS TIMEOUT resource record that
associates a lifetime with one or more resource records with the same
owner name, type, and class that can be transferred to secondary
servers through normal AXFR [RFC5936], IXFR [RFC1995] transfer
mechanisms.
An UPDATE lifetime could be stored in a proprietary database on an
authoritative primary server but there is an advantage to saving it
as a resource record: redundant master servers and secondary servers
Pusateri & Wattenberg Expires September 5, 2019 [Page 2]
Internet-Draft TIMEOUT Resource Record March 2019
capable of taking over as the primary server for a zone automatically
can benefit from the existing database synchronization of resource
records. In addition, primary and secondary servers from multiple
vendors can synchronize the lifetimes through the open format
provided by a resource record.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. These words may also appear in this
document in lower case as plain English words, absent their normative
meanings.
3. Sources of TIMEOUT Expiry Time
The expire time may come from many different sources. A few are
listed here however, this list is not considered complete.
1. Via DHCP Dynamic Lease Lifetime communicated out of band.
2. Via EDNS(0) Update Lease option [I-D.sekar-dns-ul] communicated
in DNS Update.
3. Via an administrative default server value such as one day (86400
seconds).
4. Resource Record Composition
TIMEOUT resource records provide expiry times for a mixed variety of
resource record types with the same owner name, type, and class.
Since there could exist multiple records of the same record type with
the same owner name and class, the TIMEOUT resource record must be
able to identify each of these records individually with only
different RDATA. As an example, PTR records for service discovery
[RFC6763] provide a level of indirection to SRV and TXT records by
instance name. The instance name is stored in the PTR RDATA and
multiple PTR records with the same owner name but only differing
RDATA often exist.
In order to distinguish each individual record with potentially
different expiry times, the TIMEOUT resource record contains an
exipry time, the record type, a method to identify the actual records
for which the expiry time applies, and a count of the number of
records represented. Multiple TIMEOUT records with the same owner
name and class are created for each expiry time, record type, and
Pusateri & Wattenberg Expires September 5, 2019 [Page 3]
Internet-Draft TIMEOUT Resource Record March 2019
resource record representation. If the expiry time is the same,
multiple records can be combined into a single TIMEOUT record with
the same owner name, class, and record type but this is NOT REQUIRED.
The fields and their values in a TIMEOUT record are defined as:
4.1. Represented Record Type
A 16-bit field containing the resource record type to which the
TIMEOUT record applies. Multiple TIMEOUT records for the same owner
name, class, and represented type can exist.
4.2. Represented Record Count
The Represented Record Count is a 8-bit value that specifies the
number of records of the specified record type with this expiry time.
An RR Count of zero indicates that it is not necessary to represent
any records in the list. This is a shortcut notation meaning all
resource records with the same owner name, class, and record type use
the same Expiry Time. There MUST be only one TIMEOUT record for the
same owner name, class, and record type if the Represented Record
Count is zero. If an additional TIMEOUT record exists with the same
owner name, class, and record type, it MUST be ignored and SHOULD be
removed. When the Represented Record Count is 0, the Method
Identifer is set to NO METHOD (0) on transmission and ignored on
reception.
In the unlikely event that the Represented Record Count exceeds 255
which is the largest number representable in 8 bits, multiple
instances of the same Expiry Time can exist.
4.3. Method Identifiers
The Method Identifier is a 8-bit value that specifies an identifier
for the algorithm used to distinguish between resource records. The
identifiers are declared in a registry maintained by IANA for the
purpose of listing acceptable methods for this purpose. In addition
to the method and the index, the registry MAY contain a fixed output
length in bits of the method to be used or the term "variable" to
denote a variable length output per record. It is conceivable,
though not likely, that the same method could be used with different
fixed output lengths. In this case, each fixed output length would
require a different identifier in the registry. Additions to this
registry will be approved with additional documentation under expert
review. At the time that the registry is created by IANA, a group of
expert reviewers will be established.
Pusateri & Wattenberg Expires September 5, 2019 [Page 4]
Internet-Draft TIMEOUT Resource Record March 2019
Additional methods of representing records such as hashes or other
algorithms may be defined in the future. If such methods are
defined, a primary server could create TIMEOUT record using a new
method that is not understood by a secondary server that could take
over as the primary in the event of an outage or administrative
change. In this case, the new primary would not be able to identify
the records it is supposed to TIMEOUT. This is a misconfiguration
and it is the responsibility of the administrator to ensure that
secondary servers in a position to become primary understand the
TIMEOUT record methods of the primary server.
4.3.1. Method Identifier 0: NO METHOD
The method identifier of 0 is defined as "NO METHOD" and MUST NOT be
used if the represented record count is greater than 0. The value of
0 is to be included in the IANA registry of method identifier values.
4.3.2. Method Identifier 1: RDATA
The method identifier of 1 is defined as "RDATA". It begins with the
RDATA length as a 16-bit value containing the length of the RDATA in
bytes followed by the number of bytes of RDATA as appears in the
record being represented. The record MUST be in canonical DNSSEC
form as described in Section 6 of [RFC4034].
4.4. Expiry Time
The expiry time is a 64-bit number expressed as the number of seconds
since the UNIX epoch (00:00:00 UTC on January 1, 1970). This value
is an absolute time at which the record will expire. Lease times
must be converted to an absolute expiry time when received.
5. TIMEOUT RDATA Wire Format
The TIMEOUT resource record follows the same pattern as other DNS
resource records as defined in Section 3.2.1 of [RFC1035] including
owner name, type, class, TTL, RDATA length, and RDATA.
The RDATA section of the resource record with method identifier RDATA
(1) is illustrated in Figure 1:
Pusateri & Wattenberg Expires September 5, 2019 [Page 5]
Internet-Draft TIMEOUT Resource Record March 2019
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Represented RR Type | Count (n) | Method (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiry Time (64-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Represented RDATA LEN 1 | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. Represented RDATA 1 .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Represented RDATA LEN n | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. Represented RDATA n .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Method (1) RDATA Wire Format
Figure 1 represents an arbitrary number of represented records with
the same owner name, class, and represented type. For each expiry
time, a list of RDATA length and RDATA pairs are attached. The
overall RDATA length of the TIMEOUT record indicates when the last
represented record is contained in the record.
The RDATA section of the resource record with method identifier NO
METHOD (0) is illustrated in Figure 2:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Represented RR Type | Count (0) | Method (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiry Time (64-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Method (0) RDATA Wire Format
Pusateri & Wattenberg Expires September 5, 2019 [Page 6]
Internet-Draft TIMEOUT Resource Record March 2019
Figure 2 represents the TIMEOUT RDATA field of all matching records
of the represented type for the same owner name and class.
6. Primary Server Behavior
A TIMEOUT resource record MUST be removed when the last resource
record it covers has been removed. This may be due to the record
expiring (reaching the expiry time) or due to a subsequent DNS Update
or administrative action.
Upon receiving any DNS UPDATE deleting resource records that might
have been covered by a TIMEOUT RR, a primary server MUST remove all
represented records in all of the TIMEOUT records with the same owner
name, class, and represented type.
As a reminder from Section 3.3.13 of [RFC1035], the MINIMUM field of
the SOA for the zone is used as a lower bound of the TTL for all
records in the zone. Therefore, even if the TIMEOUT record will
expire in less time than the MINIMUM, the TTL is still set to the
MINIMUM for records covered by the TIMEOUT record and the TIMEOUT
record itself when a response is returned by an authoritative server.
The TIMEOUT RR is mostly for the benefit of the authoritative server
to know when to remove the records. The fact that some records might
live longer in the cache of a resolver is no different than other
records that might get removed while still in a remote resolver
cache.
7. Secondary Server Behavior
A secondary server may or may not understand TIMEOUT resource
records. If a secondary server does not understand them, they are
treated like any other resource record that the server may not
understand [RFC3597].
A secondary server MUST NOT expire the records in a zone it maintains
covered by the TIMEOUT resource record and it MUST NOT expire the
TIMEOUT resource record itself when the last record it covers has
expired. The secondary server MUST always wait for the records to be
removed or updated by the primary server.
8. TIMEOUT RDATA Presentation Format
Record Type:
resource record type mnemonics. When the mnemonic is unknown,
the TYPE representation described in Section 5 of [RFC3597]
Represented Record Count:
unsigned decimal integer (0-255)
Pusateri & Wattenberg Expires September 5, 2019 [Page 7]
Internet-Draft TIMEOUT Resource Record March 2019
Method Identifier:
unsigned decimal integer (0-255)
Expiry Time:
The Expiry Time is displayed as a compact numeric-only
representation of ISO 8601. All punctuation is removed. This
form is slightly different than the recommendation in [RFC3339]
but is common for DNS protocols. It is defined in Section 3.2
of [RFC4034] as YYYYMMDDHHmmSS in UTC. This form will always
be exactly 14 digits since no component is optional.
YYYY is the year;
MM is the month number (01-12);
DD is the day of the month (01-31);
HH is the hour, in 24 hour notation (00-23);
mm is the minute (00-59); and
SS is the second (00-59).
RDATA Length:
unsigned decimal integer
RDATA:
record type specific
Pusateri & Wattenberg Expires September 5, 2019 [Page 8]
Internet-Draft TIMEOUT Resource Record March 2019
9. IANA Considerations
This document defines a new DNS Resource Record Type named TIMEOUT to
be exchanged between authoritative primary and secondary DNS servers.
It is assigned out of the DNS Parameters Resource Record (RR) Type
registry. The value for the TIMEOUT resource record type is TBA.
This document establishes a new registry of DNS TIMEOUT Resource
Record Method Identifier values. The registry shall include a
numeric identifier, a method name, a description of the method, and
the length of the output function in bits or the keyword "variable".
The identifier is to be used in the RDATA section of the TIMEOUT
resource record.
+-------+------------+----------------+-------------+---------------+
| ID | Method | Description | Length | Definition |
| | Name | | (bits) | |
+-------+------------+----------------+-------------+---------------+
| 0 | NO METHOD | All records | 0 | Section 4.3.1 |
| | | match | | |
| 1 | RDATA | Actual RDATA | variable | Section 4.3.2 |
| | | of represented | | |
| | | records | | |
+-------+------------+----------------+-------------+---------------+
Table 1: TIMEOUT RR Method Identifier values
10. Security Considerations
There is no secure relationship between a TIMEOUT resource record and
the represented resource records it applies to. TIMEOUT records
should typically only apply to resource records created through the
UPDATE mechanism. Protection for permanent resource records in a
zone is advisable.
Authenticated UPDATE operations MUST be REQUIRED at authoritative
name servers supporting TIMEOUT resource records.
11. Acknowledgments
This idea was motivated through conversations with Mark Andrews.
Thanks to Mark as well as Paul Vixie, Joe Abley, Ted Lemon, Tony
Finch, Robert Story, Paul Wouters, and Dick Franks for their
suggestions, review, and comments.
Pusateri & Wattenberg Expires September 5, 2019 [Page 9]
Internet-Draft TIMEOUT Resource Record March 2019
12. References
12.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <https://www.rfc-editor.org/info/rfc3597>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References
[I-D.sekar-dns-ul]
Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases",
draft-sekar-dns-ul-02 (work in progress), August 2018.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996,
<https://www.rfc-editor.org/info/rfc1995>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
Pusateri & Wattenberg Expires September 5, 2019 [Page 10]
Internet-Draft TIMEOUT Resource Record March 2019
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
Appendix A. Example TIMEOUT resource records
The following example shows sample TIMEOUT resource records based on
DNS UPDATEs containing A and AAAA address records plus the
corresponding PTR records.
A host sending a name registration at time Tn for "A" and "AAAA"
records with lease lifetime Ln would have a series of UPDATEs (one
for each zone) that contain:
+-------------------------------------------+------+----------------+
| Name | RR | Value |
| | Type | |
+-------------------------------------------+------+----------------+
| s.example.com. | A | 192.0.2.5 |
| s.example.com. | AAAA | 12001:db8::5 |
| 5.2.0.192.in-addr.arpa. | PTR | s.example.com. |
| 5.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.a | PTR | s.example.com. |
| rpa. (bytes) | | |
+-------------------------------------------+------+----------------+
Table 2: Example Address Records Update
Next, consider the TIMEOUT resource records that would be generated
for the records in Table 2. Notice that none of the 4 TIMEOUT
records on the server would require a hash:
+------------------------------+------+-------+--------+------------+
| Owner Name | For | Count | Method | Expiration |
| | Type | | | |
+------------------------------+------+-------+--------+------------+
| s.example.com. | A | 0 | 0 | Tn + Ln |
| s.example.com. | AAAA | 0 | 0 | Tn + Ln |
| 5.2.0.192.in-addr.arpa. | PTR | 0 | 0 | Tn + Ln |
| 5.0.0.0.0.0.0.0.0.0.0.0.b8.0 | PTR | 0 | 0 | Tn + Ln |
| d.01.20.ip6.arpa. (bytes) | | | | |
+------------------------------+------+-------+--------+------------+
Table 3: Address TIMEOUT records
Next, assume there are two hosts advertising the same service type
(different service types will have different owner names). We will
use _ipp._tcp.example.com as an example.
Pusateri & Wattenberg Expires September 5, 2019 [Page 11]
Internet-Draft TIMEOUT Resource Record March 2019
Host A sends an UPDATE at time Ta with lease life La for PTR, SRV, A,
AAAA, and TXT records. Host B sends an UPDATE at time Tb with lease
life Lb for PTR, SRV, A, and TXT records.
+--------------------------------+------+---------------------------+
| Owner name | RR | Value |
| | Type | |
+--------------------------------+------+---------------------------+
| _ipp._tcp.example.com. | PTR | p1._ipp._tcp.example.com. |
| p1._ipp._tcp.example.com. | SRV | 0 0 631 p1.example.com. |
| p1._ipp._tcp.example.com. | TXT | paper=A4 |
| p1.example.com. | A | 192.0.2.1 |
| p1.example.com. | AAAA | 2001:db8::1 |
+--------------------------------+------+---------------------------+
Table 4: DNS UPDATE from Host A
+--------------------------------+------+---------------------------+
| Owner name | RR | Value |
| | Type | |
+--------------------------------+------+---------------------------+
| _ipp._tcp.example.com. | PTR | p2._ipp._tcp.example.com. |
| p2._ipp._tcp.example.com. | SRV | 0 0 631 p2.example.com. |
| p2._ipp._tcp.example.com. | TXT | paper=B4 |
| p2.example.com. | A | 192.0.2.2 |
+--------------------------------+------+---------------------------+
Table 5: DNS UPDATE from Host B
For these printer registrations, the TIMEOUT records on the server
would look like the following:
Pusateri & Wattenberg Expires September 5, 2019 [Page 12]
Internet-Draft TIMEOUT Resource Record March 2019
+---------------------------+------+---+-----+----------------------+
| Owner Name | For | C | Met | Expire / |
| | Type | o | hod | RDLEN RDATA |
| | | u | | |
| | | n | | |
| | | t | | |
+---------------------------+------+---+-----+----------------------+
| _ipp.tcp.example.com. | PTR | 1 | 1 | Ta + La 25 p1._ipp._ |
| | | | | tcp.example.com. |
| _ipp.tcp.example.com. | PTR | 1 | 1 | Tb + Lb 25 p2._ipp._ |
| | | | | tcp.example.com. |
| p1._ipp._tcp.example.com. | SRV | 0 | 0 | Ta + La |
| p1._ipp._tcp.example.com. | TXT | 0 | 0 | Ta + La |
| p2._ipp._tcp.example.com. | SRV | 0 | 0 | Tb + Lb |
| p2._ipp._tcp.example.com. | TXT | 0 | 0 | Tb + Lb |
| p1.example.com. | A | 0 | 0 | Ta + La |
| p1.example.com. | AAAA | 0 | 0 | Ta + La |
| p2.example.com. | A | 0 | 0 | Tb + Lb |
+---------------------------+------+---+-----+----------------------+
Table 6: Service TIMEOUT records
Authors' Addresses
Tom Pusateri
Unaffiliated
Raleigh, NC
USA
Email: pusateri@bangj.com
Tim Wattenberg
Unaffiliated
Cologne
Germany
Email: mail@timwattenberg.de
Pusateri & Wattenberg Expires September 5, 2019 [Page 13]