SolarScale Blog

Random Hackepedia

The RH for this week is Termcap.

Wildcarddns at BETA_4

Wildcarddnsd is now at BETA_4 tag. I've merged branch TTLPATCH to HEAD and tagged it. I also branched off BETA_4STABLE for errata and bug fixes between BETA_4 and BETA_5. I want to keep developing at HEAD from now on much like other open source projects, that's why I branch a stable branch because things could get broken between commits.

Here is a timeline of tags for Wildcarddnsd:

• initial commit, Tue Nov 29 17:00:02 2005 UTC
• BETA_1, Thu Jul 24 17:42:08 2008 UTC
• BETA_2, Mon Aug 31 14:03:10 2009 UTC
• BETA_3, Tue Nov 3 17:16:30 2009 UTC
• BETA_4, today

I'm looking for people who have an interest in DNS and have some C coding skills to help me with this project. The only other thing I require from them is some patience while I adjust to a group effort, which I have no experience in. Some things we need for this project is TCP support, EDNS0 support, DNSSEC support, AXFR (through cryptochannel) and perhaps Dynamic updates, also TXT support would be nice (very simple) and NS support for delegating zones to other nameservers (a bit harder).

Random Hackepedia

The RH for this week is Sed.

DNS compression in a DNS question?

How does that work? I have pretty well sandboxed my windows machine behind a firewall and I use wildcarddnsd to read off what hosts it tries to reach. Well..wildcarddnsd refused some questions because they had a DNS compression inside it, which doesn't make sense since it would create an endless loop IMO. Here is the dropped packet warning:

Mar  5 11:10:40 rosalind wildcarddnsd[30362]: question has compressed name, drop
Mar  5 11:10:40 rosalind wildcarddnsd[30362]: on descriptor 5 interface "127.0.0.1" malformed question from 172.16.0.10, drop

Mar 05 11:10:40.349416 rule 1/(match) [uid 0, pid 814] rdr in on vic1: 172.16.0.
10.62485 > 127.0.0.1.8053: [udp sum ok] udp 35 (ttl 255, id 329, len 63)
  0000: 4500 003f 0149 0000 ff11 8f49 ac10 000a  E..?.I..ÿ..I¬...
  0010: 7f00 0001 f415 1f75 002b 92a3 86e8 0100  ....ô..u.+.£.è..
  0020: 0001 0000 0000 0000 0264 7207 5f64 6e73  .........dr._dns
  0030: 2d73 6404 5f75 6470 01c4 0000 0c00 01    -sd._udp.Ä.....

Downtime

Today I woke up to proteus.solarscale.de not pinging anymore. The downtime was around 3.5 hours as the provider that I use did some repairs on the main server that proteus is a vm guest on. In that time I updated the DNS table for solarscale and added uranus.centroid.eu as a mailserver. It would have worked getting _some_ mail because the TTL on the zone is 86400 and I mainly just get mailing lists. Unfortunately it turns out that the OpenSMTPD that I use doesn't recognize aliases (bug) and returned mail with a 530 message. No mail was really lost as the remote mailservers attempt to deliver again but it was annoying. I sent gilles@ an email explaining the error message that I got, perhaps he can get a fix in before the OpenBSD 4.7 release.

PS: oh yeah proteus had an uptime of 410 days before this mishap.

Wildcarddns does global load balancing

Well I finally got around to wildcarddnsd again and trashed all stuff I wrote for it. That was yesterday. I was able to hack up some new stuff that uses a sort of firewall ruleset to determine where a nameserver comes from and then serve based on that information to which server the request should go. I got it running in beta (centroid.eu) watch closely.

The following is a ping from proteus (germany) to centroid.eu, the IP it gives is proteus itself (also germany).

pjp@proteus:~/blog> ping -c 1 centroid.eu
PING centroid.eu (62.75.160.180) 56(84) bytes of data.
64 bytes from proteus.solarscale.de (62.75.160.180): icmp_seq=1 ttl=64 time=0.06
3 ms

--- centroid.eu ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.063/0.063/0.063/0.000 ms

The next is a ping from dione (panama) to centroid.eu. The IP it gives is dione itself, similar to the above ping:

goldflipper% ping -c 1 centroid.eu
PING centroid.eu (200.46.208.61): 56 data bytes
64 bytes from 200.46.208.61: icmp_seq=0 ttl=64 time=0.027 ms

--- centroid.eu ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.027/0.027/0.027/0.000 ms

Now there has been a few ethical debates whether DNS should "lie" or not and I think in favour of loadbalancing it should lie and tell an IP that's closest to the client. This is still in beta and I'm watching it closely and then I'll merge it into HEAD.

PS: I've balanced it in such a way that IP's comeing from RIPE and APNIC go to the server in Germany, and ARIN and LACNIC go to the server in Panama. I haven't dealt with the other regions yet, they may get defaulted to LACNIC.

Modification to webserver

Privacy just got a lot better when you visit this website. According to an article in the german magazine "C't magazin fÃr Computer technik" (2010 Edition 5, page 154), the storage of IP data is illegal. Specifically the correlation between IP and access time. So what I've done is patch my webserver (lighttpd) accordingly to throw out the last last 2 octets from the dotted quad. I can now roughly see which region you're from in my logs but not who exactly you were, I'm not interested in that anyhow but if someone wants my logs it won't give them much.

Here is the patch:

--- mod_accesslog.c..orig       2010-02-27 17:31:49.000000000 +0100
+++ mod_accesslog.c     2010-02-27 17:38:01.000000000 +0100
@@ -742,8 +742,12 @@
                        case FORMAT_REMOTE_HOST:
 
                                /* handle inet_ntop cache */
+                               {
+                                       sock_addr myaddr = con->dst_addr;
+                                       myaddr.ipv4.sin_addr.s_addr &= 0x0000fff
f;
 
-                               buffer_append_string(b, inet_ntop_cache_get_ip(s
rv, &(con->dst_addr)));
+                                       buffer_append_string(b, inet_ntop_cache_
get_ip(srv, &myaddr));
+                               }
 
                                break;
                        case FORMAT_REMOTE_IDENT:

A typical log looks like this then:

66.230.0.0 solarscale.de - [27/Feb/2010:17:46:46 +0100] "HEAD /public/rfc2516nc.
mp3 HTTP/1.1" 200 0 "http://www.deezer.com" "Mozilla/4.0 (compatible; MSIE 6.0; 
Windows NT 5.1; SV1; .NET CLR 1.1.4322)"

The other VPS I have in Panama I'm not going to do this patch because I'm unsure of what the legalities there are there. This should only affect the centroid.eu domain though and if you wish to read only from the german server use solarscale.de. Cheers!

Random Hackepedia

The RH for this week is Integer.

The Hunter and his dog

Yesterday I was able to see the starsky again. I took these pictures of Sirius and Orion through the trees.

Random Hackepedia

The RH for this week is Gingerale.