KEMBAR78
DNS Domain Name System Dig | PDF | Computer Law | Computer Networking
0% found this document useful (0 votes)
131 views3 pages

DNS Domain Name System Dig

dig +trace uses the local resolver to look up the IP addresses of intermediate nameservers beyond the initial root nameservers, even though the command output does not indicate this. This means it relies on the accuracy of the local resolver cache and could provide incorrect results if the cache contains inaccurate nameserver IP addresses.

Uploaded by

rcsrcs
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
131 views3 pages

DNS Domain Name System Dig

dig +trace uses the local resolver to look up the IP addresses of intermediate nameservers beyond the initial root nameservers, even though the command output does not indicate this. This means it relies on the accuracy of the local resolver cache and could provide incorrect results if the cache contains inaccurate nameserver IP addresses.

Uploaded by

rcsrcs
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

2/7/2017 domain name system - Is dig +trace always accurate?

- Server Fault

signup login tour help

_
ServerFaultisaquestionandanswer Here'showitworks:
siteforsystemandnetwork
administrators.Jointhemitonlytakesa
minute:

Signup Anybodycanask Anybodycan Thebestanswersarevoted


aquestion answer upandrisetothetop

Isdig+tracealwaysaccurate?

WhentheaccuracyofaDNScacheisinquestion, dig+trace tendstobetherecommendedwayofdeterminingtheauthoritativeanswerfor


aninternetfacingDNSrecord.Thisseemstobeparticularlyusefulwhenalsopairedwith +additional ,whichalsoshowsthegluerecords.

OccasionallythereseemstobesomedisagreementonthispointsomepeoplesaythatitreliesonthelocalresolvertolookuptheIP
addressesoftheintermediatenameservers,butthecommandoutputoffersnoindicationthatthisishappeningbeyondtheinitiallistofroot
nameservers.Itseemslogicaltoassumethatthiswouldn'tbethecaseifthepurposeof +trace istostartattherootserversandtraceyour
waydown.(atleastifyouhavetherightlistofrootnameservers)

Does dig+trace reallyusethelocalresolverforanythingpasttherootnameservers?

domainnamesystem nameserver dig gluerecord

editedAug18'13at1:22 askedFeb27'13at7:51
AndrewB
19.7k 5 55 91

2Answers

ThisisobviouslyastagedQ&A,butthistendstoconfusepeopleoftenandIcan'tfinda
canonicalquestioncoveringthetopic.

dig+trace isagreatdiagnostictool,butoneaspectofitsdesigniswidelymisunderstood:the
IPofeveryserverthatwillbequeriedisobtainedfromyourresolverlibrary.Thisisveryeasily
overlookedandoftenonlyendsupbecomingaproblemwhenyourlocalcachehasthewrong
answerforanameservercached.

DetailedAnalysis

ThisiseasiertobreakdownwithasampleoftheoutputI'llomiteverythingpastthefirstNS
delegation.

;<<>>DiG9.7.3<<>>+trace+additionalserverfault.com

;;globaloptions:+cmd
.121459INNSd.rootservers.net.
.121459INNSe.rootservers.net.
.121459INNSf.rootservers.net.
.121459INNSg.rootservers.net.
.121459INNSh.rootservers.net.
.121459INNSi.rootservers.net.
.121459INNSj.rootservers.net.
.121459INNSk.rootservers.net.
.121459INNSl.rootservers.net.
.121459INNSm.rootservers.net.
.121459INNSa.rootservers.net.
.121459INNSb.rootservers.net.
.121459INNSc.rootservers.net.
e.rootservers.net.354907INA192.203.230.10
f.rootservers.net.100300INA192.5.5.241
f.rootservers.net.123073INAAAA2001:500:2f::f
g.rootservers.net.354527INA192.112.36.4
h.rootservers.net.354295INA128.63.2.53
h.rootservers.net.108245INAAAA2001:500:1::803f:235
i.rootservers.net.355208INA192.36.148.17
i.rootservers.net.542090INAAAA2001:7fe::53
j.rootservers.net.354526INA192.58.128.30
j.rootservers.net.488036INAAAA2001:503:c27::2:30
k.rootservers.net.354968INA193.0.14.129
k.rootservers.net.431621INAAAA2001:7fd::1
l.rootservers.net.354295INA199.7.83.42
;;Received496bytesfrom75.75.75.75#53(75.75.75.75)in10ms

com.172800INNSm.gtldservers.net.
com.172800INNSk.gtldservers.net.
com.172800INNSf.gtldservers.net.
com.172800INNSg.gtldservers.net.
com.172800INNSb.gtldservers.net.
com.172800INNSe.gtldservers.net.
com.172800INNSj.gtldservers.net.

http://serverfault.com/questions/482913/is-dig-trace-always-accurate 1/3
2/7/2017 domain name system - Is dig +trace always accurate? - Server Fault
com.172800INNSc.gtldservers.net.
com.172800INNSl.gtldservers.net.
com.172800INNSd.gtldservers.net.
com.172800INNSi.gtldservers.net.
com.172800INNSh.gtldservers.net.
com.172800INNSa.gtldservers.net.
a.gtldservers.net.172800INA192.5.6.30
a.gtldservers.net.172800INAAAA2001:503:a83e::2:30
b.gtldservers.net.172800INA192.33.14.30
b.gtldservers.net.172800INAAAA2001:503:231d::2:30
c.gtldservers.net.172800INA192.26.92.30
d.gtldservers.net.172800INA192.31.80.30
e.gtldservers.net.172800INA192.12.94.30
f.gtldservers.net.172800INA192.35.51.30
g.gtldservers.net.172800INA192.42.93.30
h.gtldservers.net.172800INA192.54.112.30
i.gtldservers.net.172800INA192.43.172.30
j.gtldservers.net.172800INA192.48.79.30
k.gtldservers.net.172800INA192.52.178.30
l.gtldservers.net.172800INA192.41.162.30
;;Received505bytesfrom192.203.230.10#53(e.rootservers.net)in13ms

Theinitialqueryfor .INNS (rootnameservers)hitsthelocalresolver,whichinthiscase


isComcast.( 75.75.75.75 )Thisiseasytospot.
Thenextqueryisfor serverfault.com.INA andrunsagainst e.rootservers.net. ,
randomlyselectedfromthelistofrootnameserverswejustgot.IthasanIPaddressof
192.203.230.10 ,andsincewehave +additional enableditappearstobecomingfromthe
glue.
Sinceitisnotauthoritativeforserverfault.com,thisgetsdelegatedtothe com. TLD
nameservers.
Whatisn'tobviousfromtheoutputhereisthat dig didnotderivetheIPaddressof
e.rootservers.net. fromtheglue.

Inthebackground,thisiswhatreallyhappened:

tcpdump:verboseoutputsuppressed,usevorvvforfullprotocoldecode
listeningoneth1,linktypeEN10MB(Ethernet),capturesize65535bytes
02:03:43.301022IP192.0.2.1.59900>75.75.75.75.53:63418NS?.(17)
02:03:43.327327IP75.75.75.75.53>192.0.2.1.59900:6341813/0/14NSk.rootservers.net.,
NSl.rootservers.net.,NSm.rootservers.net.,NSa.rootservers.net.,NSb.root
servers.net.,NSc.rootservers.net.,NSd.rootservers.net.,NSe.rootservers.net.,NS
f.rootservers.net.,NSg.rootservers.net.,NSh.rootservers.net.,NSi.root
servers.net.,NSj.rootservers.net.(512)
02:03:43.333047IP192.0.2.1.33120>75.75.75.75.53:41110+A?e.rootservers.net.(36)
02:03:43.333096IP192.0.2.1.33120>75.75.75.75.53:5696+AAAA?e.rootservers.net.(36)
02:03:43.344301IP75.75.75.75.53>192.0.2.1.33120:411101/0/0A192.203.230.10(52)
02:03:43.344348IP75.75.75.75.53>192.0.2.1.33120:56960/1/0(96)
02:03:43.344723IP192.0.2.1.37085>192.203.230.10.53:28583A?serverfault.com.(33)
02:03:43.423299IP192.203.230.10.53>192.0.2.1.37085:285830/13/14(493)

+trace cheatedandconsultedthelocalresolvertoobtaintheIPaddressofthenexthop
nameserverinsteadofconsultingtheglue.Sneaky!

Thisisusually"goodenough"andwon'tcauseaproblemformostpeople.Unfortunately,there
areedgecases.IfforwhateverreasonyourupstreamDNScacheisprovidingthewrong
answerforthenameserver,thismodelbreaksdownentirely.

Realworldexample:

domainexpires
glueisrepointedatregistrarredirectionnameservers
bogusIPsarecachedforns1andns2.yourdomain.com
domainisrenewedwithrestoredglue
anycacheswiththebogusnameserverIPscontinuetosendpeopletoawebsitethatsays
thedomainisforsale

Intheabovecase, +trace willsuggestthatthedomainowner'sownnameserversarethe


sourceoftheproblem,andyou'reonecallawayfromincorrectlytellingacustomerthattheir
serversaremisconfigured.Whetherit'ssomethingyoucan(orarewillingto)dosomething
aboutisanotherstory,butit'simportanttohavetherightinformation.

dig+trace isagreattool,butlikeanytool,youneedtoknowwhatitdoesanddoesn'tdo,and
howtotroubleshoottheissuemanuallywhenitprovesinsufficient.

Edit:

Itshouldalsobenotedthat dig+trace willnotwarnyouabout NS recordsthatpointat


CNAME aliases.ThisisaRFCviolationthatISCBIND(andpossiblyothers)willnotattemptto
correct. +trace willbecompletelyhappytoacceptthe A recorditgetsfromyourlocally
configurednameserver,whereasifBINDweretobeperformingfullrecursionitwouldbe
rejectingtheentirezonewithaSERVFAIL.

ThiscanbetrickytotroubleshootifglueispresentthiswillworkjustfineuntiltheNSrecords
arerefreshed,thensuddenlybreak.GluelessdelegationswillalwaysbreakBIND'srecursion
whena NS recordpointsatanalias.

http://serverfault.com/questions/482913/is-dig-trace-always-accurate 2/3
2/7/2017 domain name system - Is dig +trace always accurate? - Server Fault
editedNov1'15at16:31 answeredFeb27'13at7:51
AndrewB
19.7k 5 55 91

Whatabout +nssearch ?vonbrandFeb27'13at13:14

@vonbrand +nssearch performsa NS recordlookupagainstyourlocalresolverfortherequestedrecord,


followedbyaseriesof A / AAAA lookupsagainstthelocalresolverforeachofthereturnednameservers.
It'slikewisesusceptibletobogusnameserverrecordsincache. AndrewB Feb27'13at16:50

1 Sowhat'sthesolution?Use"dig...@server"andfollowthedelegationmanually?RamanSep19'15at
0:12

@RamanYes,it'seitherthatoryouhavetoemptythecacheofarecursiveserverthatyouhavehandy,
makethequery,anddumpthecache.(whichdefeatstheideaofalightweightclient)digisdoingthisto
exponentiallyreducethenumberofqueriesrequired. AndrewB Sep19'15at0:19

AnotherwayoftracingDNSresolutionwithoutusingthelocalresolverforanythingexcept
findingtherootnameservers,isusingdnsgraph(Fulldisclosure:Iwrotethis).Ithasa
commandlinetoolandawebversion,ofwhichyoucanfindaninstanceat
http://ip.seveas.net/dnsgraph/

Exampleforserverfault.com,whichactuallyhasaDNSproblemrightnow:

answeredApr27'14at10:02
DennisKaarsemaker
14.1k 27 59

3 Thestuffypedantinmewantstosaythatthistechnicallyisn'tananswer.TheDNSadmininmethinksit's
awesomeandtotallydoesn'tcare. AndrewB Apr27'14at10:37

Iwasgoingtopostitasacomment,butwantedtoincludetheimage.Feelfreetomergeitintoyouranswer
ifyouthinkthat'sbetter.DennisKaarsemakerApr27'14at10:41

1 I'mfinewiththingsastheyare.IfamodfeelsotherwiseI'llconsolidatethough,sure. AndrewB Apr27


'14at17:48

http://serverfault.com/questions/482913/is-dig-trace-always-accurate 3/3

You might also like