Tag Archives: dhcp

ISP y u no DNSSEC?

Posted on by
Reply

Unbound is a secure, lightweight and high performance validating, recursive, and caching DNS resolver. It performs DNSSEC validation and it is also really easy to configure. Although it cannot act as a full fledged authoritative server, you may take a look at NSD, which is, on the contrary, authoritative only. For a nice tutorial about unbound configuration, see this post.

Today I discovered local_unbound on FreeBSD. This script generates a configuration suitable for running unbound as a forwarding resolver. It also uses resolveconf to update the list of forwarders. This means that it is automatically configured with the name servers provided by the DHCP offer.

By default, unbound is configured to withheld the reply from the client when the validation fails. Unfortunately most of the name servers provided by home routers and ISPs do not support DNSSEC. Even worse, some ISPs redirect all queries to their own name servers which of course do not support DNSSEC either. You can check if it is the case with this command:

dig @8.8.8.8 +short test.dnssec-or-not.net TXT

As Google public DNS support DNSSEC. If it does not show you anything, it is OK. If instead it says something like: “Nope!  DO bit not set in your query” then your query has been forwarded to a server which is not DNSSEC capable.

Because of this, you often end up with a nice caching forwarding resolver which does not seem to resolve anything (at least on the client side) because of bogus validations.

You have two solutions to overcome this. First you can force your forwarders to DNSSEC capable servers such as Google public DNS (8.8.8.8 / 8.8.4.4). However, as mentioned above this does not work when your ISP redirect all queries to its own server. The second solution is to configure unbound into permissive mode (/etc/unbound/unbound.conf):

server:
    (...)
    val-permissive-mode: yes

In that case, replies to queries that did not pass validation are not longer withheld from the client but the Authenticated Data bit is not set in the reply.

Intel NIC connection problem

Posted on by
Reply

PCIe ASPM is an hardware power management protocol for PCI express devices. It allows a far better power management than what can be done with software power management at the price of an increased latency to the device. However some hardware don’t advertise it properly. And this was in fact the origin of the power regression case of 2.6.38 which was later fixed in 3.3.

It may also cause some Intel NIC (such as e1000e) to fall asleep unintentionally. So if you have an Intel NIC on Linux and it even fails to acquire an IPv4 address then you might try to add this option to your kernel command line : pcie_aspm=off. On Debian you can add this option to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and issue an update-grub.

You may also want to change the link-state of one specific device to L0/L1 at runtime. For this I’ll point you there : http://wireless.kernel.org/en/users/Documentation/ASPM.