Researchers and practitioners often face the issue of having to attribute an IP address to an organization. For current data this is comparably easy, using services like whois or other databases. Similarly, for historic data, several entities like the RIPE NCC provide websites that provide access to historic records. For large-scale network measurement work, though, researchers often have to attribute millions of addresses. For current data, Team Cymru provides a bulk whois service which allows bulk address attribution. However, at the time of writing, there is no service available that allows historic bulk attribution of IP addresses. Hence, in this paper, we introduce and evaluate our ‘Back-to-the-Future whois’ service, allowing historic bulk attribution of IP addresses on a daily granularity based on CAIDA Routeviews aggregates. We provide this service to the community for free, and also share our implementation so researchers can run instances themselves.@en

DNS is one of the core building blocks of the Internet. In this paper, we investigate DNS resolution in a strict IPv6-only scenario and find that a substantial fraction of zones cannot be resolved. We point out, that the presence of an AAAA resource record for a zone’s nameserver does not necessarily imply that it is resolvable in an IPv6-only environment since the full DNS delegation chain must resolve via IPv6 as well. Hence, in an IPv6-only setting zones may experience an effect similar to what is commonly referred to as lame delegation. Our longitudinal study shows that the continuing centralization of the Internet has a large impact on IPv6 readiness, i.e., a small number of large DNS providers has, and still can, influence IPv6 readiness for a large number of zones. A single operator that enabled IPv6 DNS resolution–by adding IPv6 glue records–was responsible for around 20.3% of all zones in our dataset not resolving over IPv6 until January 2017. Even today, 10% of DNS operators are responsible for more than 97.5% of all zones that do not resolve using IPv6.@en

Network protocols define how networked computer systems exchange data. As they define all aspects of this communication, the way they are designed is also security sensitive. If communication is supposed to be encrypted, this has to be outlined in the protocol’s specification. If services implementing the protocol should allow for authentication, this has to be defined in the protocol. Hence, the way a protocol is designed is elemental for the security of systems later implementing it. Security by design starts with the protocol definition. Especially in today’s fast-moving environment, with cloud services and the Internet of Things, engineers constantly have to develop new protocols. In this chapter, we derive guidelines for designing new protocols securely, as well as recommendations on how existing protocols can be adjusted to become more secure. We base these recommendations on our analysis of how – historical – protocols were designed and which underlying design decisions made their corresponding implementations susceptible to security issues.@en