DNSSEC (DNS Security Extensions), a more secure DNS protocol is to be implemented on May 5th. With the rise of DNS Poisoning and Man-in-the-Middle attacks rising, the Domain Name System will be going to a secure version of DNS next month.

The changes will add digital signatures to the DNS protocol. This will reduce the risk that users will be redirected to rogue sites masquerading as the real deal. But these changes are being implemented with caution. Normal DNS packets are under 512 bytes. According the “The Register”, the new secure DNS packets will be much larger than 512 bytes and some existing firewalls could reject them:

Because of this, some pieces of network gear are configured out of the box to reject any UDP packet over 512 bytes on the basis that it’s probably broken or malicious. Signed DNSSEC packets are quite a lot bigger that 512 bytes, and from 5 May all the DNS root servers will respond with signed DNSSEC answers.

The K-root server, operated by the RIPE NCC, is now serving the signed root zone as part of a staged global deployment of DNSSEC across the root zone system. Starting with L-root in January 2010, the root servers began serving the signed root zone in batches in the form of a Deliberately Unvalidatable Root Zone (DURZ). This roll out period is scheduled to end in May 2010 and ICANN is scheduled to sign the root zone with real keys and release the trust anchor after 1 July 2010.

More Info:

http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues

http://www.ripe.net/news/k-root-signed-dnssec.html

Cisco ASA probable issue with DNS packet size:

DNS inspection on the Cisco ASA in enabled by default. The default maximum packet size of DNS is 512 bytes (see below default configuration):

policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512

Any DNS packet length larger than 512 bytes will be dropped. Since DNSSEC packets will be greater than 512, I have a suspicion that it will be a problem with the Cisco ASA dropping the DNS packets. I have not tested it but in case you run into DNS problems with your network, it is an issue you will have to consider. Maybe the DNS packet length on the ASA inspection will have to be increased as shown below:

UPDATE:

Actually Cisco has released a fix suggestion for the above mentioned problem regarding the DNSSEC packet size. Cisco recommends the following configuration:

policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto

If EDNS is used, the above command will allow DNS replies up to the length specified in the OPT record.

Again, use the above with caution and maybe run a packet sniffer to verify the DNS packet size before implementing such a change.

There are different techniques and methods for maintaining accurate routing information, thus different types of routing protocols were invented over the years.

The following post is intended to offer you an overview of the different types of routing protocols currently available.

Distance Vector / Link State

The above terms refer to the algorithms that govern the exchange of routing information and the way the optimal path is identified.

Distance vector protocols exchange information previously incorporated in the device’s routing table. The routers know only their immediate neighbor (one hop away). The link-state algorithms on the other hand, exchange information regarding the status of the links in the whole network topology (they have a bigger picture of the network).

Distance vector protocols require less hardware resources, but are sensitive to the formation of routing loops. Link state protocols require more hardware resources but are more efficient and converge better.

The following are distance vector protocols: RIPv1, RIPv2, IGRP, EIGRP.
The following are link-state protocols: OSPF, IS-IS.

Classless / classful.

Classful protocols publish only the address information of the destination network, not the subnet mask, which forces the device receiving the update to assume that the subnet mask is the same as that on its interface, or the default mask that corresponds to the class.

Classless routing protocols however, advertise the subnet mask together with the network address, so the receiving router has full routing information. This allows the implementation of VLSM and CIDR.

Classful protocols: RIPv1, IGRP.
Classless Protocols: RIPv2, EIGRP, OSPF, IS-IS.

Internal Routing Protocols / External Routing Protocols.
The interior routing protocols (or IGP – Interior Gateway Protocols) are designed to operate within the same administrative domain, which means that each device is “confident” about the information received from others.

Exterior routing protocols (or EGP such as BGP), however, are used to manage routing between different administrative domains. In EGP, each administrative domain is independent. It has implemented its own routing policy.

Interior routing protocols: RIPv1, RIPv2, EIGRP, OSPF, IS-IS.
Exterior Routing Protocol: BGPv4.

In order for two Layer 3 devices (routers or layer 3 switches) to be able to exchange routing information, it is necessary to use the same routing protocol, such as RIP, EIGRP, OSPF, BGP, etc. Different routing protocols, or protocols configured differently (eg different EIGRP autonomous system) do not exchange information.

However, when a device learns routing information from different sources (eg static routes or using different protocols) Cisco IOS allows the information learned from a specific source to be published to other devices using a different protocol. For example, a route learned through RIP can be advertised to other devices using OSPF. This is what is called “redistribution” of routes: Using a routing protocol to advertise routes that are learned through other means (other protocol, static routes or directly connected). To configure route redistribution some rules must be in place:

• The redistributed route must be present in the routing table.
• The redistributed route will be received by the neighbouring device with a new metric as configured by the redistributing router.

What is it used for?

In principle it is desirable that a network should use a single routing protocol. However, in some cases we may require the use of redistribution: two companies merged, different departments of a company managed by different teams, multi-vendor environments, migration, etc. When addressing a redistribution of routes scenario we should take into account particular aspects of routing: different metrics, administrative distance of each protocol, the capabilities of classful and classless routing, and network topology.

Metrics

Each routing protocol uses a different metric. This causes the routes redistributed to lose the original metric of the protocol and the metric is redefined in terms of the new protocol. For example, if an OSPF route is redistributed with a metric of 1642 in RIP, RIP metric uses number of hops (between 1 and 15). So you must change the metric before redistributing to RIP.

The metric with which a protocol receives the routes learned by another metric is called seed metric.
Each protocol uses a default seed metric:

RIP – default seed metric: infinity.
EIGRP – default seed metric: infinity.
OSPF – default seed metric: 20.
The default seed metric can also be modified using the “default metric” command.

The basic commands
When you configure redistribution of protocols, you should indicate how to redistribute routing information, and how we want to measure these routes (metric) when they are redistributed. If we do not indicate anything, the routes are redistributed with the default metric.

Router (config) # router rip
Router (config-router) # network 129.100.0.0
Router (config-router) # redistribute ospf 1 metric 2

In this example we tell the router to redistribute routing information into RIP when learned through the OSPF process 1 which is in the routing table, with a metric of 2 hops.

Redistribution in EIGRP
To redistribute routing information into EIGRP, it should be noted that the default metric is infinite. Therefore, if you do not specify metric for redistributed routes, they will not appear in the routing table of the neighbouring device.

Furthermore, by defining the metric it should be noted: bandwidth, delay, reliability, load and MTU.

An example:

Router (config) # router eigrp 100
Router (config-router) # redistribute static
Router (config-router) # redistribute rip
Router (config-router) # default-metric 10000 100 255 1 1500

Redistribution in OSPF

The default metric used by OSPF is 20, so it does not require us to specify a metric for the route learned by the adjacent devices. However, when there are multiple subnets on the same network and you want to publish routes for each subnet, you must configure a metric otherwise OSPF will summarize all subnets in the class boundary and publish a single route.

An example:

Router (config) # router ospf 1
Router (config-router) # redistribute static metric 200 subnets
Router (config-router) # redistribute eigrp 100 metric 500 subnets

RIP redistribution

Like EIGRP, RIP redistributes the protocols using a default metric of infinity, so it is necessary to specify a different metric in order for the neighbour router to incorporate the routing information in its table.

An example:

Router (config) # router rip
Router (config-router) # redistribute static metric 1
Router (config-router) # redistribute ospf 1 metric 2

This was a message/invitation received from a friend of mine regarding the upcoming Cisco Expo 2010 event in Athens Greece. For people that happen to be in the area, it would be a fantastic event with four excellent demos as described below:

Four demos, which encapsulate the innovation of Cisco will have the opportunity to watch the visitors of Cisco Expo 2010.

The great celebration of innovation will be held on Tuesday and Wednesday, April 20-21, 2010.

• The Cisco TelePresence, Cisco’s leading solution that offers the experience of face-to-face communications and removes their geographical constraints on cooperation, will be available to all visitors of the Cisco Expo. Two demo-rooms will be located in the exhibition space and communicate with each another in real-time.

• A commercial retail space, equipped with all modern technology that can make businesses more competitive, will be set up in the exhibition space. The Cisco Expo visitors will have the opportunity to experience wireless networking, unified communications and digital signage combined into one comprehensive solution for commercial stores of the future.

• The Cisco EnergyWise, innovative solution for the management of energy in buildings and offices, will be presented on stage at an impressive demo simulating the workplace. The presentation is scheduled on Wednesday, April 21, at 15: 00, presented by Antonis Tsimpoykis, Cisco Borderless Architecture Leader, Med Region, with the collaboration of other skilled people from Cisco, which would come to Athens ’ only for this purpose.

• Cisco Expo Athens will also establish a unique demo in Digital Media for telecommunications service providers, which will be available both days of the event.

The Athens Cisco Expo 2010 will be held on 20 and 21 April 2010 in “THEATRON” – Greek World Culture Center, pireos254, in Athens.

Participation is free for all professionals in the information technology and telecommunications sectors. For registrations, you can visit the homepage www.ciscoexpo.gr