12/2/2016 Chapter2DNSConcepts

2.DNSConcepts
IfyoualreadyunderstandwhatDNSisanddoesandhowitfitsintothe
greaterschemeofthingsskipthischapter.

2.1AbriefHistoryofNameServers
2.2DNSConcepts&Implementation
2.2.1DNSOverview
2.2.2DomainsandDelegation
2.2.3DNSOrganizationandStructure
2.2.4DNSSystemComponents
2.2.5ZonesandZoneFiles
2.2.6DNSQueries
2.2.6.1RecursiveQueries
2.2.6.2IterativeQueries
2.2.6.3InverseQueries
2.2.7ZoneUpdates
2.2.7.1FullZoneTransfer(AXFR)
2.2.7.2IncrementalZoneTransfer(IXFR)
2.2.7.3Notify(NOTIFY)
2.2.7.4DynamicZoneUpdates
2.2.7.5AlternativeDynamicDNSApproaches
2.3DNSSecurityOverview
2.3.1SecurityThreats
2.3.2SecurityTypes
2.3.3LocalSecurity
2.3.4ServerServer(TSIGTransactions)
2.3.5ServerClient(DNSSEC)

2.1AbriefHistoryofNameServers

..orwhydowehaveDNSservers

WithoutaNameServicetherewouldsimplynotbeaviableInternet.To
understandwhy,weneedtolookatwhatDNSdoesandhowandwhyit
evolved.

1.ADNStranslates(ormaps)thenameofaresourcetoitsphysicalIP
addresstypicallyreferredtoasforwardmapping

2.ADNScanalsotranslatethephysicalIPaddresstothenameofa
resourcetypicallycalledreversemapping.

Bigdeal.

RememberthattheInternet(oranynetworkforthatmatter)worksby
allocatingeverypoint(host,server,router,interfaceetc.)aphysicalIP
address(whichmaybelocallyuniqueorgloballyunique).

http://www.zytrax.com/books/dns/ch2/ 1/22
12/2/2016 Chapter2DNSConcepts

SeparationofChurchandState.....

WithoutDNSeveryhost(PC)whichwantedtoaccessaresourceonthe
network(Internet),sayasimplewebpage,forexample,www.thing.com,
wouldneedtoknowitsphysicalIPaddress.With100ofmillionsof
hostsandbillionsofwebpagesitisanimpossibletaskit'salsopretty
dauntingevenwithjustahandfulofhostsandresources.

TosolvethisproblemtheconceptofNameServerswascreatedinthe
mid70'stoenablecertainattributes(properties)ofanamedresource
tobemaintainedinaknownlocationtheNameServer.

WithaNameServerpresentinthenetworkanyhostonlyneedstoknow
thephysicaladdressofaNameServerandthenameoftheresource
itwishestoaccess.Usingthisdataitcanfindtheaddress(oranyother
storedattributeorproperty)oftheresourcebyinterrogating(querying)
theNameServer.Resourcescanbeadded,moved,changedordeletedat
asinglelocationtheNameServer.Atastrokenetworkmanagement
wassimplifiedandmademoredynamic.

Ifit'sbroke....

WenowhaveanewproblemwithournewlycreatedNameServer
concept.IfourNameServerisnotworkingourhostcannotaccessany
resourceonthenetwork.WehavemadetheNameServeracritical
resource.SowehadbetterhavemorethanoneNameServerincaseof
failure.

TofixthisproblemtheconceptofPrimaryandSecondaryNameServers
(manysystemsallowtertiaryormoreNameServers)wasborn.Ifthe
PrimaryNameServerdoesnotrespondahostcanusetheSecondary(or
tertiaryetc.).

Man,wegotmorenamesthanWebster....

AsournetworkgrowswestarttobuildupaseriousnumberofNamesin
ourNameServer(database).Thisgivesrisetothreenewproblems.

1.Findinganyentryinthedatabaseofnamesbecomesincreasingly
slowaswepowerthroughmanymillionsofnameslookingforthe
onewewant.Weneedawaytoindexororganizethenames.

2.IfeveryhostisaccessingourNameServerstheloadbecomesvery
high.Maybeweneedawaytospreadtheloadacrossanumberof
servers.

3.WithmanyName(resource)recordsinourdatabasethe
managementproblembecomesincreasinglydifficultaseveryone
triestoupdatealltherecordsatthesametime.Maybeweneeda
waytoseparate(ordelegate)theadministrationoftheseName
(resource)records.

http://www.zytrax.com/books/dns/ch2/ 2/22
12/2/2016 Chapter2DNSConcepts

WhichleadsusnicelyintothecharacteristicsoftheInternet'sDomain
NameSystem(DNS).

2.2DNSConcepts&Implementation

TheInternet'sDomainNameService(DNS)isjustaspecific
implementationoftheNameServerconceptoptimizedfortheprevailing
conditionsontheInternet.

2.2.1DNSOverview

FromourbriefhistoryofNameServerswesawhowthreeneeds
emerged:

1.Theneedforahierarchyofnames

2.Theneedtospreadtheoperationalloadsonournameservers

3.TheneedtodelegatetheadministrationofourNameservers

TheInternetDomainNameSystemelegantlysolvesalltheseproblemsat
thesinglestrokeofapen(wellactuallythewholeofRFC1034tobe
precise).

2.2.2DomainsandDelegation

TheDomainNameSystemusesatree(orhierarchical)namestructure.
AtthetopofthetreeistherootfollowedbytheTopLevelDomains
(TLDs)thenthedomainnameandanynumberoflowerlevelseach
separatedwithadot.

NOTE:Therootofthetreeisrepresentedmostofthetimeasasilentdot
('.')buttherearetimesasweshallseelaterwhenitveryimportant.

TopLevelDomains(TLDs)aresplitintotwotypes:

1.GenericTopLevelDomains(gTLD).com,.edu,.net,.org,.miletc.

2.CountryCodeTopLevelDomain(ccTLD)e.g..us,.ca,.tv,.uketc.

CountryCodeTLDs(ccTLDs)useastandardtwolettersequencedefined
byISO3166.Since2004gTLDsnowhaveasubcategoryknownas
sTLDs(SponsoredTLDs)whichimpliestheyhavelimitedregistration,
examplesofsTLDsinclude.aero,.museum,.travel,and.jobswhereasthe
normalgTLDstypicallyhaveopenregistrationrequirements.

Finally,since2011theTLDpolicyisessentiallyunrestricted,ifyoupay
enoughmoneyandadopttheoperatingprocedureslaiddownanyonecan
registerasponsoredTLD.LookforwardtoawholesetofnewTLDslike
.singles,.kitchenand.constructionarriving.

http://www.zytrax.com/books/dns/ch2/ 3/22
12/2/2016 Chapter2DNSConcepts

Figure11showsthisdiagrammatically.

Figure11DomainStructureandDelegation

WhatiscommonlycalledaDomainNameisactuallyacombinationofa
domainnameandaTLDandiswrittenfromLEFTtoRIGHTwiththe
lowestlevelinthehierarchyontheleftandthehighestlevelontheright.

domainname.tld#example.com

InthecaseofthegTLDs,suchas.com,.netetc.,theuserpartofthe
delegatednamethenametheuserregisteredisaSecondLevel
Domain(SLD).Itisthesecondlevelinthehierarchy.Theuserpartis
thereforefrequentlysimplyreferredtoastheSLD.SothetheDomain
Nameintheexampleabovecanberedefinedtoconsistof:

sld.tld#example.com

ThetermSecondLevelDomain(SLD)ismuchlessusefulwithccTLDs
wheretheuserregisteredpartistypicallytheThirdLevelDomain,for
example:

example.co.uk
example.com.br

ThetermSecondLevelDomain(SLD)providestechnicalprecisionbutcan
beconfusingwhenappliedtoagenericconceptlikeauserdomain
unlesstheprecisionisrequiredwewillcontinuetousethegenericterm
DomainNameorsimplyDomaintodescribethewholename,for
instance,whatthisguidecallsaDomainNamewouldbeexample.com
orexample.co.uk.

AuthorityandDelegation

TheconceptsofDelegationandAuthoritylieatthecoreofthedomain
namesystemhierarchy.TheAuthorityfortherootdomainlieswith
http://www.zytrax.com/books/dns/ch2/ 4/22
12/2/2016 Chapter2DNSConcepts

InternetCorporationforAssignedNumbersandNames(ICANN).Since
1998ICANN,anonprofitorganisation,hasassumedthisresponsibility
fromtheUSgovernment.

ThegTLDsareauthoritativelyadministeredbyICANNanddelegatedto
aseriesofaccreditedregistrars.TheccTLDsaredelegatedtothe
individualcountriesforadministrationpurposes.Figure1.0aboveshows
howanyauthoritymayinturndelegatetolowerlevelsinthehierarchy,in
otherwordsitmaydelegateanythingforwhichitisauthoritative.Each
layerinthehierarchymaydelegatetheauthoritativecontroltothe
nextlowerlevel.

InthecaseofccTLDscountrieslikeCanada(ccTLD.ca)andtheUS
(ccTLD.us)andotherswithfederalgovernmentsdecidedthattheywould
administeratthenationallevelanddelegatetoeachprovince(Canada)
orstate(US)atwocharacterprovince/statecode,forexample,.qc=
Quebec,.ny=NewYork,md=Marylandetc..Thusmycompany.md.us
wouldbetheDomainNameofmycompanywhichwasdelegatedfrom
thestateofMaryLandintheUS.Thiswasthedelegationmodeluntil
around2006whenbothcountrieschangedtheirregistrationpoliciesand
adoptedanessentiallyflatdelegationmodel.Thus,todayyoucanregister
mycompany.usormycompany.ca(aslongastheyareavailable).Theold
delegationmodelsarestillvalidandyoustilldomainssuchas
quebec.qc.caaswellasnumerousotherexamplesofthemultilayer
delegationmodel.

Countrieswithmorecentralizedgovernments,liketheUK,Braziland
Spainandothers,haveoptedforfunctionalsegmentationintheir
delegationmodels,forexample,.co=company,.ac=academicetc..
Thusmycompany.co.ukistheDomainNameofmycompany
registeredasacompanyfromtheUKregistrationauthority.

Delegationwithinanydomainmaybealmostlimitlessandisdecidedby
thedelegatedauthority,forexample,theUSandCanadaboth
delegatecitywithinprovince/statedomainsthustheaddress(orURL)
tennisshoes.nb.usisthetownofTennisShoesintheStateofNebraska
intheUnitedStatesandwecouldevenhave
mycompany.tennisshoes.nb.us.

ByreadingadomainnamefromRIGHTtoLEFTyoucantrackits
delegation.Thisunitofdelegationcanalsobereferredtoasazonein
standardsdocumentation.

SoWhatiswww.example.com

Fromourreadingabovewecanseethatwww.example.comisbuiltup
fromwwwandexample.com.TheDomainNameexample.compart
wasdelegatedfromagTLDregistrarwhichinturnwasdelegatedfrom
ICANN.

Thewwwpartwaschosenbytheownerofthedomainsincetheyare
nowthedelegatedauthorityfortheexample.comname.Theyown
http://www.zytrax.com/books/dns/ch2/ 5/22
12/2/2016 Chapter2DNSConcepts

EVERYTHINGtotheLEFTofthedelegatedDomainName.

Theleftmostpart,wwwinthiscase,iscalledahostname.By
convention(butonlyconvention)websiteshavethe'host'nameofwww
(forworldwideweb)butyoucanhaveawebsitewhosenameis
fred.example.comnoonemaythinkoftypingthisintotheirbrowserbut
thatdoesnotstopyoudoingit!Equallyyoumayhaveawebsitewhose
accessaddress(URL)iswww.example.comrunningonaserverwhose
realnameismary.example.com.Againthisisperfectlypermissable.In
shortthehostpartmayrefertoarealhostnameoraservicenamesuch
aswww.Sincethedomainownercontrolsthisprocessit'sallallowed.

Everycomputer,orservice,thatisaddressable(hasaURL)viathe
Internetoraninternalnetworkhasahostnamepart,herearesome
moreillustrativeexamples:

www.example.comthecompanywebservice
ftp.example.comthecompanyfiletransferprotocol
server
pc17.example.comanormalPCorhost
accounting.example.comanaccountingsystem

AhostnamepartmustbeuniquewithintheDomainNamebutcanbe
anythingtheownerofexample.comwants.

Finallyletslookatthisname:

www.us.example.com

FromourpreviousreadingwefigureitsDomainNameisexample.com,
wwwprobablyindicatesawebsite,whichleavestheuspart.

Theuspartwasallocatedbytheownerofexample.com(theyare
authoritative)andiscalledasubdomain.Inthiscasethedelegated
authorityforexample.comhasdecidedthattheircompanyorganization
isbestservedbyacountrybasedsubdomainstructure.Theycouldhave
delegatedtheresponsibilityinternallytotheUSsubsidiaryfor
administrationofthissubdomain,whichmayinturnhavecreatedaplant
basedstructure,suchas,www.cleveland.us.example.comwhichcould
indicatethewebsiteoftheClevelandplantintheUSorganisationof
example.com.

TosummarisetheOWNERcandelegate,INANYWAYTHEYWANT,
ANYTHINGtotheLEFToftheDomainNametheyown(weredelegated).
TheownerisalsoRESPONSIBLEforadministeringthisdelegationwhich
meansrunning,ordelegatingthetaskofrunning,aDNScontaining
Authoritativeinformation(orrecords)fortheirDomainName(orzone).

Note:Namessuchaswww.example.comandwww.us.example.comarecommonlybut
erroneouslyreferredtoasFullyQualifiedDomainNames(FQDN).TechnicallyanFQDN
unambiguouslydefinesanamefromanystartingpointtotherootandassuchmust

http://www.zytrax.com/books/dns/ch2/ 6/22
12/2/2016 Chapter2DNSConcepts

containthenormallysilentdotattheend.Toillustrate"www.example.com."isanFQDN
"www.example.com"isnot.

2.2.3DNSOrganizationandStructure

TheInternet'sDNSexactlymapsthe'DomainName'delegationstructure
describedabove.ThereisaDNSserverrunningateachlevelinthe
delegatedhierarchyandtheresponsibilityforrunningtheDNSlieswith
theAUTHORITATIVEcontrolatthatlevel.

Figure12showsthisdiagrammatically.

Figure12DNSmappedtoDomainDelegation

TheRootServers(RootDNS)aretheresponsibilityofICANNbutoperated
byaconsortiumunderadelegationagreement.ICANNcreatedtheRoot
ServersSystemsAdvisoryCommittee(RSSAC)toprovideadviceand
guidanceastotheoperationanddevelopmentofthiscriticalresource.
TheIETFwasrequestedbytheRSSACtodeveloptheengineering
standardsforoperationoftheRootServers.Thisrequestresultedinthe
publicationofRFC2870.

Therearecurrently(mid2003)13rootserversworldwide.TheRoot
ServersareknowntoeverypublicDNSserverintheworldandarethe
startingpointforeverynamelookupoperation(orquery).Tocreate
additionalresilienceeachrootservertypicallyhasmultipleinstances
(copies)spreadthroughouttheworld.EachinstancehasthesameIP
addressbutdataissenttotheclosestinstanceusingaprocesscalled
anycasting.

TheTLDservers(ccTLDandgTLD)areoperatedbyavarietyofagencies
andorganizations(underafairlycomplexsetofagreements)called
RegistryOperators.

http://www.zytrax.com/books/dns/ch2/ 7/22
12/2/2016 Chapter2DNSConcepts

TheAuthorityandthereforetheresponsibilityfortheUser(orDomain
Name)DNSserverslieswiththeownerofthedomain.Inmanycases
thisresponsibilityisdelegatedbytheowneroftheDomaintoanISP,Web
Hostingcompanyorincreasinglyaregistrar.Manycompanies,however,
electtoruntheirownDNSserversandevendelegatetheAuthorityand
responsibilityforsubdomainDNSserverstoseparatepartsoftheir
organization.

WhenanyDNScannotanswer(resolve)arequest(aquery)foradomain
namefromaclient,forinstance,example.com,thequeryispassedtoa
rootserverwhichwilldirect(refer)thequerytotheappropriateTLD
DNSserver(for.com)whichwillinturndirect(refer)ittothe
appropriateDomain(User)DNSserver.

2.2.4DNSSystemComponents

ADomainNameSystem(DNS)asdefinedbyRFC1034includesthree
parts:

1.Datawhichdescribesthedomain(s)
2.OneormoreNameServerprograms.
3.Aresolverprogramorlibrary.

AsingleDNSservermaysupportmanydomains.Thedataforeach
domaindescribesglobalpropertiesofthedomainanditshosts(or
services).ThisdataisdefinedintheformoftextualResourceRecords
organizedinZoneFiles.TheformatofZonefilesisdefinedinRFC1035
andissupportedbymostDNSsoftware.

TheNameServerprogramtypicallydoesthreethings:

1.Itwillreadaconfigurationfilewhichdefinesthezonesforwhichitis
responsible.
2.DependingontheNameServersfunctionalityaconfigurationfile
maydescribevariousbehaviours,forinstance,tocacheornot.
SomeDNSserversareveryspecializedanddonotprovidethislevel
ofcontrol.
3.Respondtoquestions(queries)fromlocalorremotehosts.

Theresolverprogramorlibraryislocatedoneachhostandprovidesa
meansoftranslatingausersrequestfor,say,www.thing.comintooneor
morequeriestoDNSserversusingUDP(orTCP)protocols.

Note:TheresolveronallWindowssystemsandthemajorityof*nixsystemsisactually
astubresolveraminimalresolverthatcanonlyworkwithaDNSthatsupports
recursivequeries.ThecachingresolveronMSWindows2KandXPisastubresolverwith
acachetospeedupresponsesandreducenetworkusage.

WhileBINDisthebestknownoftheDNSserversandmuchofthisguide
documentsBINDfeatures,itisbynomeanstheonlysolutionorforthat
mattertheonlyOpenSourcesolution.AppendixC:listsmanyalternate
http://www.zytrax.com/books/dns/ch2/ 8/22
12/2/2016 Chapter2DNSConcepts

solutions.Thezonefileformatswhichconstitutethemajorityofthework
(dependingonhowmanysitesyouoperate)isstandard(definedbyRFC
1035)andistypicallysupportedbyallDNSsuppliers.Whereafeatureis
uniquetoBINDweindicateitclearlyinthetextsoyoucankeepyour
optionsopen!

2.2.5ZonesandZoneFiles

ZonefilescontainResourceRecordsthatdescribeadomainorsub
domain.TheformatofzonefilesisanIETFstandarddefinedbyRFC
1035.AlmostanysensibleDNSsoftwareshouldbeabletoreadzone
files.Azonefilewillconsistofthefollowingtypesofdata:

1.Datathatindicatesthetopofthezoneandsomeofitsgeneral
properties(aSOARecord).
2.Authoritativedataforallnodesorhostswithinthezone(typicallyA
(IPv4)orAAAA(IPv6)Records).
3.Datathatdescribesglobalinformationforthezone(includingmail
MXRecordsandNameServerNSRecords).
4.Inthecaseofsubdomaindelegationthenameserversresponsible
forthissubdomain(oneormoreNSRecords).
5.Inthecaseofsubdomaindelegationoneormoregluerecordsthat
allowsanameservertoreachthesubdomain(typicallyoneormore
AorAAAARecords)forthesubdomainnameservers.

TheindividualResourceRecordsaredescribedandnumeroussample
configurationfilesareprovidedanddocumented.

2.2.6DNSQueries

ThemajortaskcarriedoutbyaDNSserveristorespondtoqueries
(questions)fromalocalorremoteresolverorotherDNSactingonbehalf
ofaresolver.Aquerywouldbesomethinglike'whatistheIPaddressof
fred.example.com'.

ADNSservermayreceivesuchaqueryforanydomain.DNSserversmay
beconfiguredtobeauthoritativeforsomedomains,slavesforothers,
forwardqueriesorothercombinations.

MostofthequeriesthataDNSserverwillreceivewillbefordomainsfor
whichithasnoknowledge,thatis,forwhichithasnolocalzonefiles.
DNSsoftwaretypicallyallowsthenameservertorespondindifferent
waystoqueriesaboutwhichithasnoknowledge.

TherearethreetypesofqueriesdefinedforDNS:

1.Arecursivequerythecompleteanswertothequestionisalways
returned.DNSserversarenotrequiredtosupportrecursivequeries.
http://www.zytrax.com/books/dns/ch2/ 9/22
12/2/2016 Chapter2DNSConcepts

2.AnIterative(ornonrecursive)querywherethecompleteanswer
MAYbereturnedorareferralprovidedtoanotherDNS.AllDNS
serversmustsupportIterativequeries.

3.AnInversequerywheretheuserwantstoknowthedomainname
givenaresourcerecord.Reversequerieswerepoorlysupported,
veryinfrequentandarenowobsolete(RFC3425).

Note:TheprocesscalledReverseMapping(returnsahostnamegivenan
IPaddress)doesnotuseInversequeriesbutinsteadusesRecursiveand
Iterative(nonrecursive)queriesusingthespecialdomainnameIN
ADDR.ARPA.

HistoricallyreverseIPv4mappingwasnotmandatory.Manysystems
howevernowusereversemappingforsecurityandsimpleauthentication
schemes(especiallymailservers)soproperimplementationand
maintenanceisnowpracticallyessential.IPv6originallymandated
reversemappingbut,likealotoftheoriginalIPv6mandates,hasnow
beenrolledback.

2.2.6.1RecursiveQueries

ArecursivequeryisonewheretheDNSserverwillfullyanswerthequery
(orgiveanerror).DNSserversarenotrequiredtosupportrecursive
queriesandboththeresolver(oranotherDNSactingrecursivelyon
behalfofanotherresolver)negotiateuseofrecursiveserviceusingabit
(RD)inthequeryheader.

Therearethreepossibleresponsestoarecursivequery:

1.TheanswertothequeryaccompaniedbyanyCNAMErecords
(aliases)thatmaybeuseful.Theresponsewillindicatewhetherthe
dataisauthoritativeorcached.
2.Anerrorindicatingthedomainorhostdoesnotexist(NXDOMAIN).
ThisresponsemayalsocontainCNAMErecordsthatpointedtothe
nonexistinghost.
3.Antemporaryerrorindicationforinstance,can'taccessother
DNS'sduetonetworkerroretc..

InarecursivequeryaDNSResolverwill,onbehalfoftheclient(stub
resolver),chasethetrailofDNSsystemacrosstheuniversetogetthe
realanswertothequestion.Thejourneyofasimplequerysuchas'what
istheIPaddressofwww.example.com'toaDNSResolverwhichsupports
recursivequeriesbutisnotauthoritativeforexample.comisshownin
Diagram13below:

http://www.zytrax.com/books/dns/ch2/ 10/22
12/2/2016 Chapter2DNSConcepts

Diagram13RecursiveQueryProcessing

1.Theusertypeswww.example.comintotheirbrowseraddressbar.
Thebrowserissuesastandardfunctionlibrarycall(1)tothelocal
stubresolver.

2.Thestubresolversendsaquery(2)'whatistheIPaddressof
www.example.com'tolocallyconfiguredDNSresolver(akarecursive
nameserver).ThisisastandardDNSqueryrequestingrecursive
services(RD(RecursionDesired)=1).

3.TheDNSResolverlooksuptheaddressofwww.example.cominits
localtables(itscache)anddoesnotfindit.(Ifitwerefoundit
wouldbereturnedimmediatelytotheStubresolverinananswer
messageandthetransactionwouldbecomplete.)

4.TheDNSresolversendsaquery(3)toarootserver(everyDNS
resolverisconfiguredwithafilethattellsitthenamesandIP
addressesoftherootservers)fortheIPofwww.example.com.
(Rootservers,TLDserversandcorrectlyconfiguredusername
serversdonot,amatterofpolicy,supportrecursivequeriessothe
Resolverwill,typically,notsetRecursionDesired(RD=0)this
queryis,infact,anIterativequery.)

5.Therootserverknowsnothingaboutexample.com,letalonethe
wwwpart,butitdoesknowaboutthenextlevelinthehierarchy,in
thiscase,the.compartsoitreplies(answers)withareferral(3)
pointingattheTLDserversfor.com.

6.TheDNSResolversendsanewquery(4)'whatistheIPaddressof
www.example.com'tooneofthe.comTLDservers.Againitwilluse,
typically,anIterativequery.

http://www.zytrax.com/books/dns/ch2/ 11/22
12/2/2016 Chapter2DNSConcepts

7.TheTLDserverknowsaboutexample.com,butknowsnothingabout
wwwso,sinceitcannotsupplyacompleteresponsetothequery,it
replies(4)withareferraltothenameserversforexample.com.

8.TheDNSResolversendsyetanotherquery(5)'whatistheIP
addresswww.example.com'tooneofthenameserversfor
example.com.Onceagainitwilluse,typically,anIterativequery.

9.Theexample.comzonefiledefinesaA(IPv4address)recordsothe
authoritativeserverforexample.comreturns(5)theArecordfor
www.example.com(itfullyanswersthequestion).

10.TheDNSResolversendstheresponse(answer)
www.example.com=x.x.x.xtotheclient'sstubresolver(2)andthen
placesthisinformationinitscache.

11.Thestubresolverplacestheinformationwww.example.com=x.x.x.x
initscache(sincearound2003moststubresolvershavebeen
cachingstubresolvers)andrespondstotheoriginalstandardlibrary
functioncall(1)withwww.example.com=x.x.x.x.

12.Thebrowserreceivestheresponsetoitsstandardfunctioncall,
placestheinformationinitscache(really)andinitiatesanHTTP
sessiontotheaddressx.x.x.x.DNStransactioncomplete.Quite
simplereally,notmuchcouldpossiblygowrong.

Insummary,thestubresolverdemandsrecursiveservicesfromtheDNS
Resolver.TheDNSResolverprovidesarecursiveservicebutuses,
typically,Iterativequeriestoachieveit.

Note:TheresolveronWindowsandmost*nixsystemsisastub
resolver(inpointoffact,inmostmodernsystemsitisaCachingstub
Resolver)whichisdefinedinthestandardstobeaminimalresolver
whichcannotfollowreferrals.IfyoureconfigureyourlocalPCor
WorkstationtopointtoaDNSserverthatonlysupportsIterativequeries
itwillnotwork.Period.

2.2.6.2Iterative(nonrecursive)Queries

AIterative(ornonrecursive)queryisonewheretheDNSservermay
provideananswerorapartialanswer(areferral)tothequery(orgivean
error).AllDNSserversmustsupportnonrecursive(Iterative)queries.An
IterativequeryistechnicallysimplyanormalDNSquerythatdoesnot
requestRecursiveServices.

Therearefourpossibleresponsestoanonrecursivequery:

1.TheanswertothequeryaccompaniedbyanyCNAMErecords
(aliases)thatmaybeuseful(inaIterativeQuerythiswillONLYoccur
iftherequesteddataisalreadyavailableinthecache).Theresponse
willindicatewhetherthedataisauthoritativeorcached.
http://www.zytrax.com/books/dns/ch2/ 12/22
12/2/2016 Chapter2DNSConcepts

2.Anerrorindicatingthedomainorhostdoesnotexist(NXDOMAIN).
ThisresponsemayalsocontainCNAMErecordsthatpointedtothe
nonexistinghost.
3.Antemporaryerrorindication,forinstance,can'taccessotherDNS's
duetonetworkerroretc..
4.Areferral:Iftherequesteddataisnotavailableinthecachethen
thenameandIPaddess(es)oroneormorenameserver(s)thatare
closertotherequesteddomainname(inallcasesthisisthenext
lowerlevelintheDNShierarchy)willbereturned.Thisreferralmay,
ormaynotbe,totheauthoritativenameserverforthetarget
domain.

InDiagram13abovethetransactions(3),(4)and(5)arenormallyall
Iterativequeries.EveniftheDNSserverrequestedRecursion(RD=1)it
wouldbedeniedandthenormalreferral(oranswer)returned.Whyuse
Iterativequeries?Theyaremuchfaster.TheDNSserverreceivingthe
queryeitheralreadyhastheanswerinitscache,inwhichcaseitsendsit,
ornot,inwhichcaseitsendsareferral.Nomessingaround.Iterative
queriesgivetherequestorgreatercontrol.Areferraltypicallycontainsa
listofnameserversforthenextlevelintheDNShierarchy.Therequestor
mayhaveadditionalinformationaboutoneormoreofthesename
serversinitscache(includingwhichisthefastest)fromwhichitcan
makeabetterdecisionaboutwhichnameservertouse.Iterativequeries
areveryusefulindiagnosticsituations.

2.2.6.3InverseQueries

Historically,anInversequerymappedaresourcerecordtoadomain.An
exampleInversequerywouldbe'whatisthedomainnameforthisMX
record'.Inversequerysupportwasoptionalanditwaspermittedforthe
DNSservertoreturnaresponseNotImplemented.

InversequeriesareNOTusedtofindahostnamegivenanIPaddress.
ThisprocessiscalledReverseMapping(Lookup)usesrecursiveand
Iterative(nonrecursive)querieswiththespecialdomainnameIN
ADDR.ARPA.

Inversequerieswentthewayofall"seemedlikeagoodideaatthetime"
conceptswhentheywerefinallyobsoletedbyRFC3425.

2.2.7ZoneUpdates

TheinitialdesignofDNSallowedforchangestobepropagatedusing
ZoneTransfer(AXFR)buttheworldoftheInternetwassimplerandmore
sedateinthosedays(1987).Thedesiretospeeduptheprocessofzone
updatepropagationwhileminimisingresourcesusedhasresultedina
numberofchangestothisaspectofDNSdesignandimplementationfrom

http://www.zytrax.com/books/dns/ch2/ 13/22
12/2/2016 Chapter2DNSConcepts

simplebuteffectivetinkeringsuchasIncrementalZoneTransfer
(IXFR)andNOTIFYmessagestotheconceptofDynamicUpdates
whichhavesignificantsecurityconsequencesifnotproperlyimplemented.
Diagram14showzonetransfercapabilities.

Warning:Whilezonetransfersaregenerallyessentialfortheoperation
ofDNSsystemstheyarealsoasourceofthreat.AAslaveNameServer
canbecomepoisonedifitacceptszoneupdatesfromamalicioussource.
Careshouldbetakenduringconfigurationtoensurethat,asaminimum,
the'slave'willonlyaccepttransfersfromknownsources.Theexample
configurationsprovidetheseminimumprecautions.SecurityOverview
outlinessomeofthepotentialthreatsinvolved.

2.2.7.1FullZoneUpdate(AXFR)

TheoriginalDNSspecifications(RFC1034&RFC1035)envisagedthat
Slave(orsecondary)NameServerswould'poll'theDomain(orzone)
Master.Thetimebetweensuch'polling'isdeterminedbytherefresh
valueonthedomain'sSOAResourceRecord

ThepollingprocessisaccomplishedbytheSlavesendingaquerytothe
MasterrequestingitscurrentSOAresourcerecord(RR).Iftheserial
numberofthisRRishigherthanthecurrentonemaintainedbythe
Slave,azonetransfer(AXFR)isrequested.Thisiswhyitisvitaltobe
verydisciplinedaboutupdatingtheSOAserialnumbereverytime
anythingchangesinANYofthezonerecords.

ZonetransfersarealwayscarriedoutusingTCPonport53whereas
normalDNSqueryoperationsuseUDPonport53.

2.2.7.2IncrementalZoneUpdate(IXFR)

Transferringverylargezonefilescantakealongtimeandwaste
bandwidthandotherresources.Thisisespeciallywastefulifonlyasingle
RRhasbeenchanged!RFC1995introducedIncrementalZoneTransfers
(IXFR)whichasthenamesuggestsallowstheSlaveandMasterto
transferonlythoserecordsthathavechanged.

TheprocessworksasforAXFR.TheSlavesendsaqueryforthedomain's
SOARReveryrefreshinterval.IftheserialnumberoftheSOArecord
ishigherthanthecurrentonemaintainedbytheSlaveitrequestsazone
transferandindicateswhetherornotitiscapableofacceptingan
IncrementalTransfer(IXFR).IfbothMasterandslavesupportthefeature
anIncrementalTransfer(IXFR)takesplaceotherwiseaFullTransfer
(AXFR)takesplace.IncrementalZonetransfersuseTCPonport53,
whereasnormalDNSqueriesoperationsuseUDPonport53.

http://www.zytrax.com/books/dns/ch2/ 14/22
12/2/2016 Chapter2DNSConcepts

ThedefaultmodeforBINDwhenactingasaSlaveistorequestIXFR
unlessitisconfigurednottousingtherequestixfrparameterinthe
serveroroptionsclauseofthenamed.conffile.

ThedefaultmodeforBINDwhenactingasaMasteristouseIXFRonly
whenthezoneisdynamic.TheuseofIXFRiscontrolledusingthe
provideixfrparameterintheserveroroptionsclauseofthe
named.conffile.

2.2.7.3Notify(NOTIFY)

RFC1912recommendsaREFRESHintervalofupto12hoursonthe
REFRESHintervalofanSOAResourceRecord.Thismeansthat,inthe
worstcase,changestotheMasterNameServermaynotbevisibleatthe
SlaveNameServer(s)forupto12hours.Inadynamicenvironmentthis
maybeunacceptable.

RFC1996introducedaschemewherebytheMasterwillsendaNOTIFY
messagetotheSlaveNameServer(s)thatachangeMAYhaveoccurred
inthedomainrecords.TheSlave(s)onreceiptoftheNOTIFYwillrequest
thelatestSOAResourceRecordandiftheserialnumberoftheSOARR
isgreaterthanitscurrentvalueitwillinitiateazonetransferusingeither
aFullZoneTransfer(AXFR)oranIncrementalZoneTransfer(IXFR).

NOTIFYbehaviourinBINDiscontrolledbynotify,alsonotifyand
notifysourceparametersinthezoneoroptionsstatementsofthe
named.conffile.

Diagram14MasterSlaveInteractionandZoneTransfer

ZoneTransferProcessDescription

http://www.zytrax.com/books/dns/ch2/ 15/22
12/2/2016 Chapter2DNSConcepts

ThetimetakentopropagatezonechangesthroughouttheInternetis
determinedbytwomajorfactors.First,thetimetakentoupdateallthe
Domain'sNameserverswhenanyzonechangeoccurs.This,inturn,is
determinedbythemethodusedtoinitiatezonetransferstoallSlave
NameServerswhichmaybepassive(theSlavewillperiodicallypollthe
Master)orActive(theMasterwillsendaNOTIFYtoitsconfigured
Slave(s)).Bothmethodsaredescribedbelow.Second,thecurrentTTL
value(priortoitschange)onanychangedzonerecordwilldetermine
whenResolverswillrefreshtheircachesbyinterrogatingtheAuthoritative
NameServer.

1.IftheMasterhasbeenconfiguredtosupportNOTIFYmessagesthen
wheneverthestatusoftheMaster'szonefile(1)changesitwillsend
aNOTIFYmessage(2)toeachconfiguredSlave.ANOTIFYmessage
doesnotnecessarilyindicatethatthezonefilehaschanged,for
example,iftheMasterorthezoneisreloadedthenaNOTIFY
messageistriggeredevenifnochangeshaveoccured.Whenthe
SlavereceivesaNOTIFYmessageitfollowstheproceduredefinedin
Step3below.

2.IrrespectiveofwhethertheMasterhasbeenconfiguredtosupport
NOTIFYmessagesornottheSlavewillalwaysusethepassiveor
'polling'processdescribedinthisstep.(Whileonitsfacethisseem
superflousincaseswheretheMasterhasbeenconfiguredtouse
NOTIFY,however,itdoesprovideprotectionagainlostNOTIFY
messagesduetomalconfigurationormaliciousattack.)Whena
Slaveserverisloadeditwillreadanycurrentsavedzonefile(seefile
statement)orimmediatelyintitateazonetransferifthereisno
savedzonefile.Itthenstartsatimerusingtherefreshvalueinthe
zone'sSOARR.WhenthistimerexpirestheSlavefollowsthe
proceduredefinedinStep3below.

3.IftheSlave'srefreshtimerexpiresORitreceivesaNOTIFY
messagetheSlavewillimmediatelyissueaqueryforthezone
Master'sSOARR(3).

4.Whentheanswerarrives(4)theSlavecomparestheserialnumber
ofitscurrentSOARRwiththatoftheanswer(theMaster'sSOARR).
IfthevalueoftheMasterSOARRserialnumberisgreaterthanthe
currentserialnumberintheSlave'sSOAcopythenazonetransfer
(5)isintiatedbytheSlave.(Thegruesomedetailsoftheserial
numberarithmeticisdefinedinRFC1982andclarifiedinRFC2181,
thedatebasedconventionusedforserialnumbersisdefinedhere).
IftheslavefailstoreadtheMaster'sSOARR(orfailstointiatethe
zonetransfer)thenitwilltryagainaftertheretrytimedefinedin
thezone'sSOARRbutwillcontinueansweringAuthoritativelyforthe
Domain(orzone).Theretryprocedurewillberepeated(everyretry
interval)eitheruntilitsucceeds(inwhichcasetheprocesscontinues
atstep5below)oruntiltheexpirytimerofthezone'sSOARRis
reached,atwhichpointtheSlavewillstopansweringqueriesforthe
Domain.

http://www.zytrax.com/books/dns/ch2/ 16/22
12/2/2016 Chapter2DNSConcepts

5.TheSlavealwaysintitiates(5)azonetransferoperation(usingAXFR
orIXFR)usingTCPonPort53(thiscanbeconfiguredusingthe
transfersourcestatement).

6.TheMasterwilltransfertherequestedzonefile(6)totheslave.On
completiontheSlavewillresetitsrefreshandexpirytimers.

2.2.7.4DynamicUpdate

TheclassicmethodofupdatingZoneResourceRecordsistomanuallyedit
thezonefileandthenstopandstartthenameservertopropagatethe
changes.Whenthevolumeofchangesreachesacertainlevelthiscan
becomeoperationallyunacceptableespeciallyconsideringthatin
organisationswhichhandlelargenumbersofZoneFiles,suchasservice
providers,BINDitselfcantakealongtimetorestartatitplowsthrough
verylargenumbersofzonestatements.

The'holygrail'ofDNSistoprovideamethodofdynamicallychangingthe
DNSrecordswhileDNScontinuestoservicerequests.

Therearetwoarchitecturalapproachestosolvingthisproblem:

1.Allow'runtime'updatingoftheZoneRecordsfromanexternal
source/application.
2.DirectlyfeedtheDNSfromadatabasewhichcanbedynamically
updated.BINDprovidestwoAPIstoenablethis,otherDNS
implemenationsprovideembeddeddatabaseaccess.

RFC2136takesthefirstapproachanddefinesaprocesswherezone
recordscanbeupdatedfromanexternalsource.Thekeylimitationinthis
specificationisthatanewdomaincannotbeaddeddynamically.Allother
recordswithinanexistingzonecanbeadded,changedordeleted.This
limitationisalsotrueforbothofBIND'sAPIsaswell.

AspartofRFC2136thetermPrimaryMasterwascoinedtodescribe
theNameServerdefinedintheSOAResourceRecordforthezone.The
significanceofthistermisthatwhendynamicallyupdatingrecordsitis
essentialtoupdateonlyoneservereventhoughtheremaybemultiple
masterserversforthezone.Inordertosolvethisproblema'boss'
servermustbeselected,this'boss'server(thePrimaryMaster)hasno
specialcharacteristicsotherthanitisdefinedastheNameServerinthe
SOArecordandmayappearinanallowupdateclausetocontrolthe
updateprocess.

DDNSisnormallyassociatedwithSecureDNSfeaturessuchasTSIG
RFC2845&TKEYRFC2930.DynamicDNS(DDNS)doesnotREQUIRE
TSIG/TKEY.HoweverbyenablingDynamicDNSyouarealsoopeningup
thepossibilityofmasterzonefilecorruptionorpoisoning.SimpleIP
addressprotection(acl)canbeconfiguredintoBINDbutthisprovidesat
bestlimitedprotection.Forthatreason,serioususersofDynamicDNS

http://www.zytrax.com/books/dns/ch2/ 17/22
12/2/2016 Chapter2DNSConcepts

willalwaysuseTSIG/TKEYprocedurestoauthenticateincomingupdate
requests.

InBINDDDNSisdefaultedtodenyfromallhosts.ControlofDynamic
UpdateisprovidedbytheBINDallowupdate(usablewithandwithout
TSIG/TKEY)andupdatepolicy(onlyusablewithTSIG/TKEY)clausesin
thezoneoroptionsstatementsofthenamed.conffile.

ThereareanumberofOpenSourcetoolswhichwillinitiateDynamicDNS
updatestheseincludednsupdate(notthesameasDNSUpdate)and
nsupdatewhichisdistributedwithbindutils.

2.2.7.5AlternativeDynamicDNSApproaches

AsnotedabovethemajorlimitationinthestandardDynamicDNS(RFC
2136)approachisthatnewdomainscannotbecreateddynamically.

BINDDLZtakesamuchmoreradicalapproachand,usingaseriouspatch
toBIND,allowsreplacementofallzonefileswithasinglezonefilewhich
definesadatabaseentry.Thedatabasesupport,whichincludesmostof
themajordatabases(MySQL,PostgreSQL,BDBandLDAPamongothers)
allowstheadditionofnewdomainsaswellaschangestopreexisting
domainswithouttheneedtostopandstartBIND.Aswithallthingsinlife
thereisatradeoffandperformancecandropprecipitously.Currentwork
beingcarried(early2004)outwithaHighperformanceBerkeleyDB
(BDB)isshowingexcellentresultsapproachingrawBINDperformance.

PowerDNSanauthoritativeonlynameservertakesasimilarapproach
withitsown(nonBIND)codebasebyreferringallqueriestothe
databasebackendandtherebyallownewdomainstobeadded
dynamically.

2.3SecurityOverview

DNSSecurityisahugeandcomplextopic.Itismadeworsebythefact
thatalmostallthedocumentationdivesrightinandyoufailtoseethe
forestforallthed@!#*dtrees.

Thecriticalpointistofirstunderstandwhatyouwanttosecureor
ratherwhatthreatlevelyouwanttosecureagainst.Thiswillbevery
differentifyourunarootserverratherthanrunningamodestinhouse
DNSservingacoupleoflowvolumewebsites.

ThetermDNSSECisthrownaroundasablanketterminalotof
documentation.Thisisnotcorrect.ThereareatleastthreetypesofDNS
security,twoofwhicharerelativelypainlessandDNSSECwhichis
relativelypainful.

http://www.zytrax.com/books/dns/ch2/ 18/22
12/2/2016 Chapter2DNSConcepts

Securityisalwaysaninjudiciousblendofrealthreatandparanoiabut
rememberjustbecauseyouarenaturallyparanoiddoesnotmeanthat
theyarenotafteryou!

2.3.1SecurityThreats

Inordertobeabletoassessboththepotentialthreatsandthepossible
countermeasuresitisfirstandforemostnecessarytounderstandthe
normaldataflowsinaDNSsystem.Diagram15belowshowsthisflow.

Diagram15DNSDataFlow

Everydataflow(eachREDlineabove)isapotentialsourceofthreat!
Usingthenumbersfromtheabovediagramhereiswhatcanhappenat
eachflowbeware,youmaynotsleepsoundlytonight:

Number Area Threat

(1) Zone FileCorruption(maliciousoraccidental).Localthreat.

Files

(2) Dynamic UnauthorizedUpdates,IPaddressspoofing(impersonatingupdate

Updates source).ServertoServer(TSIGTransaction)threat.

(3) Zone IPaddressspoofing(impersonatingupdatesource).ServertoServer

Transfers (TSIGTransaction)threat.

(4) Remote CachePoisoningbyIPspoofing,datainterception,orasubverted

Queries MasterorSlave.ServertoClient(DNSSEC)threat.

(5) Resolver Datainterception,PoisonedCache,subvertedMasterorSlave,localIP

http://www.zytrax.com/books/dns/ch2/ 19/22
12/2/2016 Chapter2DNSConcepts

Queries spoofing.RemoteClientclient(DNSSEC)threat.

Thefirstphaseofgettingahandleontheproblemistofigure(audit)
whatthreatsareapplicableandhowseriouslydoYOUratethemordo
theyevenapply.Asanexampleifyoudon'tdoDynamicUpdates(BIND's
defaultmode)thereisnoDynamicUpdatethreat!Finallyinthissection
awarning:thefurtheryougofromtheMasterthemore
complicatedthesolutionandimplementation.Unlessthereisavery
goodreasonfornotdoingso,wewouldalwaysrecommendthatyoustart
fromtheMasterandworkout.

2.3.2SecurityTypes

Weclassifyeachthreattypebelow.Thisclassificationsimplyallowsus
selectappropriateremediesandstrategiesforavoidingorsecuringour
system.Thenumberingusedbelowrelatestodiagram13.

(1)TheprimarysourceofZonedataisnormallytheZoneFiles(anddon't
forgetthenamed.conffilewhichcontainslotsofinterestingdataaswell).
Thisdatashouldbesecureandsecurelybackedup.Thisthreatis
classifiedasLocalandistypicallyhandledbygoodsystem
administration.

(2)TheBINDdefaultistodenyDynamicZoneUpdates.Ifyouhave
enabledthisserviceorrequiretoitposesaseriousthreattotheintegrity
ofyourZonefilesandshouldbeprotected.ThisisclassifiedasaServer
Server(Transaction)threat.

(3)Ifyourunslaveserversyouwilldozonetransfers.Note:YoudoNOT
havetorunwithslaveservers,youcanrunwithmultiplemastersand
eliminatethetransferthreatentirely.ThisisclassifiedasaServer
Server(Transaction)threat.

(4)ThepossibilityofRemoteCachePoisoningduetoIPspoofing,data
interceptionandotherhacksisajudgementcallifyouarerunninga
simplewebsite.Ifthesiteishighprofile,opentocompetitivethreatoris
ahighrevenueearneryouhaveprobablyimplementedsolutionsalready.
ThisisclassifiedasaServerClientthreat.

(5)ThecurrentDNSSECstandardsdefineasecurityawareresolverand
thisconceptisunderactivedevelopmentbyannumberofgroupsround
theworld.ThisisclassifiedasaServerClientthreat.

2.3.3SecurityLocal

Normalsystemadministrationpracticessuchasensuringthatfiles
(configurationandzonefiles)aresecurelybackedup,properreadand

http://www.zytrax.com/books/dns/ch2/ 20/22
12/2/2016 Chapter2DNSConcepts

writepermissionsappliedandsensiblephysicalaccesscontroltoservers
maybesufficient.

ImplementingaStealth(orSplit)DNSserverprovidesamoreserious
solutiondependingonavailableresources.

FinallyyoucanrunBIND(named)inachrootjail.

2.3.4ServerServer(TSIGTransactions)

Zonetransfers.Ifyouhaveslaveserversyouwilldozonetransfers.
BINDprovidesAccessControlLists(ACLs)whichallowsimpleIP
addressprotection.WhileIPbasedACLsarerelativelyeasytosubvert
usingIPaddreessspoofingtheyarealotbetterthannothingandrequire
verylittlework.Youcanrunwithmultiplemasters(noslaves)and
eliminatethethreatentirely.Youwillhavetomanuallysynchronisezone
fileupdatesbutthismaybeasimplersolutionifchangesarenot
frequent.

DynamicUpdates.Ifyoumustrunwiththisserviceitshouldbe
secured.BINDprovidesAccessControlLists(ACLs)whichallowsimple
IPaddressprotectionbutthisisprobablynotadequateunlessyoucan
securetheIPaddresses,thatis,allsystemsarebehinda
firewall/DMZ/NATortheupdatinghostsareusingprivateIPaddresses.

TSIG/TKEYIfallothersolutionsfailDNSspecifications(RFC2845
TSIGandRFC2930TKEY)provideauthenticationprotocol
enhancementstosecuretheseServerServertransactions.

TSIGandTKEYimplementationsaremessybutnottoocomplicated
simplybecauseofthescopeoftheproblem.WithServerServer
transactionsthereisafiniteandnormallysmallnumberofhostsinvolved.
Theprotocolsdependonasharedsecretbetweenthemasterandthe
slave(s)orupdater(s).Itisfurtherassumedthatyoucangettheshared
secretsecurelytothepeerserverbysomemeansnotcoveredinthe
protocolitself.Thisprocess,knownaskeyexchange,maynotbetrivial
(typicallylongrandomstringsofbase64charactersareinvolved)butyou
canusethetelephone(!),mail,faxorPGPemailamongothermethods.

Thesharedsecretisopentobruteforceattackssofrequent(monthly
ormore)changingofsharedsecretswillbecomeafactoflife.TKEY
allowsautomationofkeyexchangeusingaDiffieHellmanalgorithmbut
startswithasharedsecret!TKEYappearstohaveverylimited,ifany,
usage.

2.3.5ServerClient(DNSSEC)

http://www.zytrax.com/books/dns/ch2/ 21/22
12/2/2016 Chapter2DNSConcepts

TheclassicRemotePoisonedcacheproblemisnottrivialtosolvesimply
becausetheremaybeaninfinitelylargenumberofRemoteCaches
involved.Itisnotreasonabletoassumethatyoucanuseashared
secret.

InsteadDNSSECreliesonpublic/privatekeyauthentication.The
DNSSECspecifications(RFC4033,RFC4034andRFC4035augmented
withothers)attempttoanswerthreequestions:

1.AuthenticationtheDNSrespondingreallyistheDNSthatthe
requestwassentto.
2.Integritytheresponseiscompleteandnothingismissingor
changed.
3.ProofofnonexistanceiftheDNSreturnsastatusthatthename
doesnotexist(NXDOMAIN)thisresponsecanbeproventohave
comefromtheauthoritativeserver.

Chapter3ReverseMapping

MainContents

Problems,comments,suggestions,corrections(includingbrokenlinks)or
somethingtoadd?Pleasetakethetimefromabusylifeto'mailus'(at
topofscreen),thewebmaster(below)orinfosupportatzytrax.Youwill
haveawarminnerglowfortherestoftheday.

Copyright19942016ZyTrax,Inc. sitebyzytrax webmasteratzytrax

Allrightsreserved.LegalandPrivacy Pagemodified:July122016.

http://www.zytrax.com/books/dns/ch2/ 22/22