After some searching, I’ve found a Polish website that is hosted on an IDN domain name, which makes it a useful test vector.
- http://ąćęłńóśźż.pl/
- ascii punycode equivalent: http://xn--kda9ag6e8jma6nxjsa.pl/
Posts tagged ‘DNS’
Together with most of the internet, we tested IPv6 on World IPv6 day last week. I won’t go into details on what IPv6 is and why it’s important. Although IPv6 has been tested intensely in isolated networks, this is the first time it was tested on such a large scale. Technically, the participants would just add AAAA-records for their websites to DNS. This small change causes a huge effect. Since most browsers are configured to prefer IPv6 AAAA-records over IPv4 A-records, this causes all IPv6-connected users to suddenly connect over IPv6 instead of IPv4.
For the most part, this major changeover happened without as much of a hitch. In fact, if I hadn’t known it was World IPv6 day, I wouldn’t have noticed anything. But I’m not a normal web-user, so I did notice some issues.
Continue reading ‘World IPv6 day – lessons learned’ »
dd-wrt has built-in support for a whole list of Dynamic DNS services. Unfortunately, they only support HTTP-based services. I use a standard RFC2136 DNS update. Here’s how to add nsupdate support to dd-wrt.
Continue reading ‘Using nsupdate in dd-wrt’ »
I just read this message by Mark Andrews on the BIND mailing list. It explains the possible issues with DNSSEC and over-protective firewalls, giving test-commands to verify your setup. This post is also interesting for regular DNS traffic, since a firewall doesn’t know the difference.
DNSSEC, short for DNS security, provides a security extension to the all important DNS system. A nice intro can be found on wikipedia. This is a part of a series on DNSSEC:
- The RRSIG record
- The NSEC and NSEC3 record
- The DNSKEY and DS record
- Implementation
Time to put things together and setup a simple DNSSEC secured zone using BIND. Instead of providing a walkthrough, I’m just going to refer to the DNSSEC HOWTO (local mirror of the PDF version) of NLnetLabs. It provides a very thorough explanation of the whole DNSSEC concept, including copy-paste examples to try out. Also, it goes more into practical details such as key rollover, the benefits of using two keys (a Zone Signing Key, or ZSK, and a Key Signing Key, KSK).
DNSSEC, short for DNS security, provides a security extension to the all important DNS system. A nice intro can be found on wikipedia. This is a part of a series on DNSSEC:
- The RRSIG record
- The NSEC and NSEC3 record
- The DNSKEY and DS record
- Implementation
To verify the digital signatures inside the RRSIG records, the client needs to have access to the corresponding public key. What better mechanism than DNS itself could be used to convey this information to the clients? Public keys are stored in DNSKEY records inside the zone. To facilitate key rollovers, new keys are added ahead of time, while old keys remain in the zone until all entries have expired in the caches. Continue reading ‘DNSSEC – The DNSKEY and DS record’ »
DNSSEC, short for DNS security, provides a security extension to the all important DNS system. A nice intro can be found on wikipedia. This is a part of a series on DNSSEC:
- The RRSIG record
- The NSEC and NSEC3 record
- The DNSKEY and DS record
- Implementation
While the RRSIG record allows you to verify the authenticity of returned records, there is still a gap remaining. What if the requested name does not exist? Since the DNS server replies with an empty answer section, there is nothing to sign. That’s where NSEC (or its brother NSEC3) comes into play. An NSEC record (Next SECure) states the range of names that do not exist. By signing this NSEC record by a corresponding RRSIG record, one can prove that a domainname does in fact not exist.
Continue reading ‘DNSSEC – the NSEC and NSEC3 record’ »
DNSSEC, short for DNS security, provides a security extension to the all important DNS system. A nice intro can be found on wikipedia. This is a part of a series on DNSSEC:
- The RRSIG record
- The NSEC and NSEC3 record
- The DNSKEY and DS record
- Implementation
The RRSIG record is the basic building block of DNSSEC. It accompanies every Resource Record Set (RRset) and provides a digital signature over the provided data. This record is only supplied if the client indicates that it understands DNSSEC. A client does so by setting the DO (DNSSEC OK) flag (part of EDNS). If the server adds this record, it can be used to prove that the received data is authentic and hasn’t been tampered with (or prove the opposite). If, on the other hand, the response doesn’t contain RRSIG records, there are two possibilities. Probably the zone just doesn’t use DNSSEC, but it’s also possible that the response has been tampered with and had its RRSIG removed. Unless you have some prior knowledge, it’s impossible to know which case you’re in. This should be solved once the root-zone becomes signed in July 2010.
When hosts have a dynamic IP, it’s very convenient to have its DNS-name follow that dynamic IP. There are several services on the net that do this. However, the regular DNS already provides this feature. The nsupdate tool (comes with BIND) allows you to send an update to the DNS servers. By default, a DNS server does not allow updates for security reasons.
To keep the whole world from updating your zone, there are several possibilities to restrict who can update what. The easiest to setup is an IP restriction: specify from which IPs updates are to be accepted. In my setup, however, I’d like the host to update its own record. Since the host’s IP is dynamic, this is not an option.
