Tag: ietf

ISOC IETF session & Side conference at AFRINIC-25

AFRINIC-25 was held at Sofitel Imperial Resort & Spa in Mauritius this year from 25th to 30th of November 2016. Members of cyberstorm.mu were proud to be present during the ISOC IETF session. Logan, who is also a member of cyberstorm.mu introduced me to Kevin G. Chege of ISOC who was leading the meeting. There were several topics tossed on technical IETF standards at the workplace by Padma Pillay-Esnault of Huawei.

Photo Credits: Afrinic.net
Photo Credits: Afrinic.net

I made a short introduction on OpenSUSE as an OpenSUSE advocate and laid emphasis on the challenges of the OpenSUSE community in terms of code contribution. Also, a brief overview of the OpenSUSE infrastructure, the open build service, the visualization platform, and factory development at OpenSUSE.

One of the contributions made during the cyberstorm.mu hackathon – Operation SAD – Search and Destroy where codes were contributed to Monit – An opensource utility for proactive monitoring. It can conduct automatic maintenance and repair. What is most interesting during the hackathon is the deprecation of SSLv3 in Monit.

More details were shed on the spreading of the disease called SSLv3. There are many developers still importing Monit as secondary tools on their application. A live example where Github repos are infected with SSLv3 where the same need to be removed to mitigate attacks. The RFC 7568 (Thanks to the TLS working group) – which was applied during the course of the hackathon was taken as an example as well as the methodology and application of the SDLC – Software Development Life Cycle standards during the hackathon.

A slide during the IETF meeting

An open discussion among participants and audience was then carried out. The aim is to have each one to share their concerns and initiative to reach their goals. As regards to me, i laid emphasis that IETF materials should not only reach University students, but also other individuals who have the skills and know-how and ready to learn for the betterment of Africa and Mauritius. Hackathons were proposed to be carried out at international level under the umbrella of the IETF – Internet Engineering Task Force. 

I would also sincerely thank the ISOC, AFRINIC and sponsors for making this event a successful one.

Some pictures here:

afrinic-25

ISOC IETF session & Side conference at AFRINIC-25 1
ISOC IETF session & Side conference at AFRINIC-25 2
ISOC IETF session & Side conference at AFRINIC-25 3
ISOC IETF session & Side conference at AFRINIC-25 4
Loading image... Loading image... Loading image... Loading image...

Anatomy of a simple dig result

The ‘dig’ (Domain Information Gropper) command is one of the tools which is frequently used to troubleshoot DNS and BIND configurations. Its main purpose is to perform DNS lookups and query DNS servers. Though the subject is vast, I decided to blog some DNS stuff under the ‘Bind and DNS tools’ category which I just created. I will keep on updating this article as I keep on finding interesting dig commands.


Screenshot from 2015-11-08 15:45:52

Let’s analyze the result from a simple dig google.com. You would have a result similar to this one (In green). By default, dig perform query A record when launched without any arguments.

1. I made a dig google.com on my Linux terminal

[[email protected] ~]# dig google.com

2. The header section starts here. Several files in /etc/ld.so.* is being read and the dig command will also launch a uname with the argument sys and node. The uname is already inbuilt in the code of the dig command. It then reads the /etc/resolv.conf


; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.5 <<>> google.com

3. The ;; global options: +cmd is referred to the default arguments sets by dig to use only the +cmd variables.  The opcode value is always static. The status is to inform us if any error occurred during the query. Each query is also associated with an id number ( ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35133).

The flags qr (query response), rd (recursion desired) and ra (recursion available) are also information retrieved from the DNS header. As per the IETF RFC1035, when a dig with the default arguments is performed it will flag the qr, rd, ra and when the bit is 1 it’s a response and 0 for a query. Therefore ‘qr’ appears as 1

The ANSWER:2 is the numbers of answers received in the Answer section, same for QUERY, AUTHORITY and ADDITIONAL.


 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35133
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

4. The “question section” is what you are querying for. In this case, a ‘dig’ has been done on the A record. An A record simply means Adress i.e; the address associated with the website. We have several DNS records types which I will elaborate in future articles.

;; QUESTION SECTION:
 ;google.com.            IN    A

5. The number 173 is the TTL (Time To Live), IN refers to Internet i.e the class in which it is. TTL  is a 32 bit signed integer which corresponds to the time interval a record can be cached before the information is again queried. A TTL zero is used for extremely volatile data.

To resume we read it as follows: Google.com has a 173 seconds Time To Live on the Internet with the IP Address 74.125.226.168


;; ANSWER SECTION:
 google.com.        173    IN    A    74.125.226.168
 google.com.        173    IN    A    74.125.226.162

6. This section acts like a stat section. Information is given about the time it takes to query. The server IP address i.e; 4.2.2.1 and the port number 53 which is associated with it. The date and finally the message size received is 204 bytes.

;; Query time: 22 msec
 ;; SERVER: 4.2.2.1#53(4.2.2.1)
 ;; WHEN: Sun Nov 08 01:19:23 EST 2015
 ;; MSG SIZE  rcvd: 204

More analysis can be performed by launching a strace in front of a dig command. The RFC 1035 is also of great help. You can also check out the Internet System Consortium (ISC) website for more details.

Tips:

    • dig -t MX google.com will show you in the list of MX records in the ‘Answer Section’
    • A  dig result is composed of only 5 parts i.e; Header, Question (question for the name server), Answer (resource records answering the question ), Authority (resource records pointing towards an authority) and Additional (resource records holding additional information).
    • To filter information from a default dig command you can use dig google.com +nocomments +noauthority +noadditional +nostats which will give you only the answer. With an additional +noanswer won’t give you anything.
    • However, the reverse way to filter dig results with a specific answer can be dig google.com +noall +answer will give you only the answer section.
    • Another interesting tip from Keith Wright is to use recursion during the name resolution using the command dig +trace google.com.