_____ ___  __  ___ ____  __ ___  
     /\    / ____|__ \/_ |/ _ \___ \/_ |__ \ 
    /  \  | (___    ) || | | | |__) || |  ) |
   / /\ \  \___ \  / / | | | | |__ < | | / / 
  / ____ \ ____) |/ /_ | | |_| |__) || |/ /_ 
 /_/    \_\_____/|____||_|\___/____/ |_|____|
                                             

DaKnObNET - AS210312

+----------------------------------+
| DaKnObNET Public RPKI Validators |
+----------------------------------+

AS210312 operates a number of public RPKI validators that are accessible from
anywhere. They are the ones that are used by the network, and in order to help
operators get started quickly, they are open to all. This is the documentation
page where you can find useful information on how to use them.

For resiliency, multiple RPKI validation software services are running, and
where possible, they are used together. For example, for dropping invalids, you
can reject a prefix if *at least one* validator data claims that it is. Or, in
case you have a peer configured where you only accept RPKI valids, you can
check that the prefix is valid in at least one (and maybe invalid in none).

Due to different implementations in routers, something important to note is
that if you use a DNS hostname to connect to an RPKI validator, you may not
have an effect similar to happy eyeballs happen. That said, if your IPv6
connection to the validator fails, the router will not try over IPv4 if both
AAAA and A records are present. For this reason, all validators listed here
have a `4.' and a `6.' DNS record available as well, to enforce IP address
family.

Due to different implementations in validators, there may be differences
between the service provided. For example, some may not accept IPv6 connections
at all, some may only be able to do TCP, not SSH, etc. The known limitations
appear in each validator and should be taken into account when configuring.

Availability of all the validators is on a best-effort basis, and there is no
SLA provided. However, due to the operation of multiple different services in
multiple locations, and multiple IP prefixes, it is easier to maintain a
connection to at least one, due to the separate failure domains. When there are
updates available, to either the operating system, or the validator, they will
be scheduled to occur with a maximum of one validator down at any time.

In terms of security, the main concern is likely the transport of information
in plaintext. When the TCP protocol is used, there's no encryption (like with
SSH), and the connection could be tampered with. Although the data exchanged is
public, and confidentiality is not needed, there's no authentication and
integrity which means that it could be altered maliciously or accidentally. You
can prefer transport modes that provide these properties where available. If it
is relevant to your risk assessment, AS210312, as of 2022-03-25, has almost 1400
direct peers to which traffic is sent directly without intermediaries. 

All validators include the ARIN TAL and supply information for ARIN-registered
IP addresses.

In case you want to get in touch about this service, for any reason, you can
e-mail rpki-v@daknob.gov, but replace "gov" with "net" first.

+------------------------+
| ZRH2 - Routinator 3000 |
+------------------------+

Host:             r3k.zrh2.v.rpki.daknob.net
IPv4-Only:      4.r3k.zrh2.v.rpki.daknob.net
IPv6-Only:      6.r3k.zrh2.v.rpki.daknob.net
TCP Port:       3323
Software:       Routinator 3000
Location:       Zurich, Switzerland

+------------------------------+
| AMS1 - rpki-client + StayRTR |
+------------------------------+

Host:             rcgr.ams1.v.rpki.daknob.net
IPv4-Only:      4.rcgr.ams1.v.rpki.daknob.net
IPv6-Only:      6.rcgr.ams1.v.rpki.daknob.net
TCP Port:       3323
TLS Port:       443
SSH Port:       2222
SSH Username:   rpki
SSH Password:   rpki
SSH Client Key: All accepted
SSH Host Key:   here
Software:       rpki-client + StayRTR
Location:       Amsterdam, The Netherlands

The TLS Port uses a publicly trusted certificate from the Web PKI. Ensure that
your router has a current trust store installed, or manually add the 5 Root CAs
from Google Trust Services, that you can find here. There is no guarantee of
stability for these Roots, but there's no plan to change them any time soon.

Due to the automatically renewing certificates for TLS, and to ensure that they
are never expired, all services here will restart every Tuesday at 01:37 UTC.
Expect all connections to all services to break. The restart currently takes
about two seconds.