DNS Naming

 Computing  No Responses »
Jul 242018
 

As someone who has spent far too much time dealing with the Domain Name System, I get kind of miffed when people insist on creating names that conflict with the DNS ordering. You see the DNS naming works from right-to-left (the wrong way around if you’re reading this in English).

Take the name for this site – really.zonky.org – which is admittedly a rather quirky name. The most significant part of the name is at the right (org – and yes I’m ignoring the really significant and invisible “dot”). The next most significant part (zonky) specifies what organisation has registered the site (me), and the least significant part (really) points to one service at that organisation.

So when people ask for names that break that ordering it is ever so slightly irritating – for example if you have a service called mail.zonky.org and wanted a test service you might request mail-test.zonky.org which breaks the ordering of things. As an alternative, test.mail.zonky.org doesn’t break the naming, looks a bit nicer, and ultimately more reasonably flexible.

Let us look at a slightly more complex example; let’s assume that we have a domain called db.zonky.org and want to register a service name for each database. We could register names such as db-addresses.zonky.org, and db-orders.zonky.org, or we could register them instead as addresses.db.zonky.org and orders.db.zonky.org. In the later case, I can very quickly write a firewall rule that allows access to *.db.zonky.org (whereas db-*.zonky.org would not work).

Ultimately suggest names in DNS naming order unless you can justify why it is not suitable.

 

Exim: Rejecting Mail With No Reverse DNS

 Computing, Linux, Security, Working Notes  No Responses »
Feb 122017
 

A very long time ago, I used to collect spam in order to graph how much spam a single mail server was likely to get over time, and almost as long ago, I lost interest in maintaining it. As a consequence I still get a ton of spam every day and after a long period of procrastination I have been slowly raising defences against spam.

This particular recipe is not really a defence against spam – it verifies that the remote server is properly DNS registered with a reverse DNS registration – in other words that the IP address it is connecting from is registered. This is a requirement for all mail servers, and as it turns out, spammers don’t care for registering their servers in the DNS.

This ACL snippet goes into the ACL for checking the recipient or for checking the message :-

 deny
   message = Your mail server is not properly DNS registered
   log_message = BLOCKED: No rDNS
   condition = ${if eq{$host_lookup_failed} {1} {1}{0}}
   # Check rDNS and block if not registered

There are three items of interest :-

  1. The message is intended to be easily read by recipients to determine what the problem is. It turns out that many people do not read NDRs, but if we get the message right at least we are doing the right thing.
  2. The log_message is intended to make automating log parsing easier.
  3. Within the condition, the $host_lookup_failed variable indicates that the reverse DNS lookup returned NXDOMAIN and not that it timed out (which would be $host_lookup_deferred).

That’s all there is to this little piece of configuration.

Friday’s DDoS: Assisted By Poor DNS Configuration

 Computing, Security  No Responses »
Oct 222016
 

Yesterday lots of people found the Internet disappearing on them due to a significant DDoS attack against the DNS infrastructure of one company. Now there are all sorts of suggested fixes for this sort of problem, some of which are useful.

However it is notable that people have not mentioned one method built into DNS which could have been used more effectively. Indeed one suggestion was for the DNS to do something it already does – caching.

When you ask your ISP’s DNS servers to resolve a name such as example.org, the answer that your ISP’s DNS server gets back contains several bits of information in addition to the answer you are interested in (the IP address to connect to). One of which is how long to cache the value for, which means that your ISP’s DNS servers can save themselves some work for as long as they are allowed to cache the answer for.

Now it is awfully convenient to set this value to something like 5 minutes because if you have a need to change the value, it is nice to have the value change as quickly as possible.

But it also increases your vulnerability to a weaknesses in the DNS infrastructure.

If you increase the time-to-live (TTL) value to something more like 24 hours, then your DNS servers (or more usually the DNS servers of your DNS service provider) are required less frequently which means that if something takes them offline for any reason then there would be a decreased impact. It will still stop some people from getting the DNS answers they need, but the proportion unable to get an answer will drop dramatically.

 

damascus-dns

IPv6: Why The DNS Is So Important

 Computing  No Responses »
Oct 192016
 

This is a bit of a thought experiment, so it may be not entirely correct (especially the maths – my probability theory is very rusty).

One of the lesser reasons for using the DNS rather than IP4 addresses is that typing mistakes are more easily caught – if you intend to type 192.168.67.52, but accidentally enter 192.168.67.53 instead, you still have a valid IPv4 address. Whereas entering the domain name wombar.example.com instead of wombat.example.com will most likely get you an error instead of sending your secrets off to an unknown location on your network – unless you have a rather silly server naming convention of course!

But how likely are you to make a mistake typing in an IPv4 address? According to a random web site “out there”, the average accuracy of a typist is 92%, or an average of 8 typos per 100 characters. If we convert this into a probability, we get a probability of typing each character correctly as 0.92.

Given that typing IPv4 addresses is something that some of us have a lot of practice at, and in many cases we will notice typos before they become a problem, I’m going to arbitrarily declare that the probability of getting any character within an IPv4 address correct is 0.999. But to type in an IPv4 address correctly we have to get a maximum of 15 characters correct :-

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
1 9 2 . 1 6 8 . 1 2 8 . 1 2 8

So the probability of getting all those characters right is 0.999 (first character) x 0.999 (second character) … Or 0.999^15.

And once you work that out, subtract it from 1 (to get the probability of making a mistake) and convert it into a percentage, there is an 11% chance of making a typo in an IPv4 address.

For an IPv6 address such as 2001:db8:ca2c:dead:44f0:c3e9:28be:c903, which has 38 characters (no I’m not doing that silly table for IPv6) – 100 * (1 – 0.999 ^ 38) – 32%.

Now whilst my calculations may be a bit off, the likelihood of entering an IPv6 address incorrectly is nearly three times higher than the risk of entering an IPv4 address incorrectly.

In other words, with IPv6 you really need a good working DNS solution just to keep the errors to manageable levels.

dam-ip6

Always Check Your DNS Resolver (/etc/resolv.conf)

 Linux, Working Notes  No Responses »
Apr 252015
 

So for ages I've been having these mysterious slow downs in connecting to some of my internal servers. A few seconds, but once connected things are working normally.

And of course I kept putting off having a look into the problem, because firstly I'm lazy, secondly there are other more interesting things to look at, and thirdly I'd already discounted the obvious (actually I'd "fixed" it but made certain assumptions). But it's finally time to have a look.

Now I said I'd earlier discounted the obvious but decided to have a look any way. The thing to remember is that when you connect to a server it almost always performs a DNS lookup on your network address, so a mysterious slow down could well indicate that DNS resolution is to blame. You could perform diagnostics to determine what the problem is, but in all the decades I've been solving issues with computers whenever a mysterious slow down has occurred when connecting over the network, then the problem has almost always been the DNS resolver.

Taking a look at /etc/resolv.conf on the relevant server (a Linux container), and I find the file has a nameserver within it that was retired several weeks ago! Fixing that solved the issue.

Lessons learnt :-

  1. Just because you have a centrally distributed /etc/resolv.conf that is automatically installed on all your home network doesn't mean to say that it is always automatically installed. My Linux containers don't get that centrally distributed file (which had been corrected!).
  2. Don't assume that it's not the obvious even if you have reasons for thinking it couldn't possibly be the obvious (see #1).

 

 Older Entries