The Men & Mice Blog

The ABCs of DNS: a select glossary from the Men & Mice training archives - Part 4

Posted by Men & Mice on 8/16/19 8:43 AM

Continuing our glossary of DNS tips & tricks, we’re covering the letters J, K, and L this time.

J is for “jumbogram”

Ever wondered what the largest (internet-layer) packet you can send? It’s 4,294,967,295 bytes. (One byte less than 4 GB.) Theoretically. Let’s break down the math (and the tech).

IPv6, among other things, has an extension that allows for a 32-bit length field. Jumbogram is the term for IPv6 packets taking advantage of it, capable of carrying more than the 65,535 octets of the limit of IPv4’s 16-bit length field.

However, transport layers such as TCP and UDP are limited to 16 bits. (TCP doesn’t have a length field, but the TCP MSS option and TCP Urgent field are both limited to 16 bits.) To make transporting larger payloads possible, these transport layers need a redesign to include 32-bit length fields.

RFC 1883, which first described the IPv6 standard, contained these modifications but was superseded by RFC 2460 which no longer did. RFC 2147 described the TCP and UDP enhancements but was obsoleted by RFC 2675 which merged the relevant parts from 1883 and 2147 into one document.

This is all theoretical, of course. RFC 2675 is listed as ‘informational’ and the practicality of jumbograms are debatable. But, as networking becomes more and more ubiquitous with larger and larger data transport needs, it may very well become everyday practice soon enough. Especially because larger payloads mean speedier delivery and less overhead - on the other hand, networks need better reliability to handle them. If just a small bit gets lost, scrambled, or corrupted, the whole payload has to be re-sent.

K is for “Kea”

In addition to DNS, an essential component of any network is DHCP. Just like DNS, development in DHCP doesn’t stop, to the extent of completely new software emerging to replace the old one: as is in the case of the Kea DHCP server.

Kea is the successor to ISC DHCP. While mature and robust, ISC DHCP is also old. It started in 1995, a time when networks were a lot smaller. Since then, network management became a lot more complex and mission-critical.

Kea is a modern DHCP server developed for the challenges of modern times. It's more scalable and offer better performance, with a different architecture. Kea also brings a somewhat different feature set, such as hooks and a rich API to configure users and subnets, Radius integration, and support for several database backends.

As is the case with any software no longer in widespread deployment, the development of ISC DHCP will cease in favor of Kea. ISC already recommends, particularly for new deployments, to use Kea instead of ISC DHCP.

To learn more about Kea and how to migrate from ISC DHCP take a look at its website.

L is for “labels”

As we discussed earlier, domain names are made up of three or more parts. These are called labels. 

A typical fully qualified domain name (FQDN) will look like this:

  • root (the trailing dot at the end)
  • top-level domain or “TLD” (such as .com, .net, etc.)
  • domain (such as menandmice)
  • host (such as www, info, etc.)

Labels can contain 1 to 63 octets. (An octet is a unit consisting of 8 bits. While technically the same as a byte, the latter is usually used to describe storage unit sizes.) Put it simpler, labels can be between 1 and 63 characters. The null label (length zero) is reserved for the root zone and is represented by the label terminating in the trailing dot.

Labels were initially restricted to ASCII, but in 2003 ICANN approved the IDNA (internationalized domain name) system. The IDNA maps Unicode characters to valid DNS characters via Punycode. For example, Þórsmörk.is (lovely place, you should visit!) would become xn--rsmrk-ztay3d.is 

Because domain names can have a maximum of 253 characters, the theoretical limit of a domain is 127 levels. (127 1-character labels + 126 dots separating them.)

Want to learn more?

This series is byte-sized (or, well, octet-sized) — but a lot more can be said and done. To learn more in-depth about DNS specifically, we offer a comprehensive DNS training program. 

You can enroll in different groups depending on your skill level:

  • If you’re new to DNS, we offer the DNS & BIND Fundamentals (DNSB-F) course. It’s part of the DNS & BIND Week (DNSB-W) and serves as a shorter introduction to the world of DNS and BIND.
  • If you’re already familiar with the basics, the full five-day DNS & BIND Week (DNSB-W) course takes you deeper into DNS, including a heavy emphasis on security, stopping just short of DNSSEC (for which we offer a separate course).
  • And if you're looking for even more, we offer the DNS & BIND Advanced (DNSB-A) program, getting into the deep end of things.

Check out our training calendar for 2019, and reach out to us with any questions.



Topics: IPv6, DNS training, Kea, domain name

World IPv6 Day 2019 (plus a podcast!)

Posted by Men & Mice on 6/6/19 9:50 AM

June 6th, 2012 (or “6/6”) saw the World IPv6 Launch Day. Today we celebrate the 7th anniversary.

For those in need of a quick cheat sheet, here’s ours.

(Mind you, this is not ONLY a cheat sheet, but also doubles up as a lens cleaning cloth. Come by our booth at  Cisco Live in San Diego to pick one up.)

Beyond that quick reference, what’s all the fuss about this old-new networking technology? What has changed since it’s been around (from the 1990s)? What hasn’t? And where do (or should) we go from where we are now?

To IPv6 or not to IPv6?

That is the question. For what it’s worth we, and literally everybody we spoke to at RIPE 78, are for IPv6.

That said, there is legitimate criticism against it. More often than not, however, it tends to be rooted in shortcomings of implementation, misunderstandings in adoption strategies, or just general reluctance toward the work involved in the switch.

Large tech companies have adopted IPv6 whole-heartedly. ISPs, cloud providers, and data centers have been offering IPv6 for a while. Microsoft has been at work getting rid of IPv4 addresses in their offices for years. Google even keeps a public chart of IPv6 adoption amongst its users:

Screenshot 2019-06-06 at 10.28.10

Bottom line is: adoption is on the up, but it’s still spotty at best. And it is true: IPv6 isn’t perfect. But then again IPv4 isn’t, either. It will not get any better, though, if we don’t dedicate effort to perfecting it through practice.

Fun fact: IPv6 addresses are free. IPv4 addresses go for $20+ a piece and that price keeps rising.

It’s evident that, various inventions and initiatives notwithstanding, we’ll likely soon be out of IPv4 addresses. Never before have there been so many connected devices, from smartphones to cars, from smart thermostats to smart toasters. IPv6 is an inevitability.

What can we do?

Introducing ‘resolv.pod’: a DNS podcast

We can, and most definitely should, discuss and evaluate our options regarding anything and everything affecting the future of the networks we depend on. Attend conferences, read papers, draft strategies.

To that end, we’re happy to announce that we are launching a podcast aimed at sharing with you the mindshare we have access to.

resolv.podOf course, as is clear from the name of our podcast, the focus won’t be on IPv6 exclusively, but rather anything and everything related to DNS, DHCP, and IPAM. Facilitating discussions about IPv6, amongst other things, and giving listeners fuller context from experts in the field, are the DNAME of the game (OK, name - just couldn’t resist).

As luck would have it, we were fortunate enough to grab a conversation with Geoff Huston, Chief Scientist at APNIC (Asia Pacific Network Information Centre)  in the lovely Reykjavik sunshine at RIPE78.

So to celebrate World IPv6 Day, why don’t you sit back and listen to our very first episode featuring Geoff talking networking highs and lows with Men & Mice’s Carsten Strotmann? It’s sure to entertain - and inform - in equal measure. Happy  World IPv6 Day!

Find resolv.pod on your favorite podcast platform:

More interviews and discussions coming up in the next weeks! Let us know what you’d like to learn more about via the podcast email, our social media channels, or as a comment below.




Topics: IPv6, DNS, podcast, resolv.pod, IPv6 Day

The RIPE-javik logs: Day 4 - Part 1

Posted by Carsten Strotmann on 5/24/19 12:03 PM

ripe day 4carsten@menandmice:~$ cat ~/ripe/ripejavik-day4.txt | blog-publish

Day 4 of RIPE78 was so jam-packed, we had to split it in two. Here’s Part 1!

IPv6 Working Group

Day 4 of RIPE78 started with the IPv6 working group. Geoff Huston discussed his measurement engine that focuses on using "ads" delivered to browsers in order to look into the reliability of IPv6 connections. While the IPv6 failure rate has gone down since early 2017 with 4%, it is now at 1.4%. Somewhat better, but still pretty bad.

Geoff found out that mobile networks deploying 464XLAT usually have more stable and reliable IPv6, than others using NAT64/DNS64 or other stateful IPv4-to-IPv6 translation mechanisms. IPv6 reliability appears to be exceptionally bad in Vietnam with a 6-10% failure rate.

Because of the Happy Eyeballs implementations in browsers, end users possibly don't notice the breakage except for a slight delay in establishing the connection. This is both good and bad: while the users are shielded from experiencing the issues in their ISP’s networks, the provider is also not incentivized to fix the issues. (As “it works”). Other countries with non-optimal IPv6 networks are Panama, Venezuela, Morocco, Bangladesh, and Turkey. Even China, with its experience in IPv6 networking, has a higher than average failure rate.

Another artifact Geoff found during his research is the fact that some networks route their IPv6 traffic differently (and often worse) than the IPv4 traffic. At some point between November 2016 and December 2016, all IPv6 traffic from and to India was routed via networks in Great Britain.

In the next talk, Enno Rey and Christopher Werny from ENRW shared their experience with IPv6 on WiFi hotspots. They are working on a project to provide IPv6 on up to 3,000 wifi hotspots in supermarkets and shopping malls all across Europe. After their evaluation of IPv6 support in common applications used by customers of these hotspots, they decided to deploy IPv6-only with NAT64/DNS64. (WLAN 100% IPv6, IPv6 to IPv4 translation at the gateway to the Internet.)

MulticastDNS and other multicast IPv6 communication are a problem for wireless networks, as the access point needs to distribute the multicast message to all clients in range, and needs to use the oldest WiFi protocol to be able to reach legacy clients. Using the older wifi protocols blocks the air for other traffic for a longer time. Enno and Christopher recommend tuning and throttling multicast traffic in IPv6 enabled WiFi networks to minimize this effect. The IETF is aware of the issues and is working on adjustments to the IPv6 protocol family to make IPv6 more WiFi-friendly.

IoT

Over in the IoT working-group, Jan Zorz reported on his attempt to build a "smart home" and gave insight into his design choices. Being an engineer, and also because of privacy concerns, he does not want to use "off the shelf" smart home devices that send sensitive data into the cloud and whose functionality is dictated by the vendor.

So Jan started to build his own smart devices. As the central management hub, he first started his experiments with a Raspberry Pi, but will switch to a more powerful 64bit x86 desktop mini-PC for production. Jan reported that he did not initially really know what he wanted and would expect from a "smart home" system: that insight developed over time while experimenting with different smart devices.

He encourages everyone to do some experimentation before deciding on a particular smart home technology. If you want to hear about the differences between Z-Wave vs. Zigbee, or which home automation software might be the best, have a look at the video recording of his talk.

Next up on the stage was Jelte Janssen from SIDN Labs talking about the SPIN ("Security and Privacy for In-home Networks”) project. The project is developing software tools that help end users to get insight into the network communication of IoT devices in the home and enable the user to better protect the home network. One tool from the SPIN project is the traffic monitor that shows DNS queries and data traffic in the local network, showing graphically to whom the IoT devices talk.

The goal is to get the SPIN tools in the default install of CPE (customer premise equipment, such as home routers) devices. In the same talk, Peter Steinhäuser from Swiss CPE Firmware developer Embedd reported on his company’s work on integrating SPIN in OpenWRT (a popular open source home router firmware based on Linux).

SIDN Labs has installation instructions for people who would like to test-drive SPIN on their existing OpenWRT based routers. Please note that SPIN is still in development and has some rough edges. However, the project would be happy to get feedback (and pull requests) from actual users.

Part 2 coming soon

Watch this space for the second part of our day 4 coverage on RIPE 78.

Topics: IPv6, IPv4, DNS, IoT

The RIPE-javik logs: Day 2

Posted by Carsten Strotmann on 5/22/19 8:31 AM

ripe day 2

carsten@menandmice:~$ cat ~/ripe/ripejavik-day2.txt | blog-publish

The second day of RIPE 78 started with the plenary, and three presentations on the topic of Distributed Denial of Service (DDoS).

DDoS

DDoS attacks are an increasing risk on the Internet. Mattijs Jonker from the University of Twente explained how DDoS attacks work. His research has revealed that many businesses have all their Internet services (website, mailserver, etc.) in a single network. In case of a DDoS attack, all services are impacted. He counted 31 thousand websites, 3.5 thousand mailservers, and 323 DNS servers that are on a single network and would suffer in case of an attack. An alternative IP address from a different network (autonomous system/AS) would make the services more resilient.

Matthias Wichtlhuber from the German Internet Exchange DE-CIX found that DDoS attackers only use certain protocols for their amplification attacks:

  • unspecified (Port 0)
  • NTP (Port 123)
  • LDAP (Port 389)
  • DNS (Port 53)
  • Chargen (Port 19)
  • Memcache (Port 11211)

Filtering these ports (in transport networks) will stop most DDoS attacks. The problem is that most ISPs cannot do fine-grained filtering. Most can only filter on networks or IP addresses, which blocks all traffic from or to a certain machine. DE-CIX has developed a new fine-grained black-holing system for DDoS attacks that is currently in beta testing.

Koen van Hove, also from the University of Twente, presented the DDOS clearinghouse: a project to collect data of DDoS attacks in a central place. The aim is to be able to research DDoS attacks and develop fast responses to them. The DDoS clearinghouse collects network measurements, identifies DDoS attacks across networks with unique fingerprints, and stores this data in a database (DDoSDB). From the database, attack information and metadata can be retrieved to help users feed fingerprint signatures into their network systems to stop DDoS attacks.

DNS

After the morning break, the main topic was DNS. David Huberman from ICANN discussed the root server system. After talking about the history of the DNS root server system, he explained that there has been no process so far for selecting new root server operators.

With over 1.120 root server instances in the world, 340 of which are in the RIPE region, the root server system is stable and there is currently no need to add additional root server operators beyond the 12 that run the 13 logical root-server addresses. ICANN is not working on a defined governance model for the root server system.

OpenINTEL

Next on the stage was Roland van Rijswijk (NLnet Labs) presenting the OpenINTEL project he has contributed to. OpenINTEL is a massive active measurement system that sends 218 million DNS queries per day from several vantage points on the Internet, resolving a defined set of DNS names. The results will be collected in a big database (Big Data helps to get research funds these days), which so far contains 3.1 trillion results since the start of the project in 2015.

The OpenINTEL system allows researchers to search for various kinds of interesting data: parent-child TTL mismatches, distribution of authoritative DNS-Servers in different AS networks, or even silly things stored in DNS TXT records (like funny IPv6 addresses or private cryptographic keys). The project can be found at https://openintel.nl

KSK roll

Like always, Geoff Huston (APNIC) delivered a highly entertaining talk, this time about the KSK roll in October 2018.

Officially, there was no impact seen for the DNSSEC validating resolvers. But some operators, like EIR in Ireland, have missed all notices about the roll in the two years leading up to it and failed to change the trust anchor of their DNS resolvers which lead to a full-day outage of their DNS resolver services. Other smaller operators were affected as well, some of which fixed the issue by disabling DNSSEC. All except two have re-enabled DNSSEC after fixing their DNS resolver configurations. Geoff also noted that the DNSSEC trust state signaling (RFC 6975 and RFC 8145) does not work reliably to detect broken KSK rolls in the root zone.

Migration from IPv4 to IPv6

In "Get Ready for Mixed World: Economic Factors Affecting IPv6 Deployment", Brenden Kürbis and Milton Mueller from the Georgia Institute of Technology talked about the economics behind network migration from IPv4 to IPv6.

The problem of IPv6 is that it is not possible to switch off IPv4 right away. Instead, IPv4 must be kept enabled for some amount of time (dual stack deployment). The cost generated due to IPv4 depletion will stay, the cost of introducing IPv6 will come on top. Only after some years will the cost benefits be visible. Depending on the growth pattern of the company and the networks, the first cost savings can appear as early as 4 to 10 years. Larger companies will have more benefit from IPv6, while smaller companies will not see economic benefits. In the following Q&A session, people from the audience challenged some of the assumptions in the research that generated this report.

DNS flag day

In the last DNS talk of the day, Petr Špaček from CZ.NIC and Ondřej Surý from ISC gave some insight into the DNS flag day in February 2019.

DNS vendors (Bind 9, Knot, PowerDNS, Unbound, and others) and large DNS resolver operators (Google, Cloudflare, Quad9, etc.) disabled workarounds for broken EDNS implementations. The workarounds were developed to help with DNS servers on the internet that had faulty implementations of the DNS protocol. However, because the workarounds existed, the operators of these faulty servers had no motivation to fix their systems. The cost of developing and maintaining the workarounds fell to the vendors of the DNS products.

For the February 2019 flag day, there was an estimated breakage of 5.68% of all DNS servers. Two large DNS operators were responsible for 66% of this breakage. The flag day was considered a success, as the pressure generated compelled the operators to fix their systems, and no other significant breakage was reported on that day.

Motivated by the success of this first flag day, the DNS server vendors plan another in 2020. No exact date has been set at the moment. On the next flag day, new DNS software releases will change the default settings for EDNS buffer size from today's 4096 bytes to a value around 1220 bytes. The goal is to prevent fragmentation of IP packets, which is known to be broken in some networks and can be a security risk. For this change, authoritative servers and DNS resolvers must be able to operate over TCP in addition to UDP. The main problem is misconfigured firewalls that block DNS over port 53/TCP.

The flag day website will be updated with detailed information about the date and will include online tests so that DNS administrators can test their systems.

More tomorrow!

RIPE 78 is a busy event, with much more going on than we were able to report here. Do visit the session archives to check the other presentations - there are plenty more good talks to dig into. We’ll be back with more RIPE coverage tomorrow!

Topics: IPv6, IPv4, DNS, DDoS, RIPE 78, OpenINTEL, KSK roll

The RIPE-javik logs: Day 1

Posted by Carsten Strotmann on 5/21/19 6:35 AM

ripe day 1

carsten@menandmice:~$ cat ~/ripe/ripejavik-day1.txt | blog-publish

The first day of RIPE 78 started with the welcome talk by RIPE chair Hans Petter Holen and the hosts of the meeting: Icelandic sea-cable provider Farice and RHnet, the university network provider of Iceland.

It was impressive to hear that Iceland has already achieved 80% Fiber-to-the-Home installation and will have 100% by 2025. In terms of Internet speed, Iceland is only second after Norway (for mobile Internet) and Singapore (for fixed line Internet).

After short talks by Andrew Sullivan, the president and CEO of ISOC, the Internet Society (the organisation that facilitates Internet Standards Processes such as those developed by the IETF, amongst other things) and Benno Overeinder for the RIPE Program Committee, probably the best known Icelander in the Internet community took to the stage: Ólafur Guðmundsson, inventor of DNSSEC and currently CTO of Internet accelerator Cloudflare.

IPv4 volatility

Ólafur’s topic was the volatility of IP addresses. While at the beginning of the Internet IP addresses were stable over a long time and could be used to identify a machine, this is not the case today. Mobile devices switch networks constantly, always getting new addresses. A smartphone can have more than 10 different IP addresses over the course of a single day, roaming across different mobile providers and wireless networks.

As Ólafur described, IP addresses cannot reliably be used to identify machines anymore. Still, many service providers, companies, and government agencies do that all the time, for

  • blacklisting,
  • geo-location,
  • to calculate online advertising prices by placing a value to the user using the IP address,
  • or to find the nearest content server.

IPv4 address brokerage makes the situation worse. Because there are no free IPv4 addresses left and many companies have not yet switched over to IPv6, IPv4 addresses are valuable (>20 US$ per address) and are for sale. When sold, these addresses change location, but providers of location databases cannot keep up with the changes and the databases become outdated and full of wrong data.

Roaming and routing

In the next talk, Alo Safari Khatouni spoke about the implication of mobile phone roaming in Europe. In his research, he has specifically looked into how IP data is being routed in roaming situations, and when the difference in latency and bandwidth impacts a roaming user’s experience.

He found no content discrimination (i.e. that certain data is being throttled during a roaming situation), but latency was certainly higher. Mobile network operators route the roaming traffic back to the home network, where it is then routed to the Internet. This means that for a customer of an US-based mobile network operator (MNO) who is in Iceland and trying to access a website in Iceland (to look up the weather conditions - vital information in Iceland!), the network data will be routed through the US MNO’s network. It’s no surprise that this is slower than staying in Iceland and accessing the data directly.

In the Q/A session following this talk, IPv6 evangelist Jan Zorz mentioned that he also experiences IPv6 Path-MTU-Discovery issues while being inside one of the MNO networks in Iceland. It may be that possibly someone is blocking ICMPv6 on the network.

ATLAS

In the first lightning talk, Christopher Amin from the RIPE NCC explained some of the security safety belts RIPE has built into the RIPE ATLAS system.

RIPE ATLAS is a network measuring networks, where ATLAS probes are distributed all around the world. These probes can be remotely controlled by researchers to make traffic measurements on the Internet from different points of the worldwide network. However, some probes are operated by private persons in their home networks and might be located in countries where access to certain Internet content is prohibited by law. Law enforcement might not be able to tell apart access from a real Internet device from that of an ATLAS probe.

To resolve this, RIPE has built in a host of security and safety measures to limit or block the access to sensitive Internet content, but also wants to add support for DNS-over-HTTPS (DoH) measurements to the ATLAS system. The problem here is that DNS-over-HTTPS looks, by design, like HTTPS traffic generated by a web browser. From the outside, one cannot see if the content requested is a website or DNS data. Enabling DoH measurements without restrictions can introduce risks for RIPE ATLAS probe operators. Christopher asked the RIPE community about their comments and how this challenge can be solved.

The second issue Christopher brought up was the use of EDNS (Extended DNS) options in ATLAS experiments. Researchers would like to test new or unspecified option values against DNS servers on the Internet, but this can lead to unexpected behaviour, even crashing DNS servers (if the DNS server software is not of high quality, which sometimes happens if network equipment vendors write their own implementations of DNS). There’s a risk in probing these EDNS options, but Christopher is not sure exactly how big the risk is.

IPv6-only

In the last lightning talk of Day One of RIPE 78, security expert Enno Rey presented his insights from an IPv6-only WLAN study that his company ERNW has conducted for a client. They found that mobile apps, especially on Apple’s iOS "just work.” (Which is no big surprise, as each app is tested by Apple to make sure it works as expected in an IPv6-only environment.)

ERNW found some applications that did not work out of the box and needed manual fixes, like the popular game "Fortnite" and its associated Epic Game Launcher. An XMPP (Jabber) component in the game only asked for IPv4 addresses (and the domain name has no IPv6 AAAA addresses), so this was naturally failing in a network without IPv4. Some other applications like Discord worked, but had some loss of functionality.

More tomorrow

This concludes our first report from RIPE 78. Check out our guide to both the event and the city, and stay tuned for more tomorrow.

Topics: IPv6, DNS, RIPE 78, ATLAS

Men & Mice Sensible IPAM Part 2: Scaling your IP Infrastructure

Posted by Greg Fazekas on 11/21/18 6:13 AM

Continuing our series on creating a sensible strategy to consolidate management of your scattered network resources, we take a look at what happens when new resources need to be added to your network.

This Playbook series consists of five parts:

Each part presents real-world problems that Men & Mice have experience in solving.

Scaling existing configurations

Imagine that you are:

  • an MSP Infrastructure Server Admin, using Microsoft. Your business utilizes Virtual Machines to handle client workloads, but without an efficient handling of IP addresses, your DNS doesn't get updated fast enough. Customers complain about lags.
  • a Product Manager for a SaaS company seeing an uptick in customer numbers. You have the system set up just right, but to handle all the demand, you are looking at pulling in dynamic resources using multi-cloud accounts. You also don’t want to add more team members to handle it, but automate instead.
  • a Director of Operations overseeing a large network spanning several locations. At the start, you used to have spreadsheets to track IP addresses, and kept configuration files practically in your head. Surely there must be a better way.

It makes no sense to start from scratch unless you have no other option. Any business that's been around for a while will have their workflows and configurations set up for the most part. And with the array of affordable cloud resources in services like AWS and Azure, moving on-prem configurations to cloud infrastructure becomes a viable option.

From smaller networks to large, from on-prem to cloud, from manual spreadsheets to automation: it’s just a matter of scaling.

What You Need

heterogenerous_IPinfrastructure

A DNS, DHCP, and IPAM solution to pull data unobtrusively from your existing configurations. You may have been using spreadsheets for tracking IP addresses, and a local library with DNS configuration files. Whatever they may be, you need to plug them into the new solution.

In addition, it needs to replicate and automate provisioning for new resources. Bonus points for a holistic approach, where various vendors can be brought in without the accompanying overhead, special training or new personnel. In short, you want to use an API-driven solution to control and manage all others.

Where Men & Mice can help

Men_Mice_DDI-1

A software-based, API-driven, and back-end agnostic solution, the Men & Mice Suite was developed to simplify core management of IP infrastructure in heterogeneous environments.

The Men & Mice Suite is a single-pane-of-glass overlay for your entire IP infrastructure, current, and future. Adding new resources, regardless of platform or vendor, isn’t hindered with compatibility problems since the software takes care of communicating with various on-prem solutions and cloud services through powerful, reliable APIs.

Overseeing multiple locations and resource allocations for different teams or projects can be done elegantly and easily. Already tested configurations can be deployed swiftly in new environments, extending oversight and reducing time for onboarding.

Once in place, configurations can be scaled and replicated easily and automatically. Copy or extend DNS zones and DHCP scopes, and deploy user authentication (including MS Active Directory) for new locations.

Spawning new virtual machines on cloud infrastructures is supplemented by IP address assignments that are reflected in all DNS servers. Once those IPs are released, the changes are automatically propagated through the network at once.

You and your team can reduce project time and cost significantly through more quickly responding to the changing needs of your business, without the need to set up lengthy processes each time.

Multi-cloud environments can be plugged into the Men & Mice Suite. Automated through a single API layer, and secured with role-based access control the network can scale out to any size and into any platform to accommodate workload, and scaled back once resources become unnecessary.

Plus, with Men & Mice, you can manage and migrate workloads to, from and between your on-prem and whichever best-in-class cloud service make sense for you. We'll cover hybrid and cloud-native solutions specifically in our next post.

 

Topics: IPv6, IPv4, IPAM, IP address management

RIPE 72 – A Blog Report on DNS & IPv6

Posted by Carsten Strotmann on 6/22/16 5:30 AM

RIPE 72 took place in Copenhagen from 23-27 May 2016. This blog report shares some of my thoughts on interesting talks and presentations on DNS and IPv6.  

As always, this report cannot be exhaustive and I recommend that those interested browse the meeting archive of RIPE 72 for other interesting topics.

DNS

Victoria Risk from ISC reported on the changes in the upcoming BIND 9.11 release (BIND 9.11 Release Update) that is planned for August 2016. The new catalog zone feature allows automatic provisioning of slave zones from a central catalog zone. New zones are configured as a master zone on one server and a special entry is written into the catalog zone, a meta-data zone that is configured on the master and all secondary servers. The catalog zone will be replicated by zone-transfer and the secondary server will automatically configure a slave-zone for the newly added domain.

Men & Mice Trainer Jan-Piet Mens has already had a chance to test this new feature and wrote a blog article about it: Catalog zones in BIND 9.11. ISC has issued an Internet Draft in the IETF about catalog zones with the hope that other DNS software vendors will implement a compatible version.

BIND 9.11 will include a new, refined backend for storing DNS zone data in databases, called the dyndb api. This new API is much faster than the older DLZ API and also works with DNSSEC.

Speaking of DNSSEC, BIND 9.11 will come with a new component called dnssec-keymgr that will be able to automate DNSSEC key-rollover based on a policy, much like the external OpenDNSSEC tool. More improvements to BIND 9.11 can be found in the presentation and also in the upcoming Men & Mice Webinar What's new in BIND 9.11.

Jeff Osborn from ISC started a discussion on a license change of the BIND 9 DNS Server in his talk Changing the Open Source License on BIND. Today, the BIND 9 DNS server is licensed under the ISC license, which is a permissive BSD-style license. Jeff proposes a switch to the Mozilla Public License (MPL), which is a so-called copy-left license. Both licenses are open-source licenses, but the main difference is that the MPL requires all source code changes to the product to be made public. This license change will have no negative effect on anyone using the BIND 9 DNS server, but might affect companies that build products that incorporate the BIND 9 server code. As an overlay management solution, the Men & Mice Suite product works with an un-altered BIND 9, so customers using the Men & Mice Suite would also not be affected by such a license change. Jeff welcomes any feedback on the license change. His contact information can be found in the talk's slides, available in the link above.

Patrik Faltstrom, Chair of the Security and Stability Advisory Committee on the DNS root-server system, presented an alert on WPAD Name Collision Vulnerability. WPAD, the "Web Proxy Auto-Discovery", is a way to configure the Web-Proxy to be used by a Web-Browser using DNS. In this function, the special domain name "wpad" is resolved in the local domain name of the network the client is in. Collisions with internal, non-registered domain names and new top level domains in the Internet DNS system now create the vulnerability that external parties can control the internal proxy configuration inside a company's network. Internet Explorer on Windows systems have this function enabled by default, but it can also be enabled in Firefox, Safari or Chrome-Browsers on MacOS X, BSD and Linux. Running an unregistered TLD in an internal DNS deployment is not recommended, but DNS administrators will find it difficult to remove the sins of the past. Administrators should block DNS queries for internal-only domains at their DNS-resolvers, monitor DNS queries leaving the network for internal names and consider manually switching off the WPAD function in the browsers.

Duane Wessels from Verisign gave a talk on the size increase of the Root-Zone Zone-Signing-Key (ZSK). Since the beginning of the DNSSEC-signed root-zone, the ZSK was a 1024bit RSA key, as recommended by RFC 6781 - DNSSEC Operational Practices, Version 2. However, while not an immediate security threat, 1024bit RSA keys are now also seen as having a too small security margin when used for DNSSEC signatures (1024bit RSA keys have been too weak for encryption for many years). The new ZSK will be a 2048bit key and it will be introduced into the DNS root-zone on 20th September 2016. All testing done so far indicates that there should be no problems. Even though the DNS responses from the root zone during a ZSK rollover do increase from 883 to 1138 octets/bytes, the response is still below the 1232byte EDNS0 limit often used in the IPv6-DNS-Resolver or the 1500byte Ethernet MTU.

The Unbound DNS-Resolver now implements DNS Query Name Minimisation to Improve Privacy, RFC7816. Ralf Dolmans of NLnetLabs explains in his talk QNAME Minimization in Unbound how this new feature is implemented. In traditional DNS, a DNS resolver always asks the full question to all servers in the delegation chain. This is because the DNS resolver does not know about the delegation topology of the DNS system in use. In the Internet, there is a defined delegation structure for DNS, starting with the root-zone, the generic, new and country-code top-level-domains and second-level domains owned by companies and individuals below it. In the Internet, a DNS-resolver can shorten the query when asking at the root-zone or TLD level, enhancing the privacy of the users of the DNS resolver. QNAME minimization in the DNS resolver used by a client machine can be tested with a DNS lookup tool such as dig

 

% dig txt qnamemintest.internet.nl +short


IPv6

John Jason Brzozowski from US cable giant Comcast presented IPv6 @Comcast – Then, Now and Tomorrow about the challenges and successes in their deployment of IPv6 "large scale". Overall, IPv6 at Comcast is a success and they are now putting in motion the plan to phase out IPv4.

In the IPv6-Working-Group session, John reported on Community WiFi and IPv6 and how Comcast is using IPv6 to create public WIFI hotspots on CPE devices. Comcast is giving out a full "/64" network to every WIFI-device connected, in order to create easy network isolation and to reduce the multicast traffic over WLAN. This scheme could have even more benefits, such as assigning an IPv6 address for every service running on a host.

The Google public DNS resolver now supports DNS64-translation (currently in Beta) on the public DNS-resolver address "2001:4860:4860::6464" (IPv6-Only Has Never Been So Easy). DNS64 is a translation technology that works together with NAT64 to allow a client on an IPv6-only network to connect to IPv4-only services on the Internet. As DNS64 "re-writes" DNS content, it clashes with DNSSEC, as Jen Linkova from Google explains in IPv6-only and DNS(SEC|64).The workaround proposed in the talk got some criticism from the audience.

Enno Rey from the security company ERNW had a close look at the security issues of Multicast Listener Discovery MLD, a topic that has not seen much attention so far. He and his colleagues have found several issues that can be used for denial of service attacks or traffic redirection attacks by an intruder inside the local network. He recommends an (still to be developed) "MLD guard" function in switches (similar to DHCPv4- or RA-Guard) or to deploy port based ACL filtering of MLD traffic. Nobody should panic because of these findings, but every IPv6 network admin should know about MLD and the implications of having MLD active in their networks.

Vaibhav Bajpai had an interesting talk on Measuring Webpage Similarity from Dual-Stacked Hosts, looking at the differences in website content between a page fetched via IPv6 vs. IPv4. Differences coming from certain objects on the page (CSS, JavaScript, Advertisements …) are only available for one protocol, while the general website is dual-stacked and therefore available on both IPv4 and IPv6.

Two talks covered the topic of IPv6-only networks, but from very different angles. In How to Make Trouble for Yourself - You Build an IPv6-Only Network in 2016, Roger Jørgensen from Bredbandsfylket Troms in Norway reported on their project to build a new fiber optic network in the far north of Norway. The management part of this network is designed and operated as an IPv6-only network. Luuk Hendriks gave a report of his attempt at Going IPv6-only at Home while keeping the most important user of his home network, his girlfriend, happy.

Enno Rey talks about Real Life Use Cases and Challenges When Implementing Link-local Addressing Only Networks as of RFC 7404 from his experiences implementing a Link-Local-only addressing scheme in a larger enterprise network. The Link-Local-only addressing was chosen to simplify address management, as almost 50% of networks in this customer's environment are point-to-point links. There are still issues with vendor support in network devices when implementing Link-Local-only addressing. In the discussion following the talk, the audience gave a mixed message, with some people claiming success at running a Link-Local-only network.

Other topics

Mircea Ulinic presented a way to automate the provisioning and management of network devices (router, switches etc) using the configuration orchestration tool "SaltStack". SaltStack is usually used to automate the provisioning of server machines running a Salt-Agent (Minion). As it is difficult to install a customer agent on network gear, this talk presented a way to use proxy machines that act as the minions for network hardware. SaltStack automation can save a great deal of time when used in large deployments. Details can be found in Mircea's talk: Network Automation with Salt and NAPALM.

Shane Kerr, who we recently had as an interview guest in our latest Webinar on Yeti-DNS, gave a humorous talk about the "Internet of Things (IoT)" in IoT: What is the Problem or “How To Explain To Your Boss That IoT Won't Make the Company Rich….”.

Those of you hungry for more on RIPE 72, all the above talks and more can be found in the meeting archive of RIPE 72.

Topics: IPv6, DNSSEC, DNS

[Webinar] IETF 90 Report – DNS, DHCP, IPv6 and DANE

Posted by Men & Mice on 7/7/14 6:15 AM

Report from IETF 90 in Toronto 2014

The IETF, Internet Engineering Task Force, those that are working on new Internet Standards, met in Toronto in July 2014.IETF resized 600

Mr. Carsten Strotmann from the Men & Mice Services team gives an overview of interesting developments from the working groups inside the IETF, after attending online at the IETF 90 in Toronto.

Hear more on:

  • DNS
  • DNS-Privacy
  • IPv6
  • DANE
  • DHCP(v6)
  • and new RFCs that have been published since the last IETF in March 2014

Fetch the slides, webinar recording and link collection.

Topics: IPv6, DNS, DHCP, Webinars

RIPE 68 report

Posted by Men & Mice on 6/25/14 12:04 PM

Report from RIPE 68 in Warsaw, Poland

A RIPE Meeting is a five-day event where Internet Service Providers (ISPs), network operators and other interested parties from all over the world gather.

In this webinar, Carsten Strotmann from the Men & Mice Services team reports about what was new at the RIPE 68 meeting.

Hear what he had to say on:

  • Amplification DDoS Attacks – Defenses for Vulnerable Protocols
  • news from DNS-OARC meeting (DNS measurements, open resolver stats)
  • Strengthening the Internet Against Pervasive Monitoring
  • What Went Wrong With IPv6?
  • RIPE IPv6 Analyser
  • IPv6 troubleshooting procedures for helpdesks
  • Using DDoS to Trace the Source of a DDoS Attack
  • Measuring DNSSEC from the End User Perspective
  • Google DNS Hijacking in Turkey
  • The Rise and Fall of BIND 10
  • Knot DNS Update – DNSSEC and beyond
  • Bundy-DNS – the new life of BIND 10

Have a look at the slides and recording from the webinar to learn more.


 

Topics: IPv6, DNSSEC, Webinars, BIND 10

On-link vs Off-Link Packet Delivery: Unicast, Multicast, Anycast

Posted by Men & Mice on 5/6/14 9:29 AM

By David Beck, a Men & Mice trainer and course developer

Delivering IP packets within a subnet (on-link) is different than delivering between subnets (off-link). This article examines those differences for unicast, multicast, and anycast destination addresses. The goal is to shine a light on the differences for anycasts and to explain on-link anycasting. Everything is applicable to both IPv4 and IPv6, with one exception that is clearly noted. However, that difference is why this is fundamentally an IPv6 article. The IPv6 terminology "link" will be used in lieu of "subnet." "Node" will be used in lieu of "host."

UNICASTS

A unicast address uniquely identifies one interface on one node. It is used to deliver a packet to only one interface. It is the type of address that initially comes to mind, when one hears "IP address." A sender with a unicast destined packet looks up the packet's destination address in its routing table, and selects the longest-match.

The longest-match entry may indicate that the destination is on-link (OL). For an OL destination the sender uses the data link layer (DLL) protocol, e.g. Ethernet, to deliver the packet to the final destination. Alternatively, the longest-match may indicate that the destination is off-link (XL, external-link). The routing table entry for an XL destination includes an OL router that is closer to the destination. The sender uses the DLL protocol to deliver the packet to the router. The router repeats the same process sending the packet toward the final destination.

An internet is two or more links (networks) joined by a router. It is the need to deliver unicast packets to XL nodes, that spurred the creation of internet protocols such as IP. If all destinations were OL, packet delivery could be done with only the DLL protocol and DLL addresses. (Note that the Internet is a huge internet with links throughout the world joined by routers.)

MULTICASTS

A multicast address identifies multiple interfaces on multiple nodes. A packet is delivered to all identified interfaces. In both IPv4 and IPv6, multicast addresses are distinct from unicasts and easily identifiable. IPv4 multicasts are 224.0.0.0/4 (addresses starting with 224-239). IPv6 multicasts are ff00::/8. Multicasting was not always a part of IP. It was added at the end of the 1980s.

Delivery of OL IP multicasts relies on the capability of the underlying DLL protocol to support multicasting, or to at least support broadcasting. Happily, Ethernet and 802.11 wireless have multicasting functionality and there are multicast MAC addresses. This makes OL multicasting delivery simple. IP multicast addresses are mapped to MAC multicast addresses through a formula, for IPv4 that is defined in RFC "Host Extensions for IP Multicasting" (http://www.rfc-editor.org/rfc/rfc1112.txt), and for IPv6 in the RFC “Transmission of IPv6 Packets over Ethernet Networks” (http://www.rfc-editor.org/rfc/rfc2464.txt). A node assigned a multicast IP address configures its network interface to listen for the corresponding MAC multicast address. When a packet is sent to an OL IP multicast address, it is packed in a frame destined for the corresponding MAC multicast. All nodes listening for the MAC address, receive and process the frame and the packet. OL multicasting is easily implemented, and widely used.

Both IPv4 and IPv6 routing protocols rely on OL multicasting. A router sends one packet to notify all others of routing protocol information, such as a network topology change. (OL delivery of IP multicasts, with underlying DLL protocols that don't support multicasting or broadcasting, can be very challenging. That little nightmare is happily well outside the scope of this article.)

XL multicasting, with a multicast address assigned to nodes on different links, is far more challenging. A special multicasting routing protocol must be implemented. The sender generates one packet; multicasting routers must duplicate the packet to deliver it to nodes on different links. XL multicasting is not widely used. The mass majority of organizations doesn't implement multicasting routing protocols. Multicasting routing protocols are not used in the open Internet.

ANYCASTS

Now we're reaching the heart of this article.

Like a multicast, an anycast is an address assigned multiple interfaces on multiple nodes. Unlike a multicast, an anycast packet is delivered to only one node. The sender doesn't care which node receives the packet, all the destinations are equivalent.

Like multicasting, there is a wide chasm between OL and XL anycasting. For multicasting, OL is easy and widely used. XL multicasting is challenging and rare. It is the opposite for anycasting. XL anycasting is easy.

XL anycasts are used for root and TLD (Top Level Domain) DNS servers. For example, the F root server (f.root-servers.net) has the IPv4 address 192.5.5.241. The address is an anycast. It is currently assigned to fifty-five DNS servers throughout the world (http://www.isc.org/f-root/). For DNS, all these servers are identical. When a packet is sent to 192.5.5.241, the natural process of unicast routing delivers it to only one node (one DNS server). Since all the servers have the same information, it is unimportant which is reached. In order for administrators to manage individual servers, each also has a unicast address, but that address is not intended for answering DNS queries.

XL anycast addresses are indistinguishable from unicast addresses. When a unicast address is assigned to a second node, the address becomes an anycast. The various nodes assigned the address don't know that it is an anycast and not a unicast. No special handling is required by nodes assigned an anycast address. No special handling is required by a sender generating a packet to an anycast destination. There is no protocol supporting anycasts. None is needed. Normal unicast routing handles delivery of XL anycasts. The only requirements are that the nodes sharing an address are on different links, and routing is properly configured. There isn't even an RFC defining the technical specifics for XL anycasting. Note that several RFCs discuss anycasting. For example the RFC "Operation of Anycast Services" is a Best Current Practices (BCP) document (http://www.rfc-editor.org/rfc/rfc4786.txt).

While XL anycasting is found in IPv4 and IPv6, OL anycasting is only implemented in IPv6. Nodes on the same link share an address. A packet addressed to an OL anycast is still delivered to only one interface. However, because the nodes are on the same link, routing can't handle delivery. Unlike XL anycasting, OL anycasting requires a technical specification. RFC "IP Version 6 Addressing Architecture" (http://www.rfc-editor.org/rfc/rfc4291.txt) specifies OL anycasting.

A node assigned an OL anycast sends Neighbor Advertisements (NAs). The NAs associate the anycast address with the node's own DLL unicast address. The NAs are fundamentally the same as the node would send for an assigned unicast address. Mapping an OL anycast, to the DLL unicast of a node, was a fundamental implementation decision taken by the IPv6 designers. Without prejudice as to whether it was a good or bad decision, it is noteworthy that there were other options. For example, First Hop Redundancy Protocols (FHRPs), essentially implement an OL anycast address, but with a completely different approach. The IETF standardized FHRP is RFC specified: "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6" (http://www.rfc-editor.org/rfc/rfc5798.txt).

By definition, an anycast address is assigned to multiple nodes. Each node assigned an OL anycast sends NAs associating the address with its own DLL unicast. These NAs are basically competing with each other. Other nodes on the link associate the OL anycast with one DLL unicast address, with one of the nodes assigned the OL anycast. If, three nodes on an Ethernet share an anycast address, another OL node will use the unicast MAC address of one of the three. When a packet is sent to the anycast address, the DLL deliveries it to one node. In this way, the anycast requirement of delivery to a single node, is met.

It is worth considering why DLL unicasting is used for OL anycast delivery. While it isn't ideal, it is necessary because DLL protocols don't have anycast capabilities. If, for example, Ethernet had anycasting addresses and anycast functionality, an OL anycast could be mapped to a MAC anycast. OL anycasting would then be as trivial as OL unicasting, and OL multicasting. Since DLL anycasting doesn't exist, OL anycasts must be mapped to what DLLs provide, unicasts, broadcasts, or multicasts. DLLs broadcasting and multicasting functionality cannot be used, because they violate the anycast requirement of deliver to only one node. So delivery of an OL anycast is necessarily implemented by a DLL unicast.

XL anycast addressing require no special handling. OL anycast addressing does. A node assigned an OL anycast must be explicitly informed that the address is an anycast, requiring IPv6 systems to implement a technique to indicate anycasts. The OL anycast indication suppresses Duplicate Address Detection (DAD). When an IPv6 unicast is assigned, DAD tests if the address is assigned to another node on the link. The address isn't used if DAD reports duplication. Anycasts are purposely assigned to multiple nodes, so DAD is disabled for OL anycasts. Additionally, OL anycast NAs are sent with a slight delay, and, more importantly, with the Override flag cleared in the NA message.

A set Override flag tells the receiver to replace a previously cached entry for the advertised IPv6 address. For a unicast NA, the Override flag is set, so that a receiver uses the new advertisement. This makes sense since the unicast NA is coming from the same node that sent the older cached information. Newer unicast information is better. For an OL anycast, each node assigned the address sends an NA with its own DLL address. The cleared Override flag in these NAs means a receiver will use the DLL address from the first NA that arrives. Older anycast information is better.

The cleared Override flag prevents oscillating between different DLL addresses for the anycast destination. It additionally means that, at any given time, senders on a link are reaching different nodes that share the anycast address. This can be viewed positively, as it provides load balancing. However, it can't be controlled and all senders could also be sending to one DLL address (to one node). Unfortunately, if a cached OL anycast destination becomes unreachable, it can't be replaced until the cached entry times out. So for the unlucky nodes on the link with the unreachable address cached, the OL anycast is unreachable, but for all other nodes on the link the anycast is reachable.

So unlike an XL anycast, an OL anycast requires both special configuration and special handling on the nodes assigned the address. Neither OL or XL anycasts require special handling by senders.

RFCs define IPv6 OL anycast addresses. Being defined distinguishes them from other anycasts, which are purposely indistinguishable from unicasts. The most common OL anycast is the Subnet-Router anycast (SRA). Every link has an SRA address. All the interface identifier bits set to 0, identifies the SRA. For the link 2001:db8:cafe:fee::/64, the SRA is 2001:db8:cafe:fee::/128. The SRA is defined in RFC 4291. RFC "Reserved IPv6 Subnet Anycast Addresses" (http://www.rfc-editor.org/rfc/rfc2526.txt) reserves the highest 128 addresses on each link for OL anycasts.

Initially it may seem that the SRA would be an ideal way to implement a FHRP. However, the widely used FHRPs, HSRP, VRRP, GLBP and CARP all support IPv6 without using the SRA. Where is the SRA used? Saying it has not been widely implemented, is overstating its current uses. Depending on feedback, perhaps another article will delve deeper into the SRA.

So it ends on a whimper. IPv6 has added OL anycasting, but it is unused by any significant application, and its usefulness is questionable.

SUMMARY

IP unicasting, both OL (on-link) and XL (external-link, off-link), is easy and widely implemented.
OL IP multicasting is easy and common. XL multicasting is more involved and uncommon.
OL IP anycasting is extremely rarely used and limited to IPv6. XL anycasting is easy, and although not common, widely used for DNS.

Topics: IPv6, Anycast

Why follow Men & Mice?

The Men & Mice blog publishes educational, informational, as well as product-related material for everyone and anyone interested in IP Address Management, DNS, DHCP, IPv6, DNSSEC and more.

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all