Monday, May 30, 2011

BIND - Zone maintainance

 1.Vấn đề dự phòng

Một vấn đề xảy ra khi khi xây dựng một hệ thống DNS đó là khả năng dự phòng. Nếu trong domain chỉ có 1 DNS server hoạt động, khi server này gặp trục trặc, mọi host trong domain đều không thể truy vấn được thông tin về host mà nó cần.

Điều này dẫn đến việc thiết kế một DNS dự phòng mang tính backup cho server chính gọi là Secondary server. Server dự phòng này sẽ sao chép toàn bộ thông tin hiện tại của server chính, khi server chính có sự cố thì các truy vấn dns sẽ được gửi đến server phụ này

Việc DNS secondary server duy trì dữ liệu của server chính trên nó được gọi là zone maintainance. 

Quá trình sao chép dữ liệu này được gọi là zone transfer. 

2.Full zone transfer (AXFR)

Ban đầu khi xây dựng thống DNS, người ta đã thiết kế một kiểu zone transfer gọi là full zone transfer, tức là sẽ transfer toàn bộ thông tin cơ sở dữ liệu của dns server chính về cho server phụ. Việc này được thực hiện thông qua việc kiểm tra serial number của SOA Resource Record. Nếu serial number của server chính lớn hơn(mới hơn) thì server phụ sẽ yêu cầu server chính gửi toàn bộ thông tin về zone cho nó. Đây chính là full zone transfer. Thời gian các server phụ kiểm tra xem đã có sự thay đổi hay chưa đc định nghĩa bởi giá trị refresh của SOA RR.

AFXR hoạt động trên TCP port 53.

Chi tiết hơn về AXFR: http://cr.yp.to/djbdns/axfr-notes.html

3.Incremental zone transfer (IXFR)

FUll zone transfer bộc lộ một điểm yếu là nếu chỉ có 1 RR thay đổi thì việc full zone transfer là gây lãng phí cả về băng thông mạng và tốn nhiều thời gian. RFC 1995 đã đưa ra một giao thức cho phép chỉ transhfer những RR có sự thay đổi. 

Cách thức làm việc của IXFR khá giống với AXFR. Slave dns server gửi request đến master dns server mỗi lần hết giá trị refresh. Nếu serial number của SOA RR là mới hơn thì nó sẽ gửi yêu cầu xem có thể sử dụng IXFR hay không. Nếu cả slave và master server đều hỗ trợ IXFR thì sẽ sử dụng cách này để transfer zones. Nếu thất bại sẽ sử dụng AXFR. 

IXFR sử dụng TCP port 53

4.Thông điệp NOTIFY

 Giá trị refresh được định nghĩa trong SOA RR thường là vài giờ đồng hồ. Điều đó có nghĩa, nếu như có bất kỳ sự thay đổi nào từ master server thì slave server vẫn sẽ không biết được cho đến khi hết giá trị refresh đó.

RFC 1996 định nghĩa một cơ chế cho phép master server gửi một thông điệp NOTIFY đến các slave servers mỗi khi nó đc load hoặc đc cập nhật mới. Thông điệp NOTIFY này sẽ chỉ ra rằng, đã có một sự thay đổi nào đó đối với các RR. Các slave nhận đc thông điệp NOTIFY sẽ gửi đến master server yêu cầu kiểm tra SOA RR. Nếu serial number lớn hơn so với serial hiện tại, slave server sẽ đưa ra yêu cầu là AXFR hoặc IXFR.

Friday, May 27, 2011

Cài đặt GNS3 trên Ubuntu và Fedora

Dưới đây là một blog rất hữu ích, có đầy đủ các tut nói về việc sử dụng các soft gỉa lập để học Cisco.
Các bài viết khá dễ hiểu và rất chi tiết. Ai cần có thể tham khảo bài viết "How to install GNS3 on Ubuntu 10.04 LTS" tại link này:
http://networkingtips-tricks.blogspot.com/2010/09/how-to-install-gns3-on-ubuntu-1004-lts.html

Còn đây là bài viết hướng dẫn cài đặt GNS3 trên Fedora:
http://networkingtips-tricks.blogspot.com/2010/08/tutorial-how-to-install-gns3-on.html

Sunday, May 8, 2011

Packet Tracer for Linux

Đây là bản PT dành cho Linux, hiện tại tôi đã download bản rpm dành cho Fedora về và cài đặt dùng thử. Nói chung là cũng khá tốt, tương tự như PT trên Windows. Tôi mới thử cài đặt trên Fedora của mình, chưa thử trên các distro khác nên không biết có gặp vấn đề gì không. Nếu ai đang sử dụng Fedora thì có thể download bản mà tôi đã upload lên Mediafire:

http://www.mediafire.com/?oyasvs1fyiihwua

Nếu bạn là người dùng Ubuntu, bạn có thể tham khảo link này:

http://www.packettracer.info/packet-tracer-5-3-2-download.html
-Cài đặt (Fedora)
Việc cài đặt khá dễ dàng.

  • _Chmod cho file .bin vừa download về có quyền execute
  • _run file .bin mới chmod xong dưới quyền root trong terminal
  • _đọc instruction và làm theo hướng dẫn.
  • _done