This document provides an overview of how DNS lookups generally work, with a focus on DNS security (DNSSEC). It explains the standard DNS lookup process, where a user's request is recursively resolved through root servers, TLD servers, and name servers until an IP address is returned. It then discusses DNSSEC in more detail, explaining the new record types it introduces like DNSKEY, RRSIG, DS, and NSEC to authenticate records and prove non-existence. The document emphasizes that while DNSSEC aims to validate records are authentic, recursive resolvers still may not perform validation, limiting its effectiveness. It also provides steps to configure a zone with DNSSEC.

1. DNS Lookups - How DNS Generally Works – NOT DNS SEC
DNS is probably one of the most poorly understood protocols and its probably because it has many “faces”. The following example
is an overview of how its all held together by Internet cloth. You send a “name”, you expect an IPv4 or IPv6 in return.
www
google.com.my
a-m.root.servers
.com.root.servers
.com.my.root.servers
ns.google.com.my
root.hints file
a.root.server xxx
b.root.server yyy
..
m.root.server.zzz
ISP
Recursive
DNS Server
1
2
3
4
User will query ISP DNS who in turn refers
to root.hints in local system
1. a-m.root servers queried for .com.my they
will return with a list of .com.root servers
2. query goes to .com.root servers and a list
is returned for .com.my.root
3. query goes to .com.my.root servers and a
specific list is returned for ns.google.com.my
4. query goes to ns.google.com.my and a
“A” record is returned (or AAAA)
Onces this happens / completes, your ISP
will cache the records for a specific period
and does not have to repeat the entire
process again and again.
For some real
samples, do
“dig isc.org
+trace”
UDP/53
IPv4/IPv6
149.20.64.69
Zone Record
www A 149.20.64.69
mail A xxx.yyy
ftp A yyy.zzz
May transport on
IPv6 anycast /
unicast
Glue Records
May transport on IPv4
but query for AAAA record
or vice-versa

2. DNS Lookups - How DNS Generally Works – DNS Sec - Recursion
DNS Sec in this context is taken to mean … if the recursion is “secure” and if the results being returned by my ISPs DNS server is
authentic and/or correct. In otherwords, some due diligence employed by my provider to help ensure that the returned records are
“real”. DNS Sec does not encrypt traffic.
kjteoh@uruk:~$ dig isc.org +dnssec
; <<>> DiG 9.10.3 <<>> isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30990
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;isc.org. IN A
;; ANSWER SECTION:
isc.org. 1 IN A 149.20.64.69
isc.org. 1 IN RRSIG A 5 2 60 20151126190706
This is an example where validation /
authentication has taken placed and it is
marked with the “ad” which has been circled.
EDNS enabled. Traditional UDP DNS
was restricted to 512 bytes and this has
since been extended with EDNS.
Participating DNS servers will
negotiated and settle on a “size”.
Note: DNS can do TCP too
The “problem” here is... not all zones are
DNS signed/enabled. So it is not digs
function to NOT display records which are
not DNS Sec enabled.
Records will display albeit w/o the “ad”
marker.
So ISPs should commit to a few extra CPU
cycles and enable DNS Sec validation. This
does not however appear to be happening.
Users are then left none the wiser. On the
one part, DNS Sec zone appear to be valid.
All steps and procedures have been
employed to make it good.
But if the ISPs recursive element does not
commit CPU cycles to DNS Sec, then all
value associated is lost.
See sample immediately on the lower left
where all semblance of DNS Sec exist minus
the validation... absurdity or ignorance?
kjteoh@latitude:~$ dig isc.org +dnssec
; <<>> DiG 9.10.3 <<>> isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 545
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;isc.org. IN A
;; ANSWER SECTION:
isc.org. 49 IN A 149.20.64.69
isc.org. 49 IN RRSIG A 5 2 60 20151126190706
This is where the problems begin to start.
ISC.ORG is DNS Sec ready and the query
being performed requires the +dnssec option.
The flags returned however DO NOT indicate
that its been validated.
All other indications return indicate that
it is DNS Sec validated, but in truth, not.
Note: RRSIG.
kjteoh@uruk:~$ delv isc.org
; fully validated
isc.org. 60 IN A 149.20.64.69
isc.org. 60 IN RRSIG A 5 2 60 201
kjteoh@uruk:~$ delv -i isc.org
; answer not validated
isc.org. 60 IN A 149.20.64.69
Preferred behavior – No RRSIG
Missing “ad”

3. DNS Lookups - How DNS Generally Works – DNS Sec – Record Types
I think there is some confusion about DNS Sec record types. DNS Sec does introduce a few new records but too, no human
intervention is really needed for its creation... unlike say, an MX record or a A record which had to be written by hand to a “zone” file.
The general procedure of creating a DNS Sec zone/record is to firstly set it up in the traditional fashion, and create all the required
MX, A & CNAME records. Only after you're satisfied with this do you then proceed with a ZSK & KSK. After that, you would create
a DS Key and have this installed at your Parent DNS Server. This will be used as a Secure Entry Point (SEP). In truth, it is the
SEP that becomes the single most important factor in ensuring that your DNS Sec set up or zones work accordingly. Without
which, your zone (DNS Sec enabled) is worthless.
DNSKEY
Used:
Sign the zone (ZSK Zone Signing Key – shorter bits)
Sign the Key that signed the zone (KSK – longer bits)
RRSIG – Resource Record Signature
Used:
Signature typically for:
IN NS ns1.xxx.com / IN A www.xxx.com
DS – Delegation Signer
Used:
Records given to your PARENT to confirm your identity xxx.com
DLV – DNSSEC Look-aside Validation
Similar to DS above. The parent may not be DNSSEC ready … use DLV
If I buy a domain from godaddy.com I will have to do the
following:
i. Use a DNS server to sign the zone (DNSKEY process
ZSK/KSK)
ii. RRSIG record will be created automatically
iii. Generate a DS record which looks like MD5/SHA(2) key
iv. Go to godaddy.com fill in the blanks...
v. Eg. My ns1.xxx is IP Address, ns2.xxx is IP Address
vi. Eg. My DS hash is “677b80bcf6712c04669bc97b7”
.com.my.root.servers
ns.google.com.my
www DS Record/Hash is installed …
for zone/domain record xxx.com
This is the SEP. The response must have
come from here ONLY.
When the ISPs recursion DNS can properly identify
that the SEP is indeed valid, the validation of the
zone is complete. This can only be achieved where
few conditions are met. One, ISP DNS is DNS Sec
enabled. Two, the zone is duly ZSK/KSK'ed. Last,
a DS Key is obtained and properly installed on the
Parent DNS Server (which too must be DNS Sec
enabled). Otherwise, use DLV – BUT is becoming
depreciated as more and more root servers are
becoming DNS Sec aware.

4. DNS Lookups - How DNS Generally Works – DNS Sec – NSEC
DNS Servers have traditionally returned NXDOMAIN when no record is found. With DNS Sec however, a new NSEC record is
returned in place of NXDOMAIN. What DNS Sec does here is attempt to prove that the queries-for record is non-existing by
returning the NEXT available record in its “dovetail”.
kjteoh@my-anoc0:~$ dig gone.isc.org
; <<>> DiG 9.4-ESV-R4 <<>> gone.isc.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9945
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
NSEC – Next Secure – returns NSEC __name__.isc.org
NSEC3 – Next Secure (v3) – returns NSEC3 __hash__record__isc.org
kjteoh@uruk:~$ dig GONE.isc.org +dnssec
; <<>> DiG 9.10.3 <<>> GONE.isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47298
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
isc.org. 3293 IN NSEC _adsp._domainkey.isc.org. A NS SOA MX TXT ….
NOTE: isc.org NS server proving to you that next record is adsp...isc.org
Traditional Response
Note:
NSEC will return text records and
NSEC3 will returned hashed records
which will in turn totally prevent domain
“walking”.
We should remember that these records
do not required explicit configuration by
hand.
The process of creating the ZSK / KSK
will “encapsulate” the regular ZONE
record and create the additional records
required.
In otherwords, while you would need to
write out an A record, you DO NOT need
to do the same for an NSEC or DS KEY
or RRSIG entry.
Steps Required to create DNS Sec Zone
1. ready to host zone raj.com.my - regular zone file created
2. dnssec-keygen -a RSASHA256 -b 1024 raj.com.my
(this will create pub/pri key ZSK)
3. dnssec-keygen -a RSASHA256 -b 2048 -f KSK raj.com.my
(this will create pub/pri key KSK – NOTE)
4. config named.conf to include path to keys. Continue →
zone "raj.com.my" IN {
type master;
file "bind/keys/raj.com.my.db";
key-directory "bind/keys/raj.com.my";
inline-signing yes; auto-dnssec maintain; };
5. reload Bind and run dig @locahost raj.com.my +dnssec
You should get RRSIG values
7. dnssec-dsfromkey -a SHA1 your-PUB-KSK-KEY
raj.com.my. IN DS 1495 8 1 78E72B-Shortened