Tag: howto

Setting up 6to4 on Debian

by mithrandi on May.08, 2010

There are already any number of blog posts, wiki pages, and so on spread all over the internet that cover this topic. However, all of them seem to be based on outdated information, making the instructions and configuration involved more convoluted than necessary. So, without further ado, here’s the easy way to set 6to4 up on Debian.

First, you will need to calculate your 6to4 IPv6 address prefix, which is based on the IPv4 address of the host you are using as your 6to4 router. For example, if your router’s public address is 10.10.10.1 (this is NOT actually a public address):

$ ipv6calc --action conv6to4 10.10.10.1
No input type specified, try autodetection...found type: ipv4addr
No output type specified, try autodetection...found type: ipv6addr
2002:a0a:a01::

Add 1 to the end of this to obtain your router’s address, 2002:a0a:a01::1 in this case. Next, you will need to add an entry for the tunnel to /etc/network/interfaces:

auto tun6to4
iface tun6to4 inet6 v4tunnel
    address 2002:a0a:a01::1
    netmask 16
    gateway ::192.88.99.1
    endpoint any
    local 10.10.10.1
    ttl 255

Replace 2002:a0a:a01::1 with your IPv6 router address, and replace 10.10.10.1 with your public IPv4 address; 192.88.99.1 is the anycast address for the nearest 6to4 gateway, so leave that alone unless you know what you’re doing. You can now bring the tunnel up with ifup tun6to4, and you should have IPv6 connectivity.

Your 6to4 prefix is a /48, allowing you to allocate 2 ^ 16 (65536) /64 subnets below this. In the usual case of a small home / business network, you won’t need more than one of these, so just pick one to use for your network. For example, if we pick DEAD, the network prefix would be 2002:a0a:a01:dead::/64. You can manually assign addresses to the hosts on your network, but it will probably be easier to do EUI64-based autoconfiguration; this allows each host to automatically select an address based on their MAC address when they receive a router advertisement. In order to send router advertisements, you will need to install radvd, and then put something like the following in /etc/radvd.conf:

interface eth0
{
    AdvSendAdvert on;
    prefix 0:0:0:DEAD::/64
    {
        AdvOnLink on;
        AdvAutonomous on;
        Base6to4Interface ppp0;
    };
};

Replace eth0 with the name of your network interface; this is the interface on which router advertisements will be broadcast. You could hardcode your 6to4 prefix, but it’s more convenient to use the Base6to4Interface option to have radvd calculate it for you; replace ppp0 with the interface for your public internet connection, and the prefix will be altered accordingly. If your public internet connection is not on a separate interface, then just remove this option, and replace the prefix address with the full address as shown earlier.

Your hosts should now have performed EUI64-based autoconfiguration and configured a public IPv6 address for themselves, unless you have disabled this for some reason. If you need to manually calculate the auto-configured address for a particular host, you can do so given its MAC address:

$ ipv6calc --action prefixmac2ipv6 --in prefix+mac --out ipv6 2002:a0a:a01:dead::/64 11:22:33:44:55:66
2002:a0a:a01:dead:1322:33ff:fe44:5566/64

Replace the prefix and MAC address with your own, of course. If IPv6 privacy extensions are enabled, this address will be assigned to the network interface, but an additional temporary anonymous address will be assigned based on a randomly-generated identifier. The temporary address will be used for outgoing connections, thus avoiding exposing your MAC address to every host you connect to; the permanent address can still be used for incoming connections, allowing you to use this address in DNS entries and so on. Privacy extensions will typically be disabled by default on Linux-based hosts, and enabled on Windows hosts.

There is usually no real reason to disable privacy extensions; however, there is another feature enabled by default on Windows hosts that you may wish to disable. This feature randomizes the identifier used for the permanent address, separately from the temporary addresses assigned by privacy extensions. The randomly generated identifier should be persisted, so the address will not change, but it will bear no relation to the MAC address, thus preventing you from being able to calculate it. If you wish to disable this feature, run the following command with Administrator privileges:

netsh interface ipv6 set global randomizeidentifiers=disabled

If you also wish to disable privacy extensions, you can use the following command, but note that this is not necessary if you just want persistent EUI64-based addresses:

netsh interface ipv6 set privacy disabled
1 Comment :, , , more...

DNS evils: glueless delegations

by mithrandi on Apr.22, 2007

tags:

One of the most serious design flaws in DNS today, is the decision to use hostnames in NS records, instead of IP addresses. Why? Because it has the potential to massively complexify the chain of DNS queries a recursive resolver has to follow in order to resolve a particular name.

Let’s say you type http://www.google.com/ into your web browser. Your web browser hands the address www.google.com to the resolver library; it will generally end up making a recursive query to your ISP’s caching resolver. This is where all the hard work happens. The resolver starts by sending a query for A www.google.com to one of the root nameservers; it will then respond with the list of NS records corresponding to the servers hosting the .com TLD. The resolver will then repeat the query to one of these servers, and so on until it arrives at a server that is authoritative for www.google.com, which it has determined by following the chain of delegations in the form of NS records, and by getting an authoritative response from a server it queries.

So, that may seem simple enough; however there’s one snag here: NS records contain hostnames, and not IP addresses, so when the resolver receives an NS record containing a particular hostname, it then needs to perform a separate lookup, starting the process all over again. This second lookup could, in turn, require a third lookup to be performed for hostnames encountered during the second query, and so on. If this were the whole story, it would actually never be possible to resolve these NS records, because there would be no way to locate the server containing the A records for those servers in the first place.

Enter delegations with “glue”; a DNS query response has multiple sections, one of which is particularly important here: the “additional” section. This section contains records that, while not directly part of the records requested, may be helpful in using the records returned in the other sections of the response. This allows for returning A records for the hostnames specified in the NS records returned, thus providing a way for the resolver to avoid making a secondary lookup. Unfortunately, this is only possible under certain circumstances: if your DNS server is authoritative for google.com (by way of an NS record served up by the .com servers), you can return records relating to google.com, and any domain “below” it, such as quux.google.com. Resolvers recognize that your server is authoritative for these names, because they have followed the chain of NS records starting at the root. So, if you return a record like ns1.google.com 172800 A 216.239.32.10 in the additional section, resolvers will accept (and cache) this, and be able to avoid a secondary lookup of ns1.google.com. However, if your NS records point at some other address, such as ns1.yendor.net, even if you return records providing an address for ns1.yendor.net, resolvers *must* ignore these records, as your server is not authoritative for yendor.net, or anything above it. Thus, there is no way to avoid the secondary lookup; these cases are referred to as “glueless” delegations.

So, to summarize: delegations with glue are almost as good as having IP addresses in NS records, as they avoid a secondary lookup for the hostname specified in the NS record. Glueless delegations, however, do require a secondary lookup, leading to situations where a convoluted chain of delegations must be followed and many queries made in order to look up a name. This leads to increased vulnerability to attack: compromising any server along the chain gives you the ability to influence the final result, by directing the resolver to servers under your control. In addition, the increased number of queries can lead to timeouts due to the length of time it takes to get all of the responses. To see an example of how bad this situation can become, I’ve prepared transcripts simulating what a resolver has to do in order to look up a particular domain name: dns insanity and dns sanity. Also, the level of indirection along the chain may change at any time, as presumably the other names along the chain are not directly under your control (otherwise you wouldn’t have used a glueless delegation in the first place); an additional level of gluelessness might be added, causing longer delays and possibly failures, without you realising until users start complaining.

There are a few reasons you might want to use glueless delegations; probably the most common is the case where a third party is providing all of your DNS servers, or at least providing backup servers. In this case, they probably already have a hostname for their servers, and you may wish to simply use this, rather than copying their IP address into your record data. The simplest way around this is to do just that; copy their address into your data. DNS server addresses should usually be quite stable, so you shouldn’t have to worry too much about the address changing; just make sure the third-party provider notifies you of any such changes when they are to occur. Another way would be to have an automated process (either built into your DNS server, or as a separate service) that caches the address, looks it up again (using a normal simple recursive query), and updates the DNS server data if the address changes. This is effectively what resolvers have to do anyway with a glueless delegation, but this way it is only your server doing it, rather than hundreds, thousands, or millions of resolvers around the internet. Both of these solutions require a little more work on the DNS admin’s end, but improve the efficiency and reliability of your DNS data publication.

So please, think of the childr… err… dns resolvers, and use glueless delegations.

Leave a Comment :, , , more...

Darcs on win32

by mithrandi on Aug.04, 2005

tags:

Marlon blogged about the difficulties of using Darcs under Windows, especially setting ssh up. I had to get Darcs up and running on my windows workstation at work earlier this afternoon, so I figured I’d post a little HOWTO here for everyone’s benefit.

First of all, you need a win32 binary for Darcs; while you could compile it yourself, the easy way out is to get a build from Will Glozer’s site.

Now, if you just want to use Darcs over NetBIOS, this is all you need. Just stick darcs.exe somewhere on your %PATH%, and then you can happily tell Darcs to push to a UNC path (eg. darcs push \\fooserver.local\cdrive\path\to\repo) and work like that. However, if you want ssh support, then you’ll need to do a little more work.

First of all, you’ll want the following binaries from the PuTTY “suite”:

Once you have these, place them somewhere on your %PATH%, and do a little renaming: rename pscp.exe to scp.exe, psftp.exe to sftp.exe, and plink.exe to ssh.exe – these are the command names Darcs expects to have available.

This will be enough to let you push/pull/get/etc. over ssh, but you’ll soon get tired of typing out your password 34345234345 times, so you probably want to setup public key auth for ssh. To do this, first run puttygen.exe to generate a keypair. The default options that it starts with should be fine, so just kick off the generation process, and follow the instructions. When you’ve generated the keypair, save the private key wherever you want, and then copy the “known_hosts format” line out. Place it on a line by itself in ~/.ssh/authorized_keys on the ssh server (create the file if it doesn’t already exist), and then make sure the permissions on the file are correct. Run chmod 600 ~/.ssh/authorized_keys if you’re not sure; the reason for this is that ssh is very picky about the permissions of your configuration files.

You could now use pageant to manage the use of your private key, but an easier way is to create a profile in PuTTY with the same name as your ssh host; go select your private key at SSH -> Auth -> Private Key file for Authentication, fill in the same info for the hostname and profile name on the first config section, and then save the profile. The command-line tools will now use this profile when connecting to that hostname, thus avoiding the need to type in your password over and over again. (Note that anyone that gets access to your private key can now access your account, so be aware of the potential security issues.) Also, bear in mind that if you want to setup Darcs/PuTTY on another system, you could just copy your private key over to it, rather than generating a new one.

For convenience (mostly my own), I have prepared a handy package of all of the files mentioned above; you may prefer to download it rather than download each binary separately.

Leave a Comment :, , , more...

Search

Loading