Dr Strangelove, or: How I Stopped Worrying and (almost) Love the Surveillance.

Imagine for a while that you lived in a city with no modern facilities. Food was gathered through communal efforts, where there was a direct link between what you could find and what you could consume. People lived in small huts. Heat was produced and absorbed from small fireplaces. Water was collected from dedicated collectors, hanging between the huts. You get the idea, total hippie-ville. Your location within this city of dirty feet does not matter, but let’s say you live in the middle. Smack in the epicenter of hippie tobacco-scented dreams. Your name is Bob. Hi, Bob. You have a friend called Garry. Where Garry lives matters not, but let’s pretend he lives in the outskirts of town. One day you notice that you are running low on firewood. Not good, since you need the firewood to cook your stew. You decide to ask Garry for some, and prepare for the walk to his hut. Remember, you can’t just call Garry, so you have to track there. On your way, you pass about 10 huts. As it is in the middle of the day, people are outside enjoying the sun. You say hello to all your friends, namely Maria, Sarah, Evan and Tom. You also pass four or five that you do not know by name, but recognize. In addition, you pass a sketchy figure who you have never seen before, and, quite frankly, hope to never see again.

When you finally make it to your friend’s hut, you realize he is not home. What a waste of perfectly good slacker time! You turn around and go home, passing all the same figures, as well as another sketchy dude, who has joined up with that other sketchy dude who you have now had the questionable pleasure of seeing twice. But all is still well in your little corner of the world. You enter your hut, sit down, have some tea and let your brain analyze what has just happened. On your way to Garry’s hut, you passed by four friends, four acquaintances and two sketchy figures in strange clothing, passing most of them twice; one time on your way there, and one time on your way home. As you analyze the situation, you worry about those unknown characters who forced themselves into your life by appearing in a most unexpected location. Who were they? What did they want? Why were they there?

As the golden sky turns purple, your concern turns into fear. Just as the light of day is lost, so, too, is your calm. You wander about in your hut, shaking your head; “How could I be so careless? Why did I take that path and not my secret path that goes underneath the village”. Did I forget to tell you about the secret path? Oh, ok, well, there is a secret path. There. I just created that out of thin air. Deal with it. Suddenly, you hear a knock on the door. It is not just any knock, it is your secret knock-signal. You know it is Garry’s knock, and you open the door. To your surprise, Garry appears as upset as you are. He yells, carefully muffled through a whisper; “Bob! Oh, Bob! Why did you not take the secret path? Today I noticed two people I do not know wandering about outside my hut. How did they find my hut? You must have lead them there!”. As his weary eyes scan your face, as if to detect remorse, you realize what you have done. Not only have you compromised your own security, you have now pushed your friend into harm’s way. And for what? All you wanted was some firewood. You could have easily asked a neighbor nearby. Why did you go through all that trouble? You are almost as baffled by your own neglect, as you are by the appearance of two strange figures behind Garry. “Who are you? What do you want?”, you yell out. The men remain silent. Ear-deafening silent. Just as sudden as they never spoke, they leave. Left behind are two very concerned hippies, san-firewood, and the night is coming.

Without firewood, there will be no way to see, and without vision, anything could happen. So, what do our friends Bob and Garry do? The only sensible thing. They hide under their blanket until dawn pierces through their fear and thaws enough hope to make them venture outside again. They decide to go to Garry’s place to get some firewood, so as to make sure this never happens again. Strangely, all the acquaintances are gone. The village appears almost empty. When they approach Garry’s place they realize what has happened; someone has taken all the firewood. Left behind are two diseased men, in strange looking attire. As if they were from some strange land far away. It appears the two figures in strange clothing were trying to protect Garry’s firewood. Unfortunately, they were not strong enough in numbers to stop the ongoing robbery-turned-homicide.

As Garry and Bob weep for their newly diseased friends, they start arguing about who of them is to blame. Was it Bob for having shown the way to the hut? Was it Garry for leaving his house in plain sight, thus enabling the robbers to choose his hut over all the other huts, as a reasonable target for theft? Was it both of them for not having taken the secret path, that only passes by the huts of friends? From underneath the blanket, they argue all day and all night. The following morning, just in time for the swallows to start target-practice on the hut’s roof with remains gathered at various places around the village, they realize they do not have enough data to decide what would have been the ideal path. On one hand, they trust their friends. However, they do not know who their friends have befriended, and how many degrees of separation there exists from them to possible bystanders on the secret path. They also come to terms with the fact that it is impossible to know what made the murderers-to-be choose Garry’s hut. The most chilling realization, however, was that they had completely misjudged the two strange-looking men, who appears to have put up a brave fight on their behalf. Perhaps they only came to the hut to warn us, Bob gasps. Perhaps, his friend signals by calmly nodding, filled with a sudden onset of remorse.

The more they think about it, the more they agree that the unknown factor was not the sketchy figures around whom they treaded carefully and suspiciously. Nor was it their friends, whom they trust completely. It appears the problem was one of falsely assuming security where there was none; among acquaintances. It is likely one of the robbers were from that group. People they know just enough to not know at all. So, is there a point to this story? Well.

The trojan horses of our modern society are human. Make no mistake. The worst computer virus does not come as an attachment in an email. It comes from human interaction. It comes from the brain’s inept ability to separate close friends from faces we see daily. This is the same mechanism that makes some of us weep when a celebrity whom we have never met, takes his last breath on a sidewalk in Hollywood, or her last drink in Camden town. Our brains have evolved during a time when anyone you saw frequently was a friend, not foe. We have simply not evolved much since technology took off like a rocket on an epic journey, destination unknown. Daily, on TV, radio and the Internet, we are fed information about whom to trust. Instagram, Twitter, Facebook. Everywhere are we made part of a full-blown orgy of false trust. At the same time, we are warned about governments listening in on our phone calls, emails and on our credit card purchases. Yes, this is scary. No, it is not the biggest problem out there. Take the village for example. Whenever you walk somewhere, you can be watched by hundreds of people, just the same as when you visit a website in Kazakhstan, or, if you live in Kazakhstan; somewhere else. The real problem is not the enemy you expect, in strange attire or government suits.

The real foe is those that you expect to be good, namely acquaintances. It is much more likely someone in your close physical (or virtual) proximity will hurt you, than that a government will, unless you are up to some seriously dubious activities, in which case, best of luck. Why is this? Well, it is logical really. Say there is a web of trust between Garry and Bob. Anything Bob says to Garry, he expects Garry to keep secret. Garry, on the other hand, trusts Lisa and knows that she would never tell anyone. So, he tells Lisa about the things he is worried about regarding Bob. Lisa has never met Bob, but trusts Maria (and so on, and so forth). This happens on Facebook daily when people share things publicly. It also happens when we talk in a store and someone accidentally listens in. In short, it happens all the freakin’ time, everywhere! It is not something that started happening with the Internet, it has always been the case as it is human nature to apply trust, and subsequently promote future trust by sharing additional information. Without fail, however, you will eventually reach enough degrees of separation for the data to be compromised by someone or something. Since there is only one government per country (usually), but there are literally millions of people if you combine the paths on social networks that any piece of information could potentially travel, it is far more likely that your information will get compromised by sharing it with friends, rather than by sharing it with foes (the government). Especially when the motives of the government remains unclear, but we know a lot about the motives of people, who act predictably and not according to military doctrine (which is very complex in comparison, and rarely, if ever, logical from our perspective).

So, I, for one, have decided to stop worrying and almost love the surveillance, or at least hate it a bit less. Sure, it may not be ideal, but neither are people, and I know more people than I know governments. All of the people I know of who have been put behind bars, have been so for having spoken on public networks or on the phone; not because the government has cracked their encryption. We all make mistakes, but when we assume we are safe, that is when we are the most vulnerable.

 - Johan Boger

Logical Improvements to the Robtex Backend Algorithm, based on IPv6 rollout.

Logical Improvements to the Robtex Backend Algorithm, based on IPv6 rollout.

As some of you may have noticed already, we have updated the GUI and the algorithms used for https://as.robtex.com.  A working example (of as48285) can be found here: https://as.robtex.com/as48285.html.  I find it easier to understand changes if they are explained one by one. So, here goes:

A) The rollout of IPv6 in our backend, and subsequent increase in functionality, forced us (this is a good thing) to reconsider the use of IPv4-specific terminology.  Most notably, this affects [anet,bnet,cnet].robtex.com.  The functions are of course still active, but will now automagically reroute you to the correct section of the site, depending on the data processed. 

Reproduction Tutorial (IPv4):

1. Go to https://anet.robtex.com / https://bnet.robtex.com or https://cnet.robtex.com.
2. Enter "66.249.75", press "go". 
3. As you can see, the system has now processed the data and forwarded your request to the correct backend (in this case https://route.robtex.com/66.249.75.0-24---google.html), regardless of what URL you chose to use above, the calculations will end up being the same.  We strongly encourage you to use "66.249.75.0/24" instead of "66.249.75",  as it is never wrong to use CIDR, but neglecting to do so can be at times. Applicable scenarios are considered out of scope for this article. 

Reproduction Tutorial (IPv6):

1. Go to https://anet.robtex.com / https://bnet.robtex.com or https://cnet.robtex.com.
2. Enter "2607", press "go". 
3. What happened now?  That was not what we expected?  Go back again.
4. Don't worry, this is per design.  Why?  Well, to answer that question we must first compare legacy IP with IPv6.  Legacy IP has undergone multiple transformations, the dominant one being the implementation of CIDR in 1993.  Since then, the correct terminology for a legacy "A-net" is an '/8', per CIDR regulations (rfc1518).  However, naturally an /8 network corresponds to the legacy A-nets, so the term is still sometimes used, although it is only ever accurate when discussing /8, /16, or /24 networks (the networks with the same netmask as the old A/B/C-nets), and even then it makes little sense. For IPv6, using CIDR is recommended for the same reason; it is far more flexible. So, what should we use instead?
5. Try entering "2607:f8b0::/32", or any network you want to look deeper into. 
6. You should now have been rerouted to https://route.robtex.com/2607:f8b0::-32.html. You will notice that you can travel downstream recursively through the interface.

Those of you who have paid attention up until now, might already have realized that you can go straight to https://route.robtex.com for routes, and https://as.robtex.com for information on Autonomous Systems.  

But there is more, the system can now handle cross-site searches, so if you enter "as48285" at route.robtex.com, Robtex will be very forgiving and reroute your request to the section of the Robtex Backend (in this case, https://as.robtex.com/as48285.html) that makes the most logical sense, based on data input. Obviously, vice versa holds true, too.  In fact, any syntax will pretty much work anywhere, as long as you abide by the guidelines detailed in the Reproduction Tutorials above, regarding CIDR.

B) Robtex has always been an extremely powerful engine, with an (according to some) suboptimal graphical design that is sometimes hard to grasp for beginners.  It is extremely tech oriented, per design.  We believe there are plenty of beautiful GUIs out there to leave room for at least one that focuses solely on functionality, as we believe that gives us the only edge that matters. Graphics change, powerful functions remain.  However, we do acknowledge that functionality requires a level of intuitive design to work well.  It is a hard balance when you need to prioritize.  As we rely on your feedback, to find this balance, we have tried to listen to what you have had to say on Google+, and have, to the best of our abilities, tried to implement what we feel is a reasonable balance. Which leads us to the next point on this list:

C) Again, go to https://as.robtex.com/as48285.html.  Notice the new menu?  It now has a mouse over info-box, which will provide you with some function specific guidance.  You can choose to use the menu, or just scroll down.  From this interface, you can explore pretty much anything worth knowing about the structure of the Internet.  But again, let's go through them one by one for clarity:

1. AS-info will tell you when this information was gathered, and from what databases. Robtex uses multiple sources, as well as our own algorithm, but the public sources are all listed here.  The information displayed may not always be up to date.  It should update once the full routing table has spread across all neighbors, from wherever the change was made.  Due to limitations outside of our control, some of which are inherit to the Border Gateway Protocol itself, the propagation of prefixes to and from BGP neighbors might at times result in unfortunate delays. Usually, this is not a problem, as Robtex has counter-measures in place to proactively ensure that the data is as up to date as possible, through best-effort caching and other techniques considered out of scope for this article. The pie chart underneath is a work in progress, as it does not yet scale well with Tier1 networks with an enormous amount of peers.  This is something we will fix as a direct result of feedback from you, our users.  Thank you!
2. Graph shows you a visual representation of the connections between the different Autonomous Systems' edge routers.  Thanks to your feedback, there is now a static horizontal scroll at the bottom, so that you can always scroll horizontally, and not just when you are in the #graph anchor.  Please also pay attention to the fact that you can click any Autonomous System in the graph, and display the network topology from that Autonomous System's perspective.  A visual looking glass, of sorts.
3. Peers will show you all the data that is used to populate the Graph, but in text format.  In addition, it will also display AS macro and potential BGP endpoints. 
4. BGP will show you what prefixes are announced by the Autonomous System in question, as well as any information available from the different sources, such as descriptions, announcements and registrations. Naturally, you can also click any of the networks, and it will display any applicable https://route.robtex.com backend-data.
5. Sources will display raw data collected, for general information and verification purposes.

So, we hope you like the new design, and that you will appreciate the IPv6 support and better GUI.  If you do have additional feedback (please, let it be so), don't hesitate to contact us at https://google.com/+robtex. 

Thank you for your time and traffic.  Without you, Robtex would just be an extremely advanced calculator. 

Best Regards,

Johan Boger, Robtex.com

How to fix broken SOA serials

Hi,

Today we will cover the basics on how to fix a broken serial number, or SOA, in BIND. For the sake of this example, let's assume we have two nameservers; ns0.example.com being the master, and ns1.example.com being the slave.

What's the scenario ?

You want to add a new PTR record to your master (ns0.example.com). After you reload BIND to push your new DNS changes, you notice you accidentally added an extra digit to the serial number while incrementing it. The new serial number, '20130327002', is one digit longer than the previous one, incrementing it tenfolds. In your eagerness to correct the mistake, you remove the last digit and reload the master. Unfortunately, this breaks propagation, as the slave will not accept any updates associated with serial numbers lower than its own. The slave still has the incorrect serial number. Updating the serial in the master won't suffice, as those changes will be ignored by the slave.

An easy fix would be to just add an even higher value and reload the master. While that would work, it doesn't fix or undo the original mistake. A better approach would be to reset the serial back to its original 10-digit format, without breaking configuration or propagation.

But how ?

First, we need to understand how serial numbers work in BIND. The serial number, and only the serial number, determines whether a change in the master should be pushed to its slaves. The serial numbers are maintained manually, where a total of two changes are made for every one record that is added; adding the actual record, and then incrementing the serial number to flag the changes as new. However, this process is prone to errors where admins sometime forget to update the serial, increment by too much, or not enough. Other DNS server packages might handle serial numbers differently, but for the sake of this article, let's assume the whole world runs BIND. The date format is really just a convention. Any number will do fine, but for administrative purposes, it is good to use the date of the latest change.

The Start of Authority (SOA) is an unsigned 32-bit integer that can wrap around the largest possible 32-bit unsigned integer. As such, one can increment the serial repeatedly until it rolls over the max and goes through the 0. What this means in layman's terms is that if you increase the SOA enough, it will overflow and start from 0 again. So, by adding a value 2 or 3 increments higher than the theoretical max, BIND will interpret it as a low value. After that, you can then reset the serial number to its original 10-digit format. However, let's go through the steps one by one, for clarity. It is assumed in this guide that today's date is the 27th of March, 2013. This would make the ideal serial for the first edit 2013032701.

1: Open the faulty zone file for your IP network. Make sure you replace the IP network with your own. The /24 listed below is a test network that will not work for you. The PTR we want to add in this example is 1 86400 in ptr ptr.example.com. Of course, your PTR should already be in the file since the only problem in this example is a faulty serial number.
One thing to consider, is that for the rest of the guide to accurately depict your situation, we recommend you turn on notify for your slaves, and/or lower the timer, so that the changes propagate faster. This will speed up the process considerably.

sudo vim /var/named/2.0.192.in-addr.arpa

2: Locate the faulty SOA (20130327002), and replace it with the max value for an unsigned 32-bit integer. Did it just get really complicated? Don't worry; you're not alone. This is where things get tricky for most people without a calculator. However, it is not as hard as it seems, as the max value can be calculated using the formula ((2^32) -1), which gives a theoretical range of 0 to 4294967295. Note that you should avoid using 0 as it may be significant and could have a special meaning in certain DNS implementations. Another thing to consider is that the max incrementation one can do, is actually calculated using ((2^31) -1) which gives a result of 2147483647. What this means, is that if you increment the number by the maximum value (2147483647), it will wrap through max and end up the same number. A lot of guides will tell you this part is a two step process, where you first add the max incrementation value, and then push the changes and increment it again. However, in most cases, you can save some time by incrementing it to the max value for an unsigned 32 bit integer. This will also save you some calculations, as incrementing with the max incrementation value, will only work if the old value + incrementation wont exceed the max. But, anyway, saving time is good, mkey. So, let's do that.
The new value after the change should be 4294967295.

3: Reload BIND (or just the zone file if you prefer that).

/etc/init.d/named reload

4: Make sure the change has now been pushed to all slaves.

4.1: You can do this by using bash:

host -C example.com. 

This should give you a result similar to (but with your data, of course. Note that the first value on rows 3 and 6 are the SOA):

Nameserver 199.43.132.53:
        example.com has SOA record sns.dns.icann.org. noc.dns.icann.org. 
        4294967295 7200 3600 1209600 3600
Nameserver 199.43.133.53:
        example.com has SOA record sns.dns.icann.org. noc.dns.icann.org. 
        4294967295 7200 3600 1209600 3600

OR

4.2: By using the excellent interface at Robtex.com. It will provide you with a lot more information than is available by using the program 'host', as well as present the data in a more easily readable format. Remember, easy is good, mkey.

No matter what method you choose, make sure both the primary and secondary nameservers have the updated serial number (4294967295). If they do, you can safely assume the PTR changes have propagated across the network of nameservers (you could have a lot more than just two here, so make sure it is the same -everywhere-).

5: Open your zonefile again, and change the value to the correct serial. Again, we recommend using the date followed by two incrementation slots for maintenance convenience. In this case, it would be 2013032701. There is no need to make it 2013032702 as we have wrapped the value through max completely and anything above 0 would now work.

6: Repeat step 4 for the new serial number. If you were not successful, go back and make sure step 2 was followed to the last detail. If you were successful, proceed to the next step.

7: Celebrate by rewarding yourself with a cold drink in the sun. Congrats! You have now fixed the broken DNS propagation in BIND, using Serial Number Arithmetic and Mathematics For Fun and Profit. For more information, check the applicable RFC, available at: http://tools.ietf.org/html/rfc1982.

Thanks for listening!

Best regards,

Johan Boger, Robtex.com

(A shout-out to Mikael Abrahamsson and the rest of #networker for providing valuable feedback)

We have joined the NLNOG-RING!

Hi everyone,

Great news! We are proud and excited to announce that yesterday we applied, and were subsequently approved, to join the NLNOG-RING ('The Ring'). It is, in essence, a distributed network used for diagnostics, where users donate nodes (or servers) to the ring, and in exchange get access to all the other connected nodes. This enables network administrators to quickly perform ring-wide traceroutes, pings and other diagnostics from one shell, as opposed to logging into multiple networks.

More importantly, The Ring functions as a circle of trust amongst network operators, enabling members to gain access to network nodes normally off limits to them. We believe that participating in the Ring enables us to further contribute to the networking community, as well as gain valuable resources for diagnostics and monitoring of our network, AS48285.

For more information, please visit The Ring, and check our Google+ site for more frequent updates: Google.com/+robtex

Best regards,

Robtex.com

...back in action.

Hey!

After an exceptionally long hiatus, blog.robtex.com is finally back in action. Our friends over at Google+ have already interacted with us for a couple of weeks now, but we figured we should revive this blog, too.

We are currently working hard on implementing new features. Among other things, robtex.com will soon support IPv6 and 32-bit autonomous system numbers (ASN). In addition, we're also planning a major step in the history of robtex.com, the details of which have yet to be announced. For now, please keep your eyes fixed on this location.

Oh, and don't forget to circle us on Google+, where we interact with our users and share tech-savvy links. We would love to see what you guys enjoy reading, so please circle us and share away. :-)

All the best!

peeringdb.com

We just added data from peeringdb.com on AS-number information.
For instance, see bottom of first tab for AS174 .
Also new BGP data has been imported.

New AS update

Fresh BGP-Tables were successfully processed and new AS information is ready.