(lotrg) DNS dynmic updates dran
`
`lofl8
`
`lDate PrevllDate NextllThread PrevllThread NextlJDate lndexllThread lndexl
`
`(long) DNS dynamic updates draft
`
`r Zo: namedroopers@intemic.net
`. Subject: (long) DNS dynamic updates draft
`o Froz: Susan Thomson <!g@$dlig!!ggIgggE>
`t Date:Thu,14 Jul 1994 l7:15:104400(EDT)
`
`DNSIND llorking Group
`INTERNET-DRAFT
`<draf t-ietf -dnsind-dvnDNs-arch- 00. txt>
`
`Yakov Rekhter (IBM)
`Susan Thomson (Bellcore )
`Jim Bound (DEC)
`Pete! Fold (LANL)
`July 15, 1994
`
`Dynanic updates in the Donaj.n Nane sysren (DNS):
`Architecture and Mechanisn
`
`Status oi thls Meno
`Internet Dlatts are wolking
`This docunent is an Internet Draft,
`documents of the Internet Enqineering Task Folce (IETF), its Areas,
`and its working Groups. Note that other groups nay also distribule
`\torking doculents as Intetnet Drafts.
`Internet Drafts are draft docwrents valid for a naxinum of six
`nonths. Intelnet DrafLs may be updated, replaced, o! obsoleted by
`other docunents al any Cine. It ie not applopriate to use Internet
`Dlafts as reference natetial or to cj"te tshem other than as a "wolking
`draft" or "wark in plogress."
`To learn the curlent status gf eny Interne! Draft. please check the
`lid-abstracts.txt Lisling contained in the Intelnet Drafts Shadow
`Directgries on d9- internj.c.net, nic.nordu. net, ftp'nisc. sli. com or
`nunnari -o?,au.
`
`Abstract
`To support host auloconfj.gulalion, a hcst's dynamically acquired
`address must be regigLe.ed in the Dqnain Nane System (DNs)
`aulonatically. This docuneqt specifj.es the extensions to DNS tp
`enable autoregistlatiqn, DNS extensions include a new oPelaLlon that
`enables recolds associated lrith an existing node to be uPdated, and a
`neur .resource recgld atttibuLe that enables records to be invaLidated
`autonatically, The changes a!e designed to be ninimaL and are
`expected to occut iI] conjunctj.on with the Dlls securlty
`extensions IDNSSECI and the incremental zone trensfe!
`nechanismIDNSIXFRI.
`
`I tp://wrvrv-ops.ic|for8/lislyrwrcdroppetvna![cdDppeE.l99Vrnsgol302.ltunl
`
`sKYPE-N2P01603525
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 1
`
`

`

`(lotrg) DNS dynamic updates drafi
`
`2ofl8
`
`Expires .tanuary 15, 1995
`
`lPage 1l
`
`INTERNE?-DRAFT
`
`Dyna$ic DNS Updates
`
`July 19 94
`
`1.
`
`INTRODUCTIOI{
`
`This doculent addresses the problem of registering a host's dynani-
`cally acquired addless in DNS automatically,
`Host autoconfiguration is beconing increasingly impo!tant as the
`InLernet grons. It is inportant that a host is able to canfigure
`tine, and
`itse.Ii with an address lrhen it
`is polreled oD for the tirgt
`conti.nue to operate wilhaut nanua] j.ntervention when a new eddress is
`assigned, e.9. becauge a new plovide! is bej,ng uged or becauge the
`host has moved. Since the mapping between a host and its dynamically
`acquiled addless is not known a prioli and hence cannot be prete-
`gistered ln DNs, the goaf is to plovide an autoregi st r at ion nechan-isn
`so that nanuaL legj.stration iD DNS can be elininated froh the criti-
`cal path.
`To support host autoconfigu!aClon, lre speqify how, once a nane and
`addrcss has been assigned to the host, a ho3trg nane-to-addles9 {A
`record) and inverse nappings (PTR recold) can be updated. The update
`nechanisn enabLes records associated with an existing node.in the
`domain nane Epace to be added, deleted or modified, The design p!!n-
`ciple used in the architecture i5 that the entity that "o$tns" d
`record is the one autholised ta pe!for!! an update. For exanple, the
`entity wiII usuaLty be a host in Lhe case gJ a type A recold, and ad
`address asgignnent selver, e.g. a Dynarric Host Configuration Protocol
`(DHcP) tRFC1531l selver, iD lhe case of a PTR record-
`we assune that a hgst caD deternine its address, e,g. by usi.lg DHCP
`or ES-ISlIsO9542l, and can delemine its donain nalDe/ e.9. by usj.ng
`DHCP or by some out-of-band schedle such as lequesting the DNs servace
`provider o! system administrato!. If DNs is being used in secute
`node, we also assune a schene for exchange of key inforroation beLween
`the host and DNS.
`Ite are pEinarily concerned with autoregistlation of host addresses,
`but the update nechaDisdl does not preclude autoregistration of any
`other information. It i.s concei-\'able tbac other information stored in
`DNS nay also be updateable, e.9. nailbcx (M() records. ?he exten-
`sions to DNs to suppolt dynarnic updates are designed lo be applicable
`to any lecord type. llowever, the scope of the problem tre address in
`tbis documen! is Linited to that of automatically updating records
`associated with a node that already exists in the domain name space.
`Nodes must be preconfigured in the apptopriate zqne, possibly i{ith an
`etnDtv seL of resource records, before anv infornation needs to be
`
`Expires ,lanua!y 15, 1995
`
`INTERNET-DRAF?
`
`Dynarnic DNs updates
`
`IPage 2l
`
`,luly 1994
`
`httpi//\r'\v\v.ops. iet-[.org/lislVrla|nedroppervrunredrappers. 199x,/n$901302. huIl
`
`SKYPE-N2P01603526
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 2
`
`

`

`(lorg) DNS dyn:amic uPdates dtnlt
`
`loflS
`
`Ite believe and sbov, by exanple that this can be done in
`registered,
`a practical nanne!.
`This document specifies the extensions to DNs to enable autoregistra-
`tj.on, and desclibes hor.t bost address autoconfiguration can be sup-
`polted in soDe typical opelating eDvilonments. The et tensions incLude
`a new operation that enables records associated with an existing node
`to be updated, and a new resoulce record attribute, an expiratign
`tjre, which enables records to be invalidated autonatically, tbe p!o-
`posed chanqes are eipected to occu! in conjunction with the DNs secu-
`rily extensions IDNSSEC] and the incleheDtal zone ttansfer
`the expiration tirne of a record is
`nechanj.Fu IDNSIxFR] . In palticula!,
`defined to be that of its signatule, and lncrernenlaf zone transfer 1s
`expected to be important for efticient maintenance of j.ntetnal con-
`srstency.
`
`2. DESIGN PRINCIPIES END REOUIREMENTS
`
`Extensions to DNg rlust be conpatible with exlstlog servers and
`reso.lve!s.
`The use of lhe DNs dyaanic update nechanisn to update addresses
`musL be conpatible with use of other services suppoltug auto-
`conf iguration,. nolably DHcP.
`DNs updates must be able to be nade secure. The gecurity mechan-
`ism must provide data oligin authentj.cation, data integrity and
`j,5 not requiled-
`protection againsE leplay. Data ccnfidentiality
`Tbe entity that nowns" or manages a node i.n the doriain nane
`space is the one responsible for updating the recolds assocj'ated
`Nith the node.
`An entity owning a name can update the DNg servets authorif,ative
`ior lhat zone no mattet where the eDtity i5 physically Iocated,
`assulling IP connecti.vity between the entity and the servers and
`the necessary security clealance.
`lhe design should be j.ndependent cf any particula! version of
`the internetworking protocol iD use to the extent Possible.
`
`2,
`
`4.
`
`6.
`
`Exprres January 15, 1995
`
`(Page 3l
`
`INTERNET-DRAFT
`
`Dynanic DNS UPda tes
`
`July 1994
`
`3. OVERVIEW OF ARCHItECTURE
`
`3,1. Acquirlng an address
`
`A host may acquj.ie an addregs automatically using an addleg9 assign-
`ment service such as a DHCP serve!, or folm an address on its own
`
`Irllp://w\vw.ops. icf.org/listVrrunedroppergtutlrcdtoppers. l99.VtrEgol302.lrtlDl
`
`SKYPE.N2PO1603527
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 3
`
`

`

`(long) DNS dymmic updates drdft
`
`4ofl8
`
`using a subnet prefix advertised by a rouLer and an identifie!
`known
`to Lhe host that is unique at least ltithin the sublet, Like BS-IS-
`
`3.2. Acquiring a dollain nane
`
`currently/ only DHCP enables a host to acquile a domain nane au€onat-
`.ically. fn the absence ol sone otber nechanism, a host nust be
`assigned a unique donain nar0e using out_gf-baDd neans' e.g' by the
`service plovider or systen adrninistrator.
`
`3.3. Updating DNS
`
`As mentioned above, it i5 the entity that i'o!,tns! the nane of a recold
`that is responsible for updating it. For example, a host tha! onns
`its own name is responsible for updating Lhe name-to-address maPpiDg
`(A r€cord) in DNs. since an address assiqrunent selver, such as a
`leases to hosts and has lhe option
`DHCP server, onns the addresses il
`of reusing an addless once the Lease expires, it is responsibfe tor
`updali.ng the addless-to-nare rnappj.ng (PTR recordl in DNS-
`An entj.ty that admj-nisters addregses nr.lst plovide a rnechanism by
`lrhich the bost can cotnnunicate to that entity its domain nane so that
`the inverse napping can be updated. fn Lhe absence of any secule
`exchange of this inforr0atiqn, lhe address assignnent entity may
`authenticate the host's domain nane by looking it up in DNs, and
`checking that the correspondinq A r€cord exists' This authenticatj'on
`strategy rneans that the Datre-to-address mappj-ng nust be registered in
`DNS prio! to legistratian af tbe inverse nappr[g.
`
`Expires January 15, l9 -c5
`
`INTERNET-DRAFT
`
`Dynamic DNs Updates
`
`3.4 , DNs update Hechanisns
`
`lPage 4l
`
`,lul y 19 94
`
`updates to a zone nust (ultinaLely) be presented to a Prinary name
`server that i5 authorilative for the zcne. A new opelatioo (REPLACE)
`is added to the Dtts prolocol enabling records associated r'lith an
`existrng node to be added, modified o! deleted. The new update opera-
`tion has the following defin.ition:
`REPI,ACE rePlaces Lhe complete set of records of a specified
`dornain name, class and tyPe by a new set of reqolds of the same
`narne, type and class. The donrain nane and clags must e)'igl' A
`successful update is pernaDent untl-1 the recotds expire' Changes
`are drst!ibuLed to other authoritative servers asynchtonously'
`nhother cbange to the DNg specification is that a recold has an asso-
`c-iated expiratioh tihe. The expiration tine indicates rnhen a lecord
`becomes invatid (out-of-date ) -
`In the next 3 sections, the extensions to the DNS spesification are
`defined in detail.
`
`lrlrp://\!wl|.ops. iellor8/lislvrlaloedropperVrta|nedroppers.
`
`| 99Vn)sgol302.l nl
`
`SKYPE-N2P01603528
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 4
`
`

`

`(lotrg) DNS dynamic updates dlan
`
`5of18
`
`Expires January 15, 1995
`
`INTERNET-DRAFT
`
`Dvnani.c DNs uDdates
`
`4. RESOURCf, RBCORD EXTENSIONS
`
`[8age 5]
`
`.luly 19 94
`
`A tesoutce record, in additlon to containing a donain namer a classr
`a tl|per a tine-to-l.ive (TTI) value and sone data, has an associated
`expiration tine. The expilatlon tine cf a record is that of its sig-
`neture and is as defined in the DNs security specificationlDNSSECI .
`This attrj.bute indicates when the record (and its associated signa-
`ture) begones out-of_date, enab.ling records to be invalidated
`aulomatically after a sPecrfied tine has passed.
`The value of a recoldrs TTL nust take inLo account the recordts
`fhal is, the
`expiration time so that it is not cached beyood explry.
`to expiry and
`TTL value nust be sel !o the mj-ninurn of lhe tire left
`the desired or current value of the TTI.
`
`halp:/ vrvrv,ops.ictf org/lislVrlanredroppetvr|aIncdropF s. l 99.Vrrs80 l 302, lllllrl
`
`sKYPE-N2P01603529
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 5
`
`

`

`(long) DNS dynamic updates dmn
`
`6of18
`
`Expires .lanuary 15, 19 -o5
`
`IPage 6l
`
`INTERNET-DR' TA
`
`Dynanic DNS Updates
`
`July 19 94
`
`5. NAME SERVER BEMVIOR
`
`ID addition !o the standard query, name se.rvels trlust implenent the
`REPLACE operation. Unlike a standard query, only a primary name
`server authoritative fo! a sPecified ncde is able to Perforn a
`REPLACE operation on thot node.
`In this section, ire specj.fy the REPLACE opelatj.on and the extensions
`to nane serve! behavior r"then perforning standard queries,
`
`5.L. The REPLACE Operacion
`
`The algunents to the REPI,ACE operation i.nclude the name (QNAME),
`class and type of record to be updated together !.rith the recolds
`themselves, The cLass and type of query bave the salt|e semancics as
`defined ill the standard query. floltever, an update requesting that
`lecolds ol nafl classes'' be replaced is nol supported since a nane
`server can never claim to be authoritative for a node in all classes.
`The eifect of a REPr,Aca opelation is tc updaie the named set of
`records in the zone according to the definj.tion in section 3.4, and
`to distribute the changes to other auLharltatstve nane servers asyn-
`chlonous1y. Note that a REPLACE operation rePlaces a.I1 records of a
`.is corn-
`Epeci:ic nane, class and type by a new set, i.e.
`teplas€llent
`plete, not paltral.
`on rccciving an updote operation, thc aerve!r5 bchavior will dePend
`on whether recursive selvice is requested and available. If recursive
`se!vice is requested and avaitable. the selver detelmiDes the set of
`autho!itative nane servets that can update the specified node. If the
`node e*ists, the !equested se!ver attenpts to update these name
`servers. If the node does not exist or is an a]ias, an errg! is
`!eturned.
`If recur3ive service is not requested cr i3 noL available, then the
`narne server looks trp lhe specified node in onfy those zones for lrhich
`If the nade exists in tbe zone, the update is
`it is autholitative.
`performed. If it can be authoritatively detertnined that the speci-
`fied node does ngL exist o! thal the nane i9 an alias, th€n an er!o!
`is leturned, Otherwise, the name server lefels the resolver to name
`selvers closer tg the autho!ifative zone us-ing name and address
`
`Illp r//$rvrv.ops. icf.or8/lislVrunledtopPervrBrncdroPpers.199Vnrs801302-hurrl
`
`SKYPE.N2PO1603530
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 6
`
`

`

`(tong) DNS dynarnic uDdates draft
`
`7ofl8
`
`Expires JanuarY 15, 1995
`
`INTERNET - DRAF'I
`
`Dynamic DNs updates
`
`lPage ?l
`
`July 1994
`
`information fron
`The algorithn for
`be L ow.
`
`a local zone 9r the cache.
`nane selve! behavior is explai[ed in nore detail
`
`5-1.1. Algorithm
`
`2
`
`A nane selvet behaves as fo.Ilows on receiving a REPIACE operation
`(adapted fron IRFcl034] ) I
`fndlcate in the response whether reculgion i3 availab.Ie or not'
`1
`If requlsive service i5 avai.Iable and requested, tsh€n the server
`uses the local resolver or a coPy gf its algorithn (seclj'on 6l
`to perforrn the update operaLion. otherlrise. go to sLeP 2.
`Sea.rch the available eones fo! the zone which .is the nearese Lo
`QNAME. If no such zone is for.uld, go to step 4. otherwise 9o Eo
`slep 3.
`start natching down, Iabel by label, ir| the zone. Fo! cach
`Label, test fot the following cases:
`If the whole QNF,I{E Ls matched, we have founC the node.
`a)
`If the 'record at Lhe [ode is a CNAME, and QTYPa does not
`natch CNAI4E, return an authoritative !esponse indicat.ing an
`alias error.
`Otherwise, perforn the update operation. Indicate in the
`response that the server is autholj.bative for QNAITE and
`return a successful, !esPonse.
`
`3.
`
`b)
`
`c)
`
`If we have a referral, coPy the NS lecords for the subzone
`into the autholity section oI che leply. copy any addresses
`available fo! the name servers in the additional section,
`using glue records if the addresses are not fron auLhori-ta-
`tive daca or tbe cache' Retutn a non-authoritaLive response
`indicating no e!!or. Exit '
`label, a ftatch is irnpossible (i.e. lhe label
`ff at sorn€
`
`Expiles January 15, 199 5
`
`INTERNET-DRAFT
`
`Dynanic DNs Updates
`
`IPage 8l
`
`tuly 19 94
`
`Irt|p://v$rv.ops.iB|I.ors^isls/narncdroppetymuedmppers.l9g.VrrEgoI302 h0tll
`
`sKYPE-N2P01603531
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 7
`
`

`

`(lo!rg) DNS dynarnic updats draff
`
`8ofl8
`
`Iabel erj-sts. If the
`does noE exj"st), deternine if the'*'
`r*r nane exists, perform the update operation and tetuEn a
`no er!o! response iodicating the server is authoritative
`fo! 0NAl.[8. Otherwj.se, letuln an auCholitative error
`response indicatlng that the nane does not exist. Exit.
`start natching doi,'n in the cache. Look for the best delegation
`fron the cache and put j.t in the authority section, Using LocaL
`data ooly, attenpt to add useful address infornatj.on to the
`addiLional" section. Exi.L.
`
`5.2 . Mainlaining Intelnal consislency
`
`I{e use the exigting nodel to maintain the consistency of nane servels
`responsible for a zone, narnely, that oDIy prinary name serve!s are
`able Lo service an update requestr and thdt the contenCs of a zone
`are transferred to secgDdaries periodically using lhe zoDe Lransfer
`rdechanisn. However, the current zone transfer nechanisn i.3 not
`erpected to be efficient enough in all- case3. Mechanisms that enabl.e
`the prinary to notify a secondary that an update has oqcurred and to
`pe-rform increnenLal ?one transfers are needed to ensure that inlernal
`consj.stency can be naintained efficlentlyIDNS-IXFR].
`
`5.3. Access contlol considerations
`
`Even if an entity has lhe authgrity to update recotds at a particular
`node, it may be desilabLe to contrgl exactly which recotd tyPes ale
`updaleable. For example. it makes no seDse to aflow bosts to add narne
`server (NS) records.
`Thus, a ndme selver 4ay refuse to perfcrn certain updates for policy
`reasons- for e:(ampl€, an authotitative name server may be configuled
`to only service update .reguests on reccrds of a particular type in a
`zone, e,g. onl-y address records.
`
`Exprres ,tanuary 15, 1995
`
`lPage 9l
`
`INTERNET.DRAFT
`
`Dynamj.c DNs upda tes
`
`July 19 94
`
`5,4. Extensions to l,tarne Server Query Beh€vror
`
`only valid records of lhe specified nair.e, class and type should be
`returncd in lesponse to a quely, A reccrd is va-Iid if its etpitation
`tihe is not in the past,
`In addition, the narne serve! lrust set the TTL value of a record to be
`the minilnurn of the tirne left to expirv and the curtent value of the
`TTL.
`
`lrttp://wrvrv-ops. ict-f. org/listJrlalrrcdroppetylrarledroppers. 199x./n$8,01302.h r1
`
`SKYPE.NzPO1603532
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 8
`
`

`

`(lotrg) DNS dynamic updates drafi
`
`9oflE
`
`Expiles January 15, 1995
`
`INTERNET.DRAFT
`
`Dynamic DNS UPdates
`
`6. RESOLVER SEHAVTOR
`
`lPage 101
`
`July 19 94
`
`A !esolver provj.des the application interface to name selvers' A
`resolver nusL enable appl,rcations to perform both standard queries
`and updates. For an update to be successfuf, a resolver mus! updat€
`at leaet one name selve! authoritative for the specified node and
`primary for the zone,
`As witb name 5ervels, some extensigns are needed to resoLver behavior
`uhen perforndng queries because of the inlroduction of record expira-
`tj-on titnes, In this section, we specify resolve! behavior when pe!-
`io-rming updaCes and exEengions to behavior oo standarC queries'
`
`5.1. updates
`
`Thele ale tuq lypes of -Eesol-ver: the stub resolver anC the fufl-
`service tesolver. A gtub resol\,€r pe!forns no reso.Iution functlon
`.rtseli, but rs canfigured vrith a list cf name servels that plovide
`recursive service, i.e. nane servers that can Perforn requests on the
`
`h[p://ww\r.ops. icl|org/listr,/ruunedropp€rtrnrrledtoFpcts.
`
`l9rVtt$801302,1 t
`
`SKYPE.N2PO1603533
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 9
`
`

`

`(long) DNS dynanic updstes draft
`
`l0 of l8
`
`resolver's behalf. A fulL-sefvice lesclver tlavelses the dohain name
`space itselt, possibly querying sevelal. nane selvers, lrhen looking up
`the name servels authoritative for a ncde. Note that, in the case of
`updates, a Stub resolve! nay not actually need !ecursive service
`since a stub legol.ver can be contigured with a .list of prij0ary nane
`servers autholitative for the zones the resalver j.s likely Lo update.
`thj,s is feasible eince typically a stub resolver 9ril1 only need to
`update a Sj.ngle zone in the nane spac€,
`e resolvet nust send a REPUq,CE request to at least one prj.mary name
`server authoritative fo! the specj.fj.ed node, and may send Lo all such
`servers, if nore than gne exists. An update i5 successfuL if at
`.l.east one nane serve! returns an authoritative, error-flee resPonse.
`A fu.ll.-selvice tesolvet pe!forms an updabe operation as follows
`{adapred fron [REc103{] ) :
`If the regolver has sbaled access to zones nanaged by a local
`1.
`nane server, determine if one ot the zones is to be updated. rf
`so, update the relevant zone if the nane exists and is not an
`alias and letutn the response to the client or leturn a oame o!
`alias er!o!/ qtberuise.
`
`Expires January L5, 19-c5
`
`(Paqe l1l
`
`INTERNET-DRAE T
`
`' DynaEic DNs Updd tes
`
`JuIy I9 94
`
`b)
`
`It lhe zone is non-Iocal, find the best servers to ask.
`2.
`Send updates to each DaDe server until one returns a response.
`3.
`4. Analyze the lesPonsc:
`If the response contains a successful autholllative
`a)
`answer, cache the update. Either return the response to the
`client and ettit or delete lhe server flon the list of
`servers and go back to step 3.
`If the response contains an (authoritative) alias ot nane
`er.ror, leturn !esponge to the clicnt.
`If the response contains delegation infollhation, cache the
`delegation information and gc to step 2 '
`If Lhe response shows a selver failure or other bizalre
`conLents, delete the serve! f!ot! the List of servers aDd ga
`back to step 3,
`The data structures used to represent the state of a request in pro-
`gress in the resoLver are che sarne as that speci.fied in RFcl034,
`except that the lj.st tha! represents the lesolve!'s best guess about
`wttich ndme servers to ask should .incLude additj'onal infolnation Per-
`tlhich name servers are Prinary for a given
`tinent to r.rpda tes, e-g.
`zone -
`
`c)
`
`d)
`
`6-2. Extensions to Resol-vet Query Eehavicr
`
`on receiving an anstrer from a quely, a recotd should be tesLed fo!
`
`bIp://rv\vw,ops. ietf.orgnisLvtuuncdroppEtvlutn€doppen.
`
`| 99VDE80I302 1[rrl
`
`SKYPE-N2P01603534
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 10
`
`

`

`(long) DNS dynamic updates draft
`
`l1 of 18
`
`validity. A record is valid if its expiration tine is not in the
`past- Invalid records must not be used or cached.
`A valj.d record may be cached for the specified TTL period, but not
`beyond j,ts expj.raEion tine (Section 3).
`
`Expj.res Januaty 15, 19 95
`
`INTgRNET-DRAFT
`
`Dynamic DNS Updates
`
`.7. SECURITY
`
`IPage 121
`
`July 19 94
`
`The dynanic update nechanisn assulnes thele is DNs suppolt for ensur-
`ing that updates are secure. Data origin authenticaLiqn, integrity
`checks and protection against replays are needed'
`we asel,une that the DNs security hechanisms a3 specified in IDNsgEcl
`ale avail,able. h tbis 3cheme, a sryptcgraphically generated digital
`signature is associated with each record. fyPically, a private key
`associated wlth lhe $,ho.Ie zone wiII be used to sign a1-1 records. By
`learning the public key of the zone (througb DNs or by rnanual confi-
`guration), a resolver can ensure that the !ecolds are authenLic and
`reasonably curlent.
`To perfcrn updateg on records asgociated htith a Dode, the enlity that
`owns the node must have a key. Pllvate or public ).-ey cryptography may
`be used to authenticaCe the uPdater to the authoritatj.ve llame se.rve!.
`The private key apploach neans that an uPdate teceived by an authori-
`tative name selve! tnug! be decrlPted and re-signed using the zone
`private key befqle it is added to the ?one so that other resolvers
`can authenticale the updated record. Since signing of zone records by
`DNs servels is iDtended to be an off-Iine and Perj-odic activity
`tor
`efficiency and seculity rea9ons, the use of plivate keys is not
`recohmended. In the public key approach, the updated !ecords a!e
`signed with the enLity's private key and can be storeC in DNs
`directty. The entity's public key, signed by the zone key, nu3t
`itsel: be adveltised in DNs.
`Associated v,rith each signature ls the time sj.gned and the signature
`expiratian time. The time signed is used Lo protect agaj.nst replays,'
`recold update3 Inust only be accepted by a serve! if Ehe signaturc
`tinestarnp is later than that of the current signature. The signatute
`expiration time indicates Hhen the signature is no longer vaIid, and
`bence that the signed recotds can Do Icnger be considered aulhentic.'
`The dynarnic updale nechanism uses this fj.eld to indicate tbe eripila-
`tion titne of the, signed tecold as well IDYNDNSIHPL] .
`
`hIp://$'!yw,ops.ictf.orglli5l.Vnarrcdtopp€rylwll€droppe]s.
`
`l9g.VnEgol302.htinl
`
`SKYPE-N2P01603535
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 11
`
`

`

`(lon8) DNS dyrumic uPdates dnfi
`
`l2 of l8
`
`Expires JaDua!y 15, 19 95
`
`INTERNET-DRAFT
`
`Dynaniq DNs UPdates
`
`8. EXNXPLDS
`
`lPage 131
`
`,tul y 1994
`
`In this section, we describe variaus examples of holt a host night
`acqulre a domain natne and addtess in scne typicaL operaling envj.lon-
`ments, and how the nane and address nappings ale uPdated in DNs.
`
`E.L Using DltcP to aequile nalre and address
`
`DHCP
`server
`
`PTR, A
`
`DNS
`
`nane, addr from DnC P
`
`Host
`
`A DHCP server nay be configured to return a domain name (and othet
`confj.guratioo informaLion) in addition to an address on an assig nent
`reque;t, In lhls case, the DSCP selver is resPonsible fo! ensurinq
`that both the A and corlespondilg PTR teeolds are plesent and culrent
`i.n DNS. The DHCP servc! Inust have the nece3sary key(s) to update the
`nodes it admini.stels io the zone.
`The DHCP server can be qonfigured to associate a domain name with a
`speciiic host, in $,hich case Ehe host j.s always teturned the same
`domain nane lassuming the DHCP database j-s not cbang€C), or the
`domain nane can be associaled trilh the host'3 address, ln !'Jhich case
`the donain nane changes along HLtlt the address. the filst node of
`opelation i3 fea5ible for host5 that are pelnanently adrninistered by
`sone entity, have an assigned domain name administereC by thj.s
`entity, but the nane is not (yet) locally configured/ e'9. because
`
`Expires January 15, l9-c5
`
`TNTERNET.DRAFT
`
`Dvnamic DNS Updates
`
`IPage 141
`
`,tuly r 994
`
`lllp://wrv\v.ops.ie t-f.ory/lis(vrwtrcdropFtvlBltredmppeIs.199M1|s90l302.holll
`
`SKYPE.N2PO1603536
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 12
`
`

`

`(long) DNS dynamic updates draff
`
`l3 of 18
`
`the host is diskJ"ess. the second forn of operation suits what r,e
`have calfed the ''laboratoly" envixonlten!, in v,hich hosts bav€ no per-
`nanent hgme ad.ninistraLi.on and thus need to be assiqned a nane
`aut.omatical.l,y.
`
`8, 1.1- The Labqlatary EnvirqruleBt
`
`In the laboratory enviloment, different anonyrnous hosts are plugged
`into the game network for short periods of tine during the day, e.g.
`students use the laboratoly to pfug in laptop cohputers for the
`length of a c.Iass. It is the lesponsibilily of a DHCP server to allo-
`cate an unused address and donain nane to a host on request, but need
`noL, r.n chis envirolunent, ensure that the same host gets tbe same
`narne and address each Cine lhe host plugs inEo the net!,to!k.
`In thrs case, Lbe systen administrato! nay preconfigure tbe DNS
`name-to-address and invelse lookup zones for Lhe laboratory by
`enumelating al1 possj.ble IP addresses and their natching "temporary"
`dornain names, Por exaople, guppose the laboratoly netttork had a net-
`v,rork prefix of l-29.96.45 wich a mask of oXEFFFEF and a donarn nane
`suffix of xyz.con. Then the zone donain file nay f,ook as tollows:
`
`rnacl. xyz. con
`nacz . xyz. coln
`mac3. xyz . con
`
`IN
`IN
`IN
`
`A
`A
`A
`
`128.96.45.1
`r28 .96 .45 .2
`128 .96.45 .3
`
`mac254.xyz-com IN
`
`128.96.45.254
`
`and the zone invelse lookup fife nay look as folloHs :
`
`1, 45. 96. r28. in-addr -alpa-
`2 .45.96.L2A . irL-add! . alpa.
`3 , 4 5. 96. 128 . ln-add! . alPa.
`
`IN
`IN
`IN
`
`PTR
`PTR
`PTR
`
`nac1.xyz.con.
`nac2.xyz.con,
`nac3.xyz.con.
`
`2 54 - 4 5 . 96 .128. in-addr. arPa .
`
`IN
`
`PTR
`
`mac2 511 . xyz. cgn.
`
`Expires ,Ianuary 15, l9 95
`
`lPage 151
`
`INTERNET_DRAFT
`
`Dynanic DNs Upda tes
`
`July 1994
`
`The host uses the DHCP selve! !o acquire a domain name and addless in
`th-is case- On receipt of a host request fot aD addless, the DIICP
`server chooses an avail.abLe addtess, .lcoks up th€ corresponding
`donain nane in DNs and retulns both the nahe and addtess to the host'
`In thi3 ca9e, the host need not update DNS at alL to advertiee the
`nane and 6ddre3s nappings. rhe DHCP server nay need to update the DNS
`server to extend the expilation tj.ne ot the A and gTR records, either
`when the mappings are reassigDed or the lease tine is renewed. The A
`and PTR records in the zone should exPire befoEe the DHCP lease dges.
`
`l lp://wrvn.ops.ietLorgAistvrHnrcdropDergrwDedropp€Is.
`
`t99Vnrsgoli02.hrnl
`
`sKYPE-N2P01603537
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 13
`
`

`

`(loDg) DNS dynamic updd€s draJt
`
`14 of l8
`
`a.2. Pelmanen! narne and updateable address
`
`In the fol.loning exanples, a host has been assigned a permanent
`doDain nane i{hich has been .Iocally contiguled. only the address needs
`to be acquired dynanicaf 1y.
`
`Expir€s January J. 5, 1995
`
`INTERNET-DMFT
`
`Dynanic DNs Updates
`
`8.2.1, Using DIICP to acqui.re an address
`
`lPage 151
`
`July 1994
`
`DS
`serve!
`
`DHCP
`
`DNS
`
`address,
`Dame
`
`tl
`I Host I
`
`t(p://rv\v\f.ops. ictf.orgnisls/r|alnedfopp€rvruJuedreppeF.
`
`l99.Vll$901302, hlrnl
`
`SKYPE.N2PO1603538
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 14
`
`

`

`(lond DNS dynamh uPdates dtatl
`
`15 of l8
`
`In this envirqnnent' a host, ilhenever j.t acquires an address from a
`DHCP setve!, requests an autholitative DNs gelver to update lhe
`nane-to-address napping. The DHCP server is responsible fo! updating
`the j.nverse napping, Note thac the naEe selver autholitative for the
`name-to-addless napping tlay be adninistered by an authority diffelent
`from that for the addrese-to-Dane mapping.
`Suppose the host's donaiD Dalne has been preconfigured in DNS and the
`host has been given the necessary secutiLy clealance to updaee
`records asgociated ltith tbi.s nafie. Assume furthe! that the DHCP
`selve! has the necessary security clearance tq update all lhe inverse
`(FtR) nappings ot addresses .it is lespcnsj.bfe fo!, anC that the
`donain nanes corlesponding Lo these addresses exist in the inve!se
`lookup (IN ADDR.ARPA) do$ain. From a plactical Point of vlew, the
`inverse ]ookup narnes nay be enunelated implicitly using the DNS ltild-
`cald labe.I, denoted by r*'.
`if explicj.t ensutneration is no! feasible,
`iIDpIicit enrnneratioD, it is the responsibifity of the
`Note that tith
`antity pe!fqltning the updates to ensure that inve!se .lookuP naDes are
`
`Expires ilanuary 15, 1.995
`
`INTERNEl_DRAFT
`
`Dynamic DNs Updates
`
`lPage 1?l
`
`July l9 94
`
`unrque.
`Once the host acquj-res an addless f!or. the DHCP se!ve!, it requests
`DNs to replace the old existing addregg lecords, if any' with the new
`up-to-date set of add.ress reco.rds in the appropriate zone. 8y the
`sane token, uhenever a new address is Leased tg a host, the DECP
`server tequests DNs to leplace the existlng PTR mapping, if any, $rith
`the hostrs domain nane- Note lhat the hosl nust pass its donain nane
`tg DHCP tdhen requesting an address as explained in Section 3'3.
`(curlently, there is no nechanisn tg dc this in DHCP, bu! a simPle
`exeension would suffice,) Both the DHCP server and the host should
`se! the expj.tation time of the ne!., reccrd to occ\lr before the lease
`expj.res. The expiratioo tine Sbould be reset whenevet the lease tlme
`is renevred.
`Nole that this node of operation i5 suitabLe indePendent of Lhe
`host's Location aL the tlme of the DHCP lequest' The host nust con-
`municate riith a DHCP sexver that is !esponsible fo! managing the
`address space of the network to $thich the host is ettached. Thus, a
`portable host may conmunicate r,rth DHcP selver5 !un by diJlerent
`adninrstrations.
`
`8.2 ,2 , Using Router Advertisements
`
`In ES-IS, a host forms an addrcas by listening to a lioutet advellise-
`rnent of a netvrork prefix and concatenating tttis with an idenlifier
`that uniquely names the host (at least wiLhin the scope of the net-
`In this case, the rgute! I'owns" the network plefjx
`work plefix).
`while the hosL "owns" the identifier. Having the host be lesPonsible
`tor updating bath che name-to-address and inverse tnappings r'rould
`
`lrtlp;//wrvrv.ops.icd.orS/lislyrrur|edropp€tgr|aInedropFrs.
`
`| 99vrrE80 I 302. ltunl
`
`SKYPE-N2P01603539
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1006 - Page 15
`
`

`

`(long) DNS dymmis uldates droft
`
`l6 of l8
`
`require significant precontiguration especially if the hosl is po!t-
`able and untrusted. Ilence. we lequire that the host advertise both
`i.ls addlegs and ile donain nam€ to the route.r and that the router
`update the inverse napping.
`Note that an address assigdnent nechanisn has been propgsed as an
`extensj.on to Es-rs IIsog542AMll . Like DEcP, this service needs to p!o-
`vide a nechanisn Eo enabl.e a bost to comunicate its donain nane tg
`lbe selvgr so that the invelse Dapping can be updated when an address
`r5 assrgned.
`
`Expires January 15, 1995
`
`lPage 181
`
`INTERNET-DRAFT
`
`Dynamic DNs update5
`
`,luly 1994
`
`9. ACIdOT{LEDGEMENTS
`
`we r.rould Iike to aclnowledge the contlibutions of Jesse walker (DEc)
`
`IO. REFERENCES
`
`tRFC103{ |
`P, ltockapetrisr "Donain Narnes - Ccncepts and Facifities'r, RFc
`1034, Usc/Infolmation sciences Institute, Novenicer 198'1.
`
`tRFCl03sl
`P. Moqkapetlis, "DoDaj.n Names - Ir,plenentaLign and specifica-
`tj.on", RFc 1035, usc/Intornation sciences rnstitute, Novenbe!
`198?.
`
`lRFc 15 31 I
`R. Drorns, nDynatnic ltosl configuration ProLocol", RtC 1531, BucL-
`nell university, october l9 93.
`
`Irsog s4 2l
`ISO, "End systern !o Internedi