Jan Žorž

Author Archives: Jan Žorž

DNS privacy in new Android 9

I recently enrolled in the Android developer preview programme and got hold of the Android P (9 beta) OTA image for my Nokia 7 Plus phone, and while discovering what’s new, I found a new advanced option under network settings called ‘Private DNS’ that got my attention. This led to me finding an article from Erik Kline describing this new feature in Android 9, which to my surprise supports DNS-over-TLS (RFC 7858).

Last year we wrote about the experiments in the Go6lab with DNS-over-TLS where we set up a recursive DNS resolver listening on port 853 and serving DNS answers to queries encrypted with TLS. This setup was useful if your local DNS resolver was Unbound or Stubby, and since then I’ve been using Stubby as my local DNS client on MacOS with the Unbound DNS server at the Go6lab (privacydns.go6lab.si) as a recursive resolver for encrypted DNS queries without any issues.

So armed with the information from Erik, I decided to test out the Android implementation.

First thing was to turn on the setting and test it with the ‘privacydns.go6lab.si’ server which worked fine. Enabling ‘log-queries’ on the Unbound server quickly revealed that DNS queries are Continue reading

CGN, IPv6 and fighting online crime…

Carrier Grade NAT (CGN) is commonly used by network operators as a way of ekeing out the limited supply of public IPv4 addresses. This is where private IPv4 addresses are allocated to end customers, who in turn also use private IPv4 address ranges on their own Local Area Networks, which means there can be multiple layers of Network Address Translation (NAT) before traffic reaches the publicly addressed Internet.
Whilst CGN offers something of a technical solution to the shortage of public IPv4 addresses, it presents a number of problems for investigating and solving online crime. A CGN environment means that many hundreds of users can be sharing a single public IPv4 address, so that when a crime is committed, tracing the perpetrator is very difficult. Furthermore, sometimes action needs to be taken against a public IPv4 address that’s the origin of particular problems, but this then penalises many hundreds or even thousands of innocent users who may also be sharing that IP address.
Europol, the European Union Agency for Law Enforcement Cooperation, has identified that CGN is an impediment to investigating online crime, and is therefore consulting the Internet community on how network operators can be encouraged to deploy IPv6.

Can IPv4 Networks Be Compromised via IPv6?

The Fox-IT International Blog recently published an article on how IPv4 networks can be compromised via IPv6. The attack vector relies on the default IPv6 configuration in the Windows operating system to spoof DNS replies by acting as a malicious DNS server to redirect traffic to an attacker-specified endpoint. The Windows Proxy Auto Discovery (WPAD) feature can also be exploited in order to relay credentials and authenticate to various services within the network, using a tool called called mitm6 created by Fox-IT.

Fox-IT is recommending that IPv6 is disabled when it is not being used, as disabling Proxy Auto Detection. This of course means that Windows-based hosts are unable to switch preference to IPv6 when it is available (which all versions since Windows Vista will do), and that IPv6 would need to be explicitly re-enabled on hosts.

The article makes some important points, but IPv4 and IPv6 are fundamentally incompatible on a wire level and it needs to be understood they can’t communicate with each other except through translation devices. There are a number of known issues (including this one) with the security of automatic configuration mechanisms running on Local Area Networks, both under IPv6 and IPv4, but these require physical access to Continue reading

Starting a new BCOP – “How to run and protect an email server on IPv6”

After the recent series of technical Best Current Operational Practices (BCOP) documents that we initiated and co-authored, it’s time for new one. This time on how to run an incoming email server on IPv6 and survive!

Back in 2010 we started the IPv6 series of BCOP documents, starting with the popular RIPE-501 that was superseded by the even more popular RIPE-554 that discusses how to specify IPv6 functionality and compliance when ordering ICT equipment. This document emerged from listening to the Internet community that is deploying IPv6, and figuring out the common problems in order to come up with recommendations on how to solve them.

The next most common issue that we heard about, was that helpdesks of network operators would melt down if they deployed IPv6 to their end customers as they don’t know anything about IPv6. So we built an online tool and wrote some helpdesk procedures on how to troubleshoot IPv6 issues when users call them – resulting in another useful document that was published as RIPE-631.

After addressing this, we then repeatedly heard questions about what size of IPv6 prefixes should be given to end-users and should it be assigned statically or dynamically. We therefore put Continue reading

Monitoring your DANE deployment

In a previous series of articles (part 1, part 2) we described how to install and use DANE for verifying your email and web server certificates through the DNS. In this article, I discuss how to monitor whether your TLSA records still match the certificates used for your services.

The aim is help people doing something similar, as this monitoring system saved the DANE deployment in the Go6lab from being broken many times, especially at the very beginning of deployment when the automated systems we built didn’t work completely correctly all the time ?

If we’re using self-signed certificates for our services and we manually change the underlying key, then we’ll probably also change the values of the TLSA records. If we forget to change them or are using, for example, Let’s Encrypt that automatically renews the certificate every 90 days, then we need to have some automatic DANE monitoring system that informs us of misalignment between the certificate being used and the TLSA record.

For this reason there are more and more online tools to check individual services by entering the URL and port, and with a press of a button tell if things are still working fine. A few Continue reading

The First Albanian Network Operators Forum

On Tuesday, 14 November 2017, Albanian Internet Service Providers gathered in central Tirana for the first Albanian Network Operators Forum (ALNOF). The event was organized by RASH, the Albanian Academic Network, and NaMeX, the Internet Exchange Point based in Rome, Italy, with the goal of bringing Albanian ISPs together to discuss their common issues. The Internet Society sponsored the event.

The main topics on the agenda were Interconnection and Networking Community. Albania is one of the only countries in Europe that doesn’t have a neutral Internet Exchange Point: Internet traffic from one Albanian ISP to another sometimes crosses many borders and reaches Amsterdam, London, or Copenhagen before returning to Albania. RASH and NaMeX presented their partnership to create ANIX, the first neutral Internet Exchange Point in Albania, and MIXP presented its experience of the Internet Exchange Point in Montenegro. The session was completed by presentations on PeeringDB, the Facebook network, and IPv6.

As for the Networking Community topic, Albania is a small country where many people running network infrastructure operations know each other, but there is no actual “community” of ISPs. This session included presentations by two organizations that are committed to develop networking communities: Continue reading

Reflections from Copenhagen: RIPE NCC IPv6 Hackathon and Danish IPv6 Day

On 4-5 November, a group of enthusiastic and skillful people gathered at the 6th RIPE NCC hackathon with a theme of IPv6. The event was organized by RIPE NCC and DKNOG, sponsored by Comcast, hosted by IT University of Copenhagen and aimed to bring together open-minded developers and network engineers to work on different ideas and projects from the IPv6 field.

I was honoured to be a jury member and even before the hackathon we were quite busy rating all the submissions that came in, as the number of hackathon participants was limited. All potential participants had to submit a short bio, explain what kind of development (programming) knowledge they had, and also what their ideas or expectations for the hackathon were. We selected 24 participants – and what a skillful bunch that was! In total we were 33 people in the room, 24 participants, 5 jurors and 4 RIPE NCC staff for on-site support.

On Saturday,  4 November, the group came together at IT University of Copenhagen and after a short opening and update on logistics and rules of the hackathon, people got to work. First was a “speaker’s corner”, where everyone with an idea for a Continue reading

RONOG4 meeting in Bucharest, Romania

The 4th edition of Romanian NOG (RONOG) is being held today, 31 October 2017, in Bucharest, Romania, and as the largest meeting of Internet technology professionals in Romania it is expecting to hit over 170 attendees.

As specified in the meeting agenda, I’ll deliver my talk about NAT64 experiments in the go6lab and also one very useful tool that came out of this testing – NAT64Check. I also have the honour of chairing the IPv6/IOT session.

I’m looking forward to being back in Bucharest and if you happen to be at RONOG4, please come and find me in the hallways as I’m always happy to chat about technology, IPv6, DNSSEC, DANE and everything else that makes our Internet a bit of a better place!

The post RONOG4 meeting in Bucharest, Romania appeared first on Internet Society.

DNS over TLS: experience from the Go6lab

After the experiment with DPRIVE at IETF99, we thought we’d try to implement it in the Go6lab and see how this actually works in day-to-day reality.

The first step was to take a look at https://dnsprivacy.org/wiki/ as we had a feeling this might be the best source for information around this topic. There’s a ton of info about DNS over TLS, but what we were really looking for was simple instructions on how to setup a recursive DNS server to serve DNS responses over TLS (port 853), as well as how to setup a local client on our device that could talk to the server and accept local DNS queries over TLS, thereby protecting our DNS communications over the Internet.

We decided that running a  TLS proxy was not the way to do it, so we used CentOS 7 VPS with Unbound installed. After some time and with extensive help from Willem Toorop from NLnet Labs (thanks Willem!!!) we managed to navigate the setup process for server and client.

Firstly, we installed the default Unbound from the CentOS7 default yum repositories, which turned out not to be a very good idea, as this version is 1.4.20 Continue reading