DNS og det er bits og bytes

I løpet av de siste to artiklene vi har dekket DNS på et relativt høyt nivå. Vi fikk ikke gå i dybden av noen systemadministrasjon innhold egentlig, men konsentrert seg mer om å få en solid følelse for hva protokollen gjør, og hvordan den gjør det. Til slutt har vi også tok en titt på hvordan en DNS-pakke ser ut på ledningen som det var. I denne siste delen av DNS artikkelserien vil vi ta en DNS pakke og gå gjennom DNS spissen. Dette vil tillate deg å forhåpentligvis bedre forstå protokoll selv, og hvordan det fungerer. Du kan føle at du går gjennom DNS pakke, hex verdi av hex verdi, som uviktig.

Mine følelser om saken er at det å være i stand til å fullstendig analysere pakken vil gi deg en følelse av trygghet når du arbeider med DNS. Dette i sin tur vil tillate deg å nærme seg noe nettverk relatert problem som involverer DNS med selvsikkerhet. Den slags selvsikkerhet vil bare komme fra å ha en forståelse av ikke bare hvordan protokollen selv fungerer, men også hvordan det ser ut i en pakke format.

Lar plukke denne pakken fra hverandre!

Vel, før vi begynner å plukke under bemerket pakke fra hverandre, må du sørge for at du har den SANS TCP /IP og tcpdump flyer plassert nederst siden. Dette vil tillate deg å navigere DNS pakke med et minimum av innsats. Jeg vil nå kommentere pakken direkte under den.

01: 00: 09,684739 192.168.1.200.53 > 192.168.1.100.616: [udp sum ok] 59930 NXDOMAIN
0/1/0 (102) (ttl 58, id 55787, len 130)
0x0000 4 5
00 0082 d9eb 0000 3a11 f873 c0a8 01c8 E .......:. .. s..e
0x0010 c0a8 0164
0035
0268 006e ba41
ea1a 8183 ..... 5.hnA ...
0x0020 0001 0000 0001 0000 0133 0234 3503 3139 ......... 3.45.19
0x0030 3103 3230 3605 646e 7362 6c05 736f 7262 1.206.dnsbl.sorb
0x0040 7303 6e65 7400 0001 0001 c019 0006 0001 s.net ...........
0x0050 0000 0e10 002c 0772 626c 646e 7330 c01f .....,. rbldns0 ..
0x0060 0364 6e73 0469 7375 7803 636f 6d00 431c .dns.isux.com.C
0x0070 e07e 0000 1c20 0000 1c20 0009 3a80 0000 ~ ............. ..
0x0080 0e10 ..

Som et oppfrisknings jeg vil raskt gå gjennom alle feltene med start fra første linje og jobbe meg gjennom å gå fra høyre til venstre. Den første linjen har tid stempel, som er den tiden at målmaskinen 192.168.1.100 mottatt denne DNS-pakke på.

Neste vi har kilden IP-adresse og kildeport dvs: 192.168.1.200.53 fulgt av regissøren tegn, noe som betyr flyt av samtalen som det var. Etter at vi da har målet IP-adresse og destinasjon port.

Nå har vi [UDP summen ok] betegner at UDP sjekksum er korrekt. Etter det har vi DNS transaksjonen antall 59930. Dette er, som nevnt tidligere, brukes til å holde styr på DNS-spørringer og tiltak av opphavsspørringen.

Neste ser vi RCODE av NXDOMAIN og det betyr at domenet som oppløsning ble forespurt for ikke eksisterer. Etter at er tallene 0/1/0 og de mener at det er null svar poster, en autoritativ posten, og null ekstra poster i denne pakken.

Etter at vi har verdien av 102 i parentes. Det er mengden av DNS-data i dette pakke. Neste er TTL-verdi på 58, en IP-ID-verdi på 55 787, og til slutt den totale pakkelengde på 130. Det er viktig å huske på at «len 130" felt, som vist i den ovenfor angitte pakke refererer til den totale pakkestørrelse, og som inkluderer både protokoll overskrifter, og data hvis det finnes.

Vi vil ikke bry å gå gjennom hex verdier nedenfor som representerer IP og UDP header, men heller gå videre til DNS header og data. Nok en gang en rask måte å navigere til viktige punkter i pakken er å gjøre følgende.

Vi vet at vår IP header vil ende på bytes "0164" som understreket på linje 0x0010. Vi vet også at det ikke er noen IP valg på grunn av halv-byte verdi av fem som understreket på linje 0x0000. På grunn av dette har vi da vet at UDP header starter kl bytes "0035" og ende med bytes "ba41". Så fra dette kan vi konstatere at våre DNS header vil begynne på byte "ea" som understreket på linje 0x0010.

Med det ute av veien vi vil nå bryte ut DNS header verdier. Hvis du sjekker din TCP /IP og tcpdump flyer som du lastet ned vil du merke at det første feltet i DNS header knyttet til ID-nummer. Dette feltet er tilordnet to byte eller 16 biter. Du må skrive ut en liten oversikt som vist nedenfor.

| 32768 | 16384 | 8192 | 4096 | 2048 | 1024 | 512 | 256 | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |

Det vi nå må gjøre er å ta de to bytes representert ved tegn "ea1a" og legge dem inn i en kalkulator, som vil utføre hex til desimal konverteringer. Du vil merke at når du konvertere "ea1a" til desimal at du faktisk komme opp med verdien av 59 930 i pakken ovenfor. Så langt så bra, matcher DNS rekordmange.

Nå vil vi se at de neste verdiene som nevnt på våre SANS jukse ark har en rekke forskjellige betydninger. Så langt har vi sett det meste verdier reflekteres i en overskrift som bryter pent enten på napp (halvparten av en byte eller fire biter) eller en full byte eller bytes. Vel i DNS har vi flere verdier som finnes i en byte. Det er derfor vi trenger diagrammet vist ovenfor.

Vi må ta verdien av de to bytes "8183" og konvertere det til et desimaltall. Fra den desimaltall vil vi være i stand til å bestemme hvilke verdier som er satt, og som ikke er. Vel 8183 i hex eller som det skal skrives 0x8183 bryter ut til 33155 i desimal.

Ved hjelp av tabellen ovenfor som nevnt vi begynner å dele 33155 av verdiene som er tildelt to byte felt, som inneholder verdiene på jukselapp ie: QR, Opcode, og så videre. Så vi vet da at den første plasseringen av 32 768 er satt, så vi vet at dette er et svar, vice en spørring. Etter å ha trukket 33 155 fra 32 768 vi har en rest på 387.

Vi trekker nå 387 fra neste nærmeste passform. I dette tilfellet ville det være 256. Så det Verdien settes også, som forteller oss at "Rekursjon Ønsket", eller RD-feltet er satt. Nå har vi en rest på 131. Dette vi trekker fra 128 på figuren ovenfor, som forteller oss at "Rekursjon Tilgjengelig" -feltet er satt. Det etterlater oss nå med en rest på 3.

Her er den vanskelige delen. Du må ta denne desimal verdi på 3 og se på "Response code" -feltet sett på SANS jukse ark, under DNS spissen. Du vil se at en desimal verdi av tre gjenspeiler at den "Ikke-eksisterende domene" eller NXDOMAIN RCODE er innstilt. Vi kan se at det er i overskriften til denne pakken, som dokumentert av NXDOMAIN understreket.

Etter disse verdiene er det bare et spørsmål om å bruke samme logikk til resten av verdiene i DNS spissen. Som du kan se er det ikke mye vanskeligere deretter bryte ut de vanlige TCP /IP-pakker som vi har gjort før. Det var bare litt mer forvirrende som vi nå ser på applikasjonslaget data også nå. Du har nå analysert en DNS-pakke. Det er en ferdighet ikke veldig mange mennesker har! På dette notatet vil jeg bryte opp denne tredelt artikkelserie om DNS, og håper inderlig at det var nyttig for deg. Jeg alltid velkommen kommentarer, så kan du gjerne skrive meg. Til neste gang!