Embed Size (px)
Citation preview
Reference Architecture, Models and Metrics
Autors: E.Casalicchio, M. Caselli, D.Conrad, J. Damas, I.Nai Fovino
!"#$%&'()*&+,-"'.) !"#"!)/$(0"+,.) $"%&'&()**+),-./".%&'0(()-.1"%,23&4-.5".
1&6&'-.7"8&).9,:)2,)1"'(&'(.) ;0<0302*0.=3*+)>0*>?30-.6,40('.&24.
60>3)*')2&34(&5)6+"7&#(.) /02'&)!4(&.) !@ABCADB!!)1"%%&'(,.) 888)
))
))
))
)))
))
))
)
)
))
)94:3&)";)#"'(&'(,
)
<! =>=1?9@A=)B?CC/2D) E!
F! 9G=)2=H=2=I1=)/21G@9=19?2=) E!
FJ<J! !IB)KLLM?N)CL!=K) E!FJFJ! B9?O)2=BLKA=2P/NNK@1/9@LI)9L)1/1G=)!IB)KLLM?N) Q!FJRJ! 2=BLKA=2)9L)/?9GL2@9/9@A=)B=2A=2)KLLM?N) S!FJEJ! H?KK)!IB)2=1?2B@LI)/I!)1/1G@IT) U!FJQJ! 2=BLKA=2)N2@C@IT)V?=2D) W!FJXJ! H2/TC=I9/9@LI)/I!)92?I1/9@LI)@I)9G=)KLLM?N)N2L1=BB) W!FJSJ! !IBB=1)A/K@!/9@LI)@I)9G=)BDB9=C) <Y!"#$#%#! &'()*(+,-!.,/0)0!'1!2*00).!3,-+2,(+'*!1,+-/4)! %%!
R! 9G=)1LCNLI=I98O/B=!)CL!=K) <F!
E! CL!=K)/I/KDB@B) <E!
EJ<J! 9G=)=I!8?B=2)NLA) <Q!EJFJ! 9G=)/BN)NLA) <Q!EJRJ! 9G=)2=BLKA=2)NLA) <X!EJEJ! 9G=)I/C=)B=2A=2)NLA) <X!EJQJ! 9G=)ZLI=)NLA) <S!EJXJ! 9G=)TKLO/K)!IB)NLA) <S!
Q ! 9G=)NLA)/NN2L/1G)9L)C=92@1B)=A/K?/9@LI) <U!
X! C=92@1B)C/NN@IT) FY!
XJ<J! C=92@1B)C/NN@IT)=>/CNK=) FF!
S! O@OK@LT2/NGD) FX!
< =[&#$(-*&)B$%%4+\)
The DNS is a complex distributed system, a system of systems composed of a highly interconnected infrastructure, protocols and operations procedures. Measuring the Health and Security (H&S) level of this system and investigating its potential weaknesses is a question of crucial interest [5][4]. The lack of a common and formalized standard for the protocol’s evaluation and the related absence of specific metrics is a gap needing to be filled. To study such a complex system it is important to define the boundaries of the investigation and a model to drive the system analysis. The goal of this document is threefold.
First, we introduce the reference architecture and models describing the portion of the DNS we will study in this first project phase.
Second we propose an analysis approach for health and security evaluation and measurement.
Third, we propose an approach to isolate metrics that can be used to quantify the health and security level from a specific point of view. The document is organized as follows: Section 2 describes the reference architecture. The reference architecture is intended as a process-based model that describes what are the main DNS operation processes, what are the actors involved in these processes and what are the successful end conditions for each process. Section 3 proposes a component based model that isolates the different actors and components involved in the DNS operation. Section 4 proposes an analysis approach that identifies the more important point of view for the evaluation of the health and security level of the DNS. Section 5 discusses how the PoV analysis approach can be used, along with the process-based model to indentify the measurable metrics to quantify the health and security indicators.
F 90&)+&;&+&'#&)4+#0-(&#($+&)
FJ<J !IB)K""]$6)C"5&3)
The DNS system is composed of several instances of different types of components, each performing a specific type of task in a DNS lookup or information retrieval for an application. At the start of a DNS lookup we find what is called a stub resolver, typically instantiated in the form of a DNS library provided by the host operating system and used by an application.
While stub libraries are getting increasingly complex, for instance combining resource lookups outside DNS with the DNS lookups (e.g., Apple’s Bonjour) and may provide a local cache, presently these libraries are accessed via standardized or platform-dependent APIs that provide basic services such as name to address mappings and require access to a full resolver (or a forwarder) in the network. The stub resolver typically communicates over a network with a forwarder or a full-resolver (which we will call simply a resolver from here onwards) and requests DNS information. The resolver (or forwarder) is then tasked with fulfilling the request, either by performing a series of DNS lookups on the Internet or, in the case of a forwarder, forwarding the request on to a resolver. Forwarders are used mainly to provide additional caching facilities and to control load on resolvers. Figure 1 shows a diagram outlining a typical DNS lookup and the network traffic involved as a request initiated by a stub resolver triggers a resolver to issue several DNS lookups down the DNS tree. If the resolver has a cache some of these lookups may not be necessary for all queries, eliminating some of the items in the diagram. However, this does not alter the iterative nature of the process or its essential properties, rather the use of the cache merely alters the number of iteration that need to be performed.
Figure 1 A diagram of a full DNS lookup.
In the next sections each stage in the process of a complete DNS lookup is analysed separately, including an analysis of the role of a cache in a resolver. This last item is done separately to highlight the optimisations and pitfalls introduced by a cache.
FJFJ B($:)+&,"3*&+P4663-#4(-"')(")#4#0&)!IB)3""]$6)
An application1 queries for a <name,class,type> tuple that already exists in the cache. It is assumed that the response does not require TC to be set (that is, the response fits within 512 bytes or the buffer size advertised in the EDNS0 header in the request).
%!+5!6789!:;56<=6!67<!6<>?!@ABBC8:A68;5D!89!6AE<5!6;!?<A5!67<!:;?F85A68;5!;G!;B<>A685H!9I96<?J!C8F>A>8<9J!A5K!ABBC8:A68;5!:;K<!67A6!89!?AE85H!A!2*0!LM<>I#!
!"#$%&'(&'!"#$%&'(&'!"#$%&'(&'!"#$%&'(&'
)*+,-*.&
/&+01(&'/&+01(&'2
/00,$%&'(&'/00,$%&'(&'/00,$%&'(&'/00,$%&'(&'$
)*+,-*.&
3"#$%&'(&'3"#$%&'(&'3"#$%&'(&'3"#$%&'(&'
3"#$%&'(&'3"#$%&'(&'3"#$%&'(&'*"#$%&'(&'
45512.-,20*
6
7
668
3
9
:;
<
=>
6?
636;
6<8@;
8@6
8@3
8@9
8@<
!Figure 2. Application queries for name in cache. The resolver does not need to issue queries over the network and the lookup process is limited to the interaction between application (stub) and
the resolver. The behaviour of caches is analysed later. Step 1: Application sends query to resolver instance Resolveri Success depends on:
• *M?F<>!;G!><9;CN<>9!ABBC8:A68;5!E5;O9!AF;M6!• ,BBC8:A68;5!><9;CN<>!9<C<:68;5!ACH;>867?!• 4<A:7AF8C86I!;G!Resolveri!G>;?!ABBC8:A68;5!
o -AI<>!"!P+&NQR+&NST!A5K!-AI<>!U!P/2&R(.&T!o V8KKC<F;=!9MBB;>6!G;>!2*0!G<A6M><9!P<#H#!:C8<569!O867!)2*0!;5T!o +56<>?<K8A6<!G;>OA>K<>9!P<#H#!B>;=8<9!85!20-!>;M6<>9T!
Step 2: Resolveri receives query Success depends on
• WM<>I!5;6!F<85H!:;>>MB6<K!;>!K>;BB<K!85!6>A5986!• Resolveri!5;6!F<85H!;N<>C;AK<K!
o (7<!?;96!:;??;5!:;56<568;5!B;8569!G;>!6789!B>;:<99!A><!67<!'0!5<6O;>E!LM<M<RFMGG<>!9I96<?!A5K!67<!2*0!9<>N<>!856<>5AC!6A9E!LM<M85H!9I96<?#!
Step 3: Resolveri responds from cache for answer to query Success depends on:
• (8?<!985:<!CA96!A59O<>!6;!LM<>I!G;>!5A?<!><:<8N<K!o &><9<5:<!;G!ACC!<C<?<569!5<:<99A>I!G;>!GMCC!><9B;59<!ANA8CAFC<!85!:A:7<!
• .A:785H! 9<>N<>! :ABAF8C868<9! 8G! ><:;>K! 9I567<989! 89! 5<:<99A>I! P<#H#! .*,V)! G>;?!2*,V)!85!:A:7<T!
• 4<A:7AF8C86I!;G!K<9685A68;5!;G!><9B;59<!P0<<!AF;N<J!96<B!%T! Step 4: Application receives response to query Success depends on:
• 4<9B;59<!5;6!F<85H!:;>>MB6<K!;>!K>;BB<K!85!6>A5986!• ,BBC8:A68;5R'B<>A685H!9I96<?!5;6!F<85H!;N<>C;AK<K!• ,F9<5:<!;G!?AC8:8;M9!><9B;59<!><A:785H!ABBC8:A68;5!F<G;><!C<H868?A6<!><9B;59<!
o &>;6<:68;5! ?<:7A589?9! K<BC;I<K! P/2&! B;>6! >A5K;?8XA68;5J! 2*0! +2!G8<CKT!
o (IB8:ACCIJ! A6! 6789! 68?<J! 5;! 2*00).! NAC8KA68;5! 89! B<>G;>?<K! A6! 67<!ABBC8:A68;5! C<N<C! 9;J! 85! H<5<>ACJ! 2*00).! :A55;6! F<! :;M56<K! MB;5! 6;!B>;6<:6!67<!856<>A:68;5!F<6O<<5!A5!ABBC8:A68;5!A5K!67<!><9;CN<>!86!M9<9#!
!"#$%&"'!"#$%&"'(
)**%(+,-($.
/
01
2
FJRJ 2&,"3*&+)(")4$(0"+-(4(-*&),&+*&+)3""]$6)
As the minimal label length for a valid domain name (excepting the root) is at least 1 octet and the total length of a domain name (including label separators) is 256 octets, the maximum depth of recursion (n) is 127, in the absence of loops or redirections (e.g. CNAME and DNAME).
!Figure 3 Elements of DNS recursion. The bubble encloses the interaction between a resolver and
an authoritative server. Step 3: Resolveri sends query to authoritative server instance Success depends on:
• 4<9;CN<>!AM67;>86A68N<!9<>N<>!9<C<:68;5!ACH;>867?!• 4<A:7AF8C86I!;G!AM67;>86A68N<!9<>N<>!8596A5:<!G>;?!><9;CN<>!
o -AI<>!"!P+&NQR+&NST!A5K!-AI<>!U!P/2&R(.&T!o V8KKC<F;=!9MBB;>6!G;>!2*0!G<A6M><9!P<#H#!G8><OACC9J!C;AK!FACA5:<>9T!o +56<>?<K8A6<!G;>OA>K<>9!P<#H#!B>;=8<9!85!20-!>;M6<>9T!
Step 4: Authoritative server instance receives query Success depends on:
• WM<>I!5;6!F<85H!:;>>MB6<K!;>!K>;BB<K!85!6>A5986!• ,M67;>86A68N<!9<>N<>!8596A5:<!F<85H!;N<>C;AK<K!
o 0A?<! B;6<568AC! :;5H<968;5! 986MA68;5! <=8969! A9! 85! 67<! :A9<! ;G! ><9;CN<>9!AF;N<#!
Step 5: Authoritative server instance responds with referral to TLD name servers Success depends on:
• 4<A:7AF8C86I!;G!><9;CN<>!9;M>:<!AKK><99!• Y;5<!KA6A!F<85H!ANA8CAFC<!A6!67<!AM67;>86A68N<!9<>N<>!G;>!67<!><:<8N<K!LM<>I!
o ,! ><9B;59<! G>;?! A5! AM67;>86A68N<! 9<>N<>! 67A6! O8CC! <5AFC<! 67<! C;;EMB!B>;:<99!6;!:;5685M<!?AI!:;56A85!<867<>!
! (7<!A59O<>!6;!LM<>I!G>;?!C;:AC!X;5<!KA6A!! ,!><G<>>AC#!+G!67<!AM67;>86A68N<!9<>N<>!K;<9!5;6!9<>N<!67<!X;5<!67<!
LM<>I!><G<>9!6;J!86!?AI!:;56A85!85G;>?A68;5!AF;M6!A!K<C<HA68;5!6;!A!K;?A85!67A6!89!?;><!9B<:8G8:!67A5!67<!C;:ACCI!9<>N<K!;5<!67A6!O8CC!B;856!67<!C;;EMB!B>;:<99!85!67<!>8H76!K8><:68;5!6;!GMCG8CC!67<!C;;EMB!
!"#$%&'(&'!"#$%&'(&'!"#$%&'(&'!"#$%&'(&'
)*+,-*.&
/&+01(&'/&+01(&'2
/00,$%&'(&'/00,$%&'(&'/00,$%&'(&'/00,$%&'(&'$
)*+,-*.&
3"#$%&'(&'3"#$%&'(&'3"#$%&'(&'3"#$%&'(&'
3"#$%&'(&'3"#$%&'(&'3"#$%&'(&'*"#$%&'(&'
45512.-,20*
6
7
668
3
9
:;
<
=>
6?
636;
6<8@;
8@6
8@3
8@9
8@<
! (7<! AF9<5:<! ;G! <867<>! ;G! 67<9<! ;B68;59! H<5<>A6<9! A! 986MA68;5!K<G85<K! A9! A! CA?<! K<C<HA68;5! 8G! 67<! ><9;CN<>! ><A:7<K! 6789!AM67;>86A68N<! 9<>N<>! G>;?! A! B><N8;M9! ><G<>>AC#! (789! 89! A!?89:;5G8HM>A68;5!;G!67<!2*0!9<>N<>9!67A6!89!9;?<O7A6!G><LM<56CI!;F9<>N<K!85!67<!2*0#!
Step 6: Resolveri receives response Success depends on:
• WM<>I!5;6!F<85H!:;>>MB6<K!;>!K>;BB<K!85!6>A5986!• Resolveri!5;6!F<85H!;N<>C;AK<K!• 4;M685H! 96AF8C86I! 9M:7! 67A6! ><9B;59<! G>;?! 67<! AM67;>86A68N<! 9<>N<>! A>>8N<9! A6!
><9;CN<>!8596A5:<!!!• ,F9<5:<!;G!?AC8:8;M9!><9B;59<!><A:785H!ABBC8:A68;5!F<G;><!C<H868?A6<!><9B;59<!
o &>;6<:68;5! ?<:7A589?9! K<BC;I<K! P/2&! B;>6! >A5K;?8XA68;5J! 2*0! +2!G8<CKT!
o +G!2*00).!NAC8KA68;5!89!<5AFC<K!85!67<!><9;CN<>J!2*00).!:A5!B>;N8K<!A5!<GG<:68N<! OAI! 6;! B>;6<:6! 67<! 856<>A:68;5! F<6O<<5! A! ><9;CN<>! A5K! A5!AM67;>86A68N<!9<>N<>#!(789!?<:7A589?!89!<=BC;><K!CA6<>!85!6789!K;:M?<56#!
FJEJ H$33)!IB)+&#$+,-"')4'5)#4#0-'^)
Application queries an empty cache for a <name,class,type> tuple. It is assumed that the resolver has executed a priming query successfully, thus the IP addresses for the root servers are accurate. It is also assumed that all responses from the authoritative servers (and the response from the resolver to the application) do not have the TC bit set.
Figure 4 Application queries empty cache for name Full recursion is the sequential composition of the previous individual lookups. There is scope for interactions between the individual lookups through the fact that resolver cache gets modified by information obtained from lookups in lower parts of the DNS tree. That is, the cache is not only augmented by new information, it is also altered as some records, for instance NS records, have precedence in the lower branches of the DNS tree (child zones) over the higher ones, even if the information must be present in the higher branches to enable the system to function. It is not
!"#$%&'(&'!"#$%&'(&'!"#$%&'(&'!"#$%&'(&'
)*+,-*.&
/&+01(&'/&+01(&'2
/00,$%&'(&'/00,$%&'(&'/00,$%&'(&'/00,$%&'(&'$
)*+,-*.&
3"#$%&'(&'3"#$%&'(&'3"#$%&'(&'3"#$%&'(&'
3"#$%&'(&'3"#$%&'(&'3"#$%&'(&'*"#$%&'(&'
45512.-,20*
6
7
668
3
9
:;
<
=>
6?
636;
6<8@;
8@6
8@3
8@9
8@<
uncommon to find discrepancies in information that pertains to the same items at the different levels in the tree. Success depends on:
• )A:7!;G!67<!85K8N8KMAC!96<B9!B><N8;M9CI!K<9:>8F<K!• (7<!AF9<5:<!;G!CA?<!K<C<HA68;59!P?89:;5G8HM>A68;59!C<AK85H!6;!K<AK!<5K9!85!67<!
C;;EMB!BA67T!
FJQJ 2&,"3*&+)6+-%-'^)_$&+\)
Upon startup DNS resolvers usually issue a first query, even in the absence of any client queries, called the priming query. In this process resolvers select one address from a list of root servers bundled with the DNS server software and request from the selected server an updated list of all the root servers. This is akin to the boot/reset vector that enables computers to start operating when powering up. The inability of a resolver to succeed in getting answers to priming queries can result, depending on the software, in defective operation. Stale initial lists can lead to a situation where no root servers are reachable and therefore no DNS lookups can be successfully performed. Special care is taken by the operators of the root servers system to ensure that changes in the list of root servers or the introduction of new capabilities (such as IPv6 addresses for root servers) have as little impact as possible in the system as a whole. Success of a priming query usually depends on:
• 4;;6!9<>N<>!><A:7AF8C86I!A5K!ANA8CAF8C86I!• ,6!C<A96!;5<!:M>><56!>;;6!9<>N<>!F<85H!B><9<56!85!67<!F;;6!C896!
FJXJ H+4^%&'(4(-"')4'5)(+$'#4(-"')-')(0&)3""]$6)6+"#&,,)
DNS includes mechanisms to allow a DNS server (authoritative or resolver) to indicate to its respective client (application or resolver/forwarder) if it could fit all the required answer information in the reply packet. DNS was originally defined with a limit of 512 bytes on the message size when using UDP (not so when using TCP). Since then DNS has been extended (RFC 2671) to enable use of longer messages over UDP using a mechanism called EDNS, which enables messages of up to 64K bytes, however the typical size is limited to 4096 bytes. If a DNS message must contain an amount of information that exceeds the EDNS specified limit (if present) or 512 bytes (if EDNS is not present), the DNS server must set the TC bit in the reply to indicate to the client that the message is truncated, allowing a recovery mechanism to attempt recovery (usually DNS over TCP). Success of recovering from a truncated message depends on:
• 4<A:7AF8C86I!;G!67<!2*0!9<>N<>9!;N<>!(.&!• V8KKC<F;=<9!ACC;O85H!BA:E<69!O867!67<!(.!F86!9<6!6;!6>AN<>9<!67<?!• ,NA8CAFC<!(.&!><9;M>:<9!;5!67<!9<>N<>Z9!98K<#!(7<9<!><9;M>:<9!A><!M9MACCI!?;><!
:;596>A85<K!67A5!/2&!><9;M>:<9#!
When using EDNS a UDP message can exceed the maximum transmission unit (MTU) of the layer 2 networks it traverses, resulting in fragmentation of the UDP packets, either in transit (IPv4) or at origin (IPv6). This fragmentation results in the initial UDP packet being followed by one or more UDP packets that contain the remaining message fragments. Success on receiving a fragmented UDP message depends on:
• V8KKC<F;=<9! A::<B685H! A5K! ACC;O85H! 6>AN<>9AC! ;G! /2&! G>AH?<569#! [78C<!G>AH?<56A68;5! 89! A! 96A5KA>K! +56<>5<6! &>;6;:;C! 0M86<! ?<:7A589?J! 86! 89! 5;6!M5:;??;5!6;!<5:;M56<>!?8KKC<F;=<9!67A6!B>;78F86!6>AN<>9AC!;G!/2&!G>AH?<569\!
• *;5]?AC8:8;M9!85^<:68;5!;G!GAC9<!/2&!G>AH?<569#!/2&!G>AH?<569!A><!?;><!C8AFC<!6;!?AC8:8;M9!856<>G<><5:<!67A5!67<!G8>96!G>AH?<569#!
FJSJ !IBB=1)*43-54(-"')-')(0&),\,(&%)
DNSSEC, which is a set of extensions to the DNS protocol suite that allow for data integrity verification, data origin authentication, and provable denial of existence of DNS data, adds significant complexity to DNS operations and DNS server implementations (particularly resolver implementations), and changes the way DNS resolution is performed. We assume the validating resolver starts with a trust anchor for the root zone, in the form of a pre-configured Delegation Signer (DS) or DNSKEY resource record. Upon startup, the validating resolver queries the root servers for the set of DNSKEY RRs in the root zone (the root DNSKEY RRset), then checks whether this configured DNSKEY RR is present in the that RRset, whether the pre-configured DNSKEY RR has signed the root DNSKEY RRset, and whether the signature lifetime associated with the pre-configured DNSKEY RR has not expired. If all of these conditions are met, all keys in the root DNSKEY RRset are considered authenticated. When getting a referral to a TLDs DNS servers as part of the resolution process as described earlier, the validating resolver then attempts to fetch the TLD’s DS RRset from the root and uses one or more of the root DNSKEY RRs to authenticate the TLD’s DS RRset. In order for these DS RRset to be used, it must be correctly signed (non-expired signatures using the root zone keys are available). Once the TLD’s DS RRset has been authenticated using the root DNSKEY, the validating resolver checks queries the TLD’s DNS servers to obtain the DNSKEY RRset and look for one of the TLD’s DNSKEY RRs that matches one of the TLD’s authenticated DS RRs. If a match is found, the validating resolver knows whether the matching TLD’s DNSKEY RR has signed the TLD’s DNSKEY RRset and that the signature lifetime is valid. If these conditions are met, all the keys in the TLD’s DNSKEY RRset are considered authenticated. This process is repeated as resolution progresses down the DNS tree with the (signed) DS Records, and their corresponding signatures, at each level providing the validation link in a manner parallel to that indicated by the domain delegations at each step, as indicated in the previous section. Figure 5 shows the parallel chains in the DNS with DNSSEC. On the left side the normal DNS delegation tree and on the right side the parallel trust tree or chain introduced by DNSSEC. Also shown is a link introduced by the DLV mechanism.
Figure 5 DNSSEC establishes a link between zones that is parallel to the normal DNS delegation chain, called the trust chain. DLV can further complicate matters by introduing additional entry
points into the normal trust anchor graph For DNSSEC enabled resolution, with validation, to succeed, both links must be valid at each of the resolution steps down the DNS tree. Two additional features complicate this process:
• +9CA5K9!;G!9<:M>86I!A><!BA>69!;G!67<!2*0!6><<!67A6!A><!2*00).!9<:M><K!FM6!K;!5;6!7AN<!A!:;5685M;M9!2*00).!9<:M><K!C85E!G>;?!67<!>;;6!X;5<!6;!67<?#!+5!;>K<>!G;>!67<9<!6;!F<!NAC8KA6<KJ!67<!AK?85896>A6;>9!;G!67<!><9;CN<>!?M96!:;5G8HM><!<=BC8:86!AKK868;5AC!E<I9!67A6!B>;N8K<!6>M96<K!<56>I!B;8569!856;!67<9<!89;CA6<K!9MF6><<9#!!
• 2-3! 89! A! 9<BA>A6<J! BA>ACC<CJ! C;:AC! B;C8:I! ?<:7A589?! ANA8CAFC<! 85! 9;?<! 2*0!><9;CN<>RNAC8KA6;>9! 67A6! B>;N8K<9! A! 9<?8]AM6;?A68:! OAI! 6;! ?A5AH<! ?MC68BC<!89CA5K9!;G!9<:M>86I!A5K!67<8>!:;>><9B;5K85H!E<I9#! +6! 89!A5!<A>CI!K<BC;I?<56!A8K!A5K!5;6!H<5<>ACCI!:;598K<><K!A!B>;KM:68;5!;B<>A68;5AC!6;;C#!
With the signing of the root zone in mid 2010, this specialized behaviour is discouraged and should only be used with full knowledge of the additional complexity introduced.
FJSJ<J N"(&'(-43)#4$,&,)";)!IBB=1)*43-54(-"');4-3$+&)
DNSSEC introduces several new processes that need attention from the zone administrators as well as the resolver operators. In first place, DNSSEC introduces a sense of temporality in the DNS because the signatures generated over the RR Sets have inception and expiry dates. That is, they are associated with time intervals during which they are valid and outside which they are invalid. Before DNSSEC, no DNS records have any temporality associated to them.
Names DNSKEYRoot Zone
Trust anchor
Names DNSKEYTLD Zone
Names DNSKEYSLD Zone
NS
NS
DS
DS
DLV Repository
DLV
AlternateTrust anchor
Failure to renew expiring signatures with fresh ones leads to validation failures This is a significant change in the model of DNS zone administration. In second place, the keys themselves are subject to utilisation policies, around which there is, at this time, no clear definite recommendation. Administrators need to be aware of the risks associated with key management and establish a key utilisation policy for their zones, always keeping in mind the sense of proportionality involved in all security decisions. Key roll-over, or the replacement of old keys buy new keys, is a delicate process that needs attention when carried out, in particular for the case or Key Signing Keys (KSKs) since a new set of DS Records will need to be generated and sent to the parent zone to replace the DS Records corresponding to the keys that are being retired. In the absence of this step, the trust chain will be broken, as the links provided by the DS records will not match what is present in the DNS. This last process can be seen as somewhat similar to the communications necessary when a new set of name servers is used for a zone. Another issue that can arise comes from the fact that there are several algorithm choices for DNSSEC keys and not all software supports all algorithms. Careful choice must be exercised to ensure interoperability. For resolvers the most important task to ensure is the proper refresh of trust anchors. This effort can be minimised by reducing the number of trust anchors in use by the resolver to one, the root server key. This key is not replaced frequently but to avoid any issues, resolver operators are advised to choose software that automatically tracks changes in trust anchors using the mechanism defined in RFC 5011. Recent versions of major DNSSEC enabled resolver software support this feature.
R 90&)1"%6"'&'(8:4,&5)%"5&3)
The component-based model of the DNS is intended to describe in a single picture all the actors and elements participating in the DNS processes. The components-based model, along with the reference architecture (a process-based model) are needed for:
%# (7<! 8K<568G8:A68;5! ;G! 67<! K8GG<><56! &;856! ;G! 38<O! ?M96! F<! :;598K<><K! 85! 67<!A5ACI989!A5K!<NACMA68;5!;G!2*0!_<AC67!A5K!0<:M>86I#!
"# (7<!K<G85868;5!;G!A!2*0!_<AC67!A5K!0<:M>86I!A5ACI989!ABB>;A:7#!!
Figure 6 The component based model!
!
The component-base model identifies the following high level components. %# (7<!)5K!/9<>!,BBC8:A68;5!`!8#<#!67<!ABBC8:A68;5!P<#H#!F>;O9<>T!67A6!;>8H85A6<9!67<!
2*0! ><LM<96#! /9MACCIJ! 86! 89! 5;6! ;G! B>8?A>I! 8?B;>6A5:<J! FM6! 86! ?8H76! AGG<:6! 67<!<NACMA68;5!;G!B<>G;>?A5:<!A5KR;>!NMC5<>AF8C86I#!4<:<56CI!O<!9<<!O<F!F>;O9<>9!9M:7!A9!0AGA>8J!.7>;?<!A5K!18><G;=!6AE<!A!?;><!A:68N<!>;C<!85!2*0!O867!2*0!B><]G<6:785HJ!856<>5AC!:A:785HJ!<6:!
"# (7<! ,BBC8:A68;5! 0<>N8:<! &>;N8K<>! P,0&T! `! 89! 856<5K<K! A9! 67<! 9I96<?! 67A6!B>;N8K<9! K896>8FM6<K! 9<>N8:<9RABBC8:A68;59J! ?A85CI! M985H! O<F! 9<>N8:<9!6<:75;C;H8<9#!,5!,0&!B>;N8K<9J! 67>;MH7! 67<! +56<>5<6J! 9<>N8:<9! 6;! 67<!<5K]M9<>9!FM6! 869<CG! 89!:C8<56!;G!;67<>!ABBC8:A68;5R9<>N8:<!A::<998FC<! 67>;MH7! 67<! +56<>5<6#!'G!:;M>9<!<5K]M9<>9!5<<K!67<!aC;FAC!2*0!6;!A::<99!A5!,0&!FM6!AC9;!67<!,0&!5<<K!67<!aC;FAC!2*0!6;!A::<99!;67<>!5<6O;>E<K!><9;M>:<9!A5K!6;!B>;N8K<!869!9<>N8:<9#!+6!89!B;998FC<!67A6!67<!,0&J!6;!>M5!869!ABBC8:A68;5!A5K!6;!?A5AH<!869!KA6AJ!O8CC!>M5!A!B>8NA6<!5A?85H!9I96<?J!85K<B<5K<56!G>;?!67<!aC;FAC!2*0#!
U# (7<! 06MF! 4<9;CN<>! P04T! ]! 67<! ;B<>A685H! 9I96<?! :;?B;5<56! 67A6! ><:<8N<9! 2*0!><LM<969! G>;?! ABBC8:A68;59! A5K! 9<5K9! 67<?! 6;! 67<! 4<9;CN<>! P67>;MH7! (.&R+&!:;55<:68;5T!
Q# (7<!4<9;CN<>!P4T`!86!89!A!5A?<!9<>N<>!;G6<5!;O5<K!A5K!?A5AH<K!FI!A5!+0&!67A6!><:<8N<9!67<!2*0!LM<>8<9!9<56!FI!M9<>9!67>;MH7!67<!06MF!4<9;CN<>!A5K!G;>OA>K9!67<?!MB!6;!67<!2*0!78<>A>:7I#!,9!<=BCA85<K! 85!0<:68;5!"!67<!><9;CN<>!:A5!F<!A!G;>OA>K<>!;>!A!GMCC!><9;CN<>#!
b# (7<!*A?<!0<>N<>!`!89!67<!9<>N<>!67A6!><9;CN<9!LM<>8<9!G;>!A!9B<:8G8:!Y;5<#!+6!:A5!F<!?A96<>!;>!9CAN<#!
S# (7<!4<H896>A56!`!+6!><B><9<569!67<!AK?85896>A6;>!;G!A!Y;5<!A5K!86!89!85!:7A>H<!;Gc!?A5AH85H!A5K!;B<>A685H!67<!2*0!KA6AFA9<\!MBKA685H!67<!2*0!><:;>K9!;G!67<!*09!M5K<>!869!:;56>;C#!!
$# (7<!2A6AFA9<9! ]!(7<I!A><! 67<!KA6AFA9<9!96;>85H!2*0! 85G;>?A68;5! G;>!A!:<>6A85!Y;5<#!
d# (7<!e*)(e!><B><9<569!ACC!67<!5<6O;>E!856<>:;55<:68;59!P-,*J!+56<>5<6J!<6:fT!;G!67<!?<?F<>9!C896<K!AF;N<#!
g# (7<! @2*0! Y;5<D! ]! +6! 89! A! 9B<:8G8:! 2*0! K;?A85! ?A5AH<K! FI! A! 985HC<! M58G8<K!AK?85896>A68N<!<5686I#!
%h# (7<! @aC;FAC! 2*0! 0I96<?D! 89! A! B9<MK;]<C<?<56! 67A6! 85K8:A6<9! 67<! aC;FAC! 2*0!9I96<?!85!869!<568><6I#!
11. (7<!@2*0!0MF]9I96<?D!`!+6!><B><9<569!A5!AM6;5;?;M9!*A?85H!0<>N8:<!?A5AH<K!FI!A!9B<:8G8:!<5686I#!1;>!<=A?BC<!A5!<56<>B>89<!5<6O;>E!5A?85H!9I96<?!89;CA6<K!G>;?! 67<! HC;FAC! 2*0#! (7<! 2*0! 9MF9I96<?! 89! :;?B;9<K! FI! 67<! G;CC;O85H!:;?B;5<569c! 67<! 06MF! ><9;CN<>J! ;5<! ;>! ?;><! 4<9;CN<>9J! ;5<! ;>! ?;><! *A?<!0<>N<>9#!
E C"5&3)/'43\,-,)
The framework for DNS Health and Security evaluation must be capable to respond to the different needs of its potential users. Therefore it is important:
• (;!8K<568GI!67<!?A85!<NACMA68;5!B;856!;G!N8<O9!• (;!K<G85<!67<!2*0!B>;:<99<9J!:;?B;5<569!A5K!A:6;>9!85N;CN<K!85!67<!<NACMA68;5!
;G!67<!7<AC67!A5K!9<:M>86I!• (;! 8K<568GI! 67<! :;?BM6AFC<! A5K! ?;><! ABB>;B>8A6<! ?<6>8:9! G;>! <A:7! B;856! ;G!
N8<O#!!The reference architecture and the component-based model are drivers allowing to deal with the above-mentioned items. In this section we discuss the concept of Point of View and how it can be used for health and security evaluation. A Point of View is intended as the perspective of a DNS actor/component in using, operating and influencing the Global DNS. Each point of view has a different perception of DNS health and security. The six points of view we will consider in the analysis of DNS health and security are:
• "#$%&'()!&;3J!• ,0&!&;3J!!• *('+,-()!&;3J!!• ./0(12()-()!&;3J!!• 3+#(!&;3J!!• 4,+5/,!&;3#!!
From each of the above PoVs it is possible to directly observe and measure the behaviour of some DNS components while it is not directly feasible to measure other not accessible components. To improve the H&S assessment capability the framework considers the possibility to integrate measurements directly collected with third parties data while and if accessible (e.g. could make sense a forwarder expose its average resolution time or its availability level). The third parties measures can be used in different ways, for example for H&S level comparison or to identify remote cause of H&S degradation.
EJ<J 90&)='58?,&+)N"A)
The End-User PoV represents the perspective from which each user can evaluate the Naming service (see Figure 7). From the End-User PoV, the elements involved in the resolution process are (see section 2 and 3): the Application component, the Stub Resolver component and the Net component, while the only operation of interest will be the DNS lookup process. This view will leave aside issues related to the H&S of other components such as the resolvers will take part in the DNS lookup process and the ASP.
Figure 7 The End User PoV
EJFJ 90&)/BN)N"A)
The Application Service Provider interacts with both the Global DNS, as an End-User, and (optionally) with its enterprise naming system. Therefore, the elements to be considered are: the Application Service Provider, the Stub Resolver, the NET component and, optionally, the DNS Sub-System and the Intranet. In addition, if the case, must be considered the DNS sub-system (intended as the autonomous naming service under the ASP control) and again the Net component (intended as the intranet). The DNS sub-system includes the following components: the Stub resolver, one or more Resolvers, one or more Name Servers. The operation involved in this point of view are DNS lookup, and DNS sub-system management (DNS lookup, zone transfer, zone management, etc...). Finally, to completely assess the H&S level are useful H&S indexes related to external resolvers and other ASPs involved.
Figure 8 The Application Service Provider PoV
EJRJ 90&)2&,"3*&+)N"A)
The Resolver PoV contemplates both the forwarder and full resolver cases. A forwarder interacts with other resolvers through the network (see figure 9), therefore measure of interest are also H&S indexes of external resolvers. A full resolver interacts directly with name servers. Therefore network and name servers are the elements of interest for the assessment of H&S. Moreover, for a complete health and security assessment, should be evaluated all the information provided by the Stub Resolvers that have originated the queries, and by the name servers that resolved the queries.
EJEJ 90&)I4%&)B&+*&+)N"A)
The Name Server point of view describes the NS vista of the Global DNS services. This perspective is different depending on whether it is Master or Slave server. The NS is directly affected by the NET component. A master NS participates in the DNS lookup process and the zone management process (included zone transfer). The slave NS is involved in the DNS lookup process and the zone transfer process. When the health and security are evaluated from a NS PoV different external measures should be considered: Zone, name server (other) and resolver.
Figure 10 The Name Server PoV (Master)
Figure 9 The Resolver PoV (forwarder on the left and full resolver on the right)
EJQJ 90&)Z"'&)N"A)
In the case of the Zone PoV the perspective includes more broadly a set of name servers connected each other, the zone registrant and the zone database. The process of interest for a Zone are the DNS lookup, the Zone transfer and the database update and management routines. Moreover the health and security evaluation from the Zone PoV should take into account external measurement from other zones and from the active resolver.
EJXJ 90&)T3":43)!IB)N"*)
The Global perspective examines the DNS in its most extended meaning. Here all the components and processes are involved and measurements aggregation mechanisms should be defined to give global measures of the DNS Health and Security level.
Figure 12 The Zone PoV
Figure 13 The Global DNS PoV
Figure 11 The Zone PoV (Slave)
Q 90&)N"A)466+"4#0)(")%&(+-#,)&*43$4(-"')
The PoV analysis approach is intended to provide a bottom up methodology to the measurement and evaluation of metrics. The concept is simple and intuitive. Let us suppose we want to evaluate the health and security level for the ASP PoV. The first step is to evaluate the network state, secondly are measured the Resolver and DNS sub-system H&S level and finally, aggregating this measure with external data (from Stub resolvers and Resolvers), it is possible to estimate the ASP perceived level of health and security. From the above example also emerges the need for a metrics aggregation methodology. Metrics aggregation results are important when, for example, the state of a set of NSs or Zones must be summarized with a single value. Measurement aggregation can be performed in different ways (e.g. average, integrals, etc etc..) which will be evaluated and discussed case by case.! The health and security level of the DNS will be evaluated through some specific metrics, categorized by eight benchmarks[4][4][6]: Coherency, Integrity, Speed, Availability, Resiliency, stability, security and vulnerability. The idea is to use the reference architecture, the component-based model and the PoV analysis approach as tools to filter the metrics proposed in [6] depending on:
• (7<!:7;9<5!M9<!:A9<!• (7<!:7;9<5!B;856!;G!N8<O!• (7<!:7;9<5!N86AC!98H59!O<!OA56R7AN<!6;!:;598K<>!• (7<!9<C<:6<K!67><A6RNMC5<>AF8C86I!9:<5A>8;#!!
A first coarse grain filtering of the metrics [6] can be done considering the eight vital signs of the DNS and the PoV organized in a mapping matrix as shown in Table 1. That matrix describes, for a given threat scenario, what are the metrics to measure the H&S from a specific PoV (see Table 1). These matrix representation helps to understand
• O7A6!A><!_i0!85K<=<9!?<A9M>AFC<!G>;?!A!9B<:8G8:!&;3!A5K!85!A!H8N<5!9:<5A>8;!• O7A6!A><!67<!?<6>8:9!M9<K!6;!?<A9M><!A!9B<:8G8:!_i0!85K<=!G>;?!A!9B<:8G8:!&;3!
A5K!9:<5A>8;!• 8G!A><!5<<K<K!5<O!?<6>8:9!G;>!A!9B<:8G8:!&;3J!_i0!85K<=!A5K!9:<5A>8;#!
!! !
!
Threat Scenario: …
End- User Application
Application Service. Provider
Stub Resolver … Zone Net
DNS System
Coherency
Integrity
Speed
Availability
Resiliency Unlinked (Security, Stability and Vulnerability)
Table 1 Health and Security metrics mapping matrix !
!
!
!
!
!
!
!
!
!
X C&(+-#,)C466-'^)
In the following are presented two example of a first coarse grain mapping of metrics describe in [6] into matrix. First we do not consider a specific threat scenario but only the DNS vital signs and the PoV. Therefore, we consider the specific case of Repository corruption scenario (we remind the four threat classes used to classify metrics in [6] are: Repository corruption, System Corruption, Denial of Service, Data pollution). We remarks also that each component that participates in a DNS resolution process, from data production to data usage will see different outcomes and have different opportunities of measuring how the system is performing. For instance, a user application will have a very limited view of the system and possibly only limited to whether it gets an answer to the query it generated or not. Other components of the system will have a more detailed view that provide more measurement points, as reflected in the corresponding applicable metrics. For easy of reading we report in the following the metrics identified for each threat scenario. Repository Corruption:
• 2A6A!06AC<5<99!• 2A6A!06AC<5<99!2M>A68;5!• Y;5<!K>8G6RY;5<!6>A97!• *0!&A><56R.78CK!2A6A!.;7<><5:<!• aCM<!85:;59896<5:8<9!• Y;5<!85:;59896<5:8<9!
System Corruption • *j2'V,+*!4<K8><:68;5!• *j2'V,+*!K<6<:68;5!>A6<!• &>;6;:;C!899M<9!• .A:7<!&;89;585H!• .A:7<!&;89;585H!4A6<!• .A:7<!&;89;585H!!&>;FAF8C86I!• .A:7<!&;89;585H!&>;BAHA68;5!• 2*0!9B;;G85HR'B<5!><:M>98;5!• Y;5<!(>A59G<>!GA8CM><!!• Y;5<!(>A59G<>!&>;6<:68;5!
Denial of Service • 3A>8A68;5!;G!2*0!4<LM<96!B<>!0<:;5K!• 3A>8A68;5!;G!2*0!4<LM<>I!6IB<!K896>8FM68;5!85!68?<!• +5:;?85H!kA5KO8K67!.;59M?B68;5!• +5:;?85H!6>AGG8:!NA>8A68;5!• a<;H>AB78:AC!2'0!)GG<:68N<5<99!• 4A6<!;G!><B<A6<K!LM<>8<9!• (>AGG8:!(;C<>A5:<!
Data Pollution
• +5G;>?A68;5!<=B;9M><!• Y;5<
!
!"#" $%&'()*+,-..(/0+%1-,.2%+
All the metrics are intended as "of interest" for the relative PoV and some times as "measurement of something that is not possible to measure elsewhere"
Not specific threat scenario is considered here, that is metrics are related to Repository corruption, System Corruption, Denial of Service, Data pollution
User Application
App. Serv. Provider
Stub Resolver Active Resolver Name Server Registrant Database Zone Net
DNS System
Coherency NXDOMAIN Redirection Data Staleness
Data Staleness
NS Parent/Child data Coher.
NXDOMAIN Redirection Rate
Zone drift/Zone thrash
Zone drift/Zone thrash
Glue Inconsistencies
Zone transfer protection
NS Parent/Child data Coher.
Zone transfer failure
Glue Inconsistencies
Zone Inconsistencies
Integrity Cache Poisoning Cache Poisoning Cache Poisoning Cache Poisoning
Cache Poisoning Rate
Cache Poisoning Rate
Cache Poisoning Rate
Cache Poisoning Rate
Data Pollution Data Pollution Data Pollution Cache Poisoning Prob.
DNSSEC validation DNSSEC publishing
DNSSEC key management
DNSSEC Key management
DNSSEC signature validty
DNSSEC transport
Speed Var. of DNS Req. Per Sec.
Cache Poisoning Prop.
Cache Poisoning Prop.
Data Staleness Duration
Incoming Band. Cons.
Cache Poisoning Prop.
Var. of DNS Req. per s.
Var. of DNS Req. per s.
Cache Poisoning Prop.
Incoming Traff. Var.
Var. of DNS Requery Type Distr.
Var. of DNS Requery Type Distr.
Traffic Tolerance
Availability OA Keyset Availability Keyset Availability Geogr. DOS Effec.
OA OA Name Exposure
Resiliency
Rate of Repeated Queries
Var. of DNS Req. per s.
Var. of DNS Req. per s. SMTR
Incoming Band. Cons. SMTR
MTTID
Var. of DNS Requery Type distr.
Var. of DNS Requery Type distr.
Incoming Traff. Var.
OMTBF Rate of Repeated Queries
Rate of Repeated Queries
Aver. Recovery Speed MTTID MTTID
NMTR OMTBF OMTBF
Aver. Recovery Speed
Aver. Recovery Speed
NMTR NMTR
Unlinked DNS Spoofing / Open Rec.
DNS Spoofing / Open Rec.
DNS Spoofing / Open Rec.
Zone Walkability Verifiability
OR OR Zone Transfer Failure
RR types Info. Leakage ATS
FRR FRR Zone Transfer Protection ATS BATS
IR IR OR BATS ATD FRR ATD BATD IR BATD SIL SIL AES AES CNATES CNATES VD
NUDI WVD TUDI SRT VD WVD ALE BAR
!! !
!In this second example, we select the Repository corruption scenario. A first observation is that while coherency, Integrity and speed can be measured from certain PoV, the other vital signs have no candidate indicators.
Repository Corruption threat scenario
End-user App. Serv. Provider
Stub Resolver
Active Resolver Name Server Registrant
Database Zone Net DNS System
Coherency Data Staleness Data Staleness NS Parent/Child data Coher.
Zone drift/Zone thrash
Zone drift/Zone thrash
Glue Inconsistencies
Zone transfer protection
NS Parent/Child data Coher.
Glue Inconsistencies
Zone Inconsistencies
Integrity
Speed Data Staleness Duration
Availability, Resiliency, Security, stability and vulnerability
!
!
Fondazione Global Cyber Security Center - Viale Europa, 175 00144 Roma - www.gcsec.org - P. IVA 11183771002 - CF 97603480589
! "#$%#&'()*+,-
!"# $%&'()*'(+,)-(+.,)-/,)01&(2(.3(,)4/,)5&6+7866)5&'(&9):5,);(<%=,)>)431?@)A%6B)1C)D'(E%.@)1C);1F(%+)8(F6)G63<%H6,)I8JK5K0)LMMN/)LO.&)IPPP)I+.63+(.%1+(E)51+C636+H6)1+)51F2'.63)51FF'+%H(.%1+=/)IPPP,)O7"L)0(@)LMMN)
!L# >/)Q'R63,)S/)<(+)011T,)06(='36=)C13)F(T%+U);8G)F136)36=%E%6+.)(U(%+=.)C13U6V)(+=B63=,)86.B13T)WX)IPYJ,)SJ5)Z[ZL,)\(+)LMM]))
!^# 0(3T)G(+.H311=,)KE(C)0/)-1ETF(+,);8G)Y&36(.)>+(E@=%=,)8$+6.)$(R=)V1H'F6+.)LMMO7GP7M")<63=%1+)"/M)0(@)^,)LMMN)
![# 06(='3%+U).&6)&6(E.&)1C).&6);1F(%+)8(F6)G@=.6F,)S6213.)1C).&6)L+V)>++'(E)G@F21=%'F)1+);8G)G6H'3%.@,)G.(R%E%.@,)_)S6=%E%6+H@,)J6R)LM"M,)[email protected],)\(2(+)`>23/)LM"Ma,)&..2=bccBBB/%H(++/13Uc6+c.12%H=c==3cV+=7==37=@F21=%'F736213.7"7^C6R"M76+/2VC)
!Z# I5>88,)G6H'3%.@,)G.(R%E%.@)(+V)S6=%E%6+H@)1C).&6);1F(%+)8(F6)G@=.6F,)\(+/)LMM])&..2bccBBB/U.%=H/U(.6H&/6V'c2VCc;8GGGS4(263/2VC)
!O# P/)5(=(E%HH&%1,);/)51+3(V,)I/)8(%)J1<%+1,)G/);%)dE(=%)e;8G)06.3%H=):=6)5(=6f,)I+.63+(E)36213.,)<63=%1+)M/O,)0(@)LM"")g))
