DNSSEC resolution when NS records are not accompanied by A records

Question

Been trying to find the right place to ask this. hopefully this is the place!

There are a few subtleties behind DNS and DNSSEC in particular that I am trying to understand. DNSSEC uses a chain of trust to go from the trusted root DNS servers down to the target host. According to http://dnsviz.net/d/ietf.org/dnssec/, the host ietf.org is DNSSEC secured. Running the following Unix command, we get a sample trace:

$ dig ietf.org +dnssec +trace +multi

; <<>> DiG 9.9.5 <<>> ietf.org +dnssec +trace +multi
;; global options: +cmd
.                       24638 IN NS a.root-servers.net.
.                       24638 IN NS b.root-servers.net.
.                       24638 IN NS c.root-servers.net.
.                       24638 IN NS d.root-servers.net.
.                       24638 IN NS e.root-servers.net.
.                       24638 IN NS f.root-servers.net.
.                       24638 IN NS g.root-servers.net.
.                       24638 IN NS h.root-servers.net.
.                       24638 IN NS i.root-servers.net.
.                       24638 IN NS j.root-servers.net.
.                       24638 IN NS k.root-servers.net.
.                       24638 IN NS l.root-servers.net.
.                       24638 IN NS m.root-servers.net.
.                       24638 IN RRSIG NS 8 0 518400 (
                                20180223050000 20180210040000 41824 .
                                e8itIEYiVRvPxv5mkNzkBZTltFgDUIFLB/KxV7RFpXzj
                                X8Rqre85GiIFlAM01rIi0YGTkb6k6U+TGdDxXabQmr4q
                                wHIBTEd2MjrHb+0XsY4dIlZJ3qvLPdnDPHSlIBx17K3A
                                +AqMZdINCCA7QlxnUd3+agMpc9jkJrsNBO2x1CVBP8R2
                                w4a2kHcpxILr9T/heamOJOpHjd3r3l6/mhGkY0ut2I+Y
                                4vbzplayG0f6Br461y4qtX4h6JUJk8BBDvzcqzovpUSk
                                VSqLeM9YXVC5XzrWNb8081u7ct37J5g+5vJLHAMcac7L
                                8qQ4rtmQqzHn1reS6wOogYxsUVlOxdxP2Q== )
;; Received 525 bytes from 10.211.254.254#53(10.211.254.254) in 109 ms

org.                    172800 IN NS a0.org.afilias-nst.info.
org.                    172800 IN NS a2.org.afilias-nst.info.
org.                    172800 IN NS b0.org.afilias-nst.org.
org.                    172800 IN NS b2.org.afilias-nst.org.
org.                    172800 IN NS c0.org.afilias-nst.info.
org.                    172800 IN NS d0.org.afilias-nst.org.
org.                    86400 IN DS 9795 7 1 (
                                364DFAB3DAF254CAB477B5675B10766DDAA24982 )
org.                    86400 IN DS 9795 7 2 (
                                3922B31B6F3A4EA92B19EB7B52120F031FD8E05FF0B0
                                3BAFCF9F891BFE7FF8E5 )
org.                    86400 IN RRSIG DS 8 1 86400 (
                                20180223050000 20180210040000 41824 .
                                Weag50NNvW6pqxODjMj3F0LrcFizxaK76PhdGtVv0iDg
                                tgZw4DzcDU8WrD6q/pm7kzKwLpXryhfMo3ASKgP+Usyr
                                V1uW0WyCh0cwZs6yfMKfZNtF1X47PulkiHgrc7AI/+nO
                                oQGv6FlUAROyh+aak7QN6/IEVO5CE6nzpsyzDqewnGmt
                                xYNgeWJr0RJR81VqBN6/Y4t/NthxsPEyLoXl1ijju99h
                                Tf9UP2+1GFLqaf6uINsSD/EsHryQB7W6ZUz6pdmE5C3W
                                jbqZ+7heu7xK9Tzz7Fv3tS2nei0xk0puNh5vCHjGzjG5
                                +lIfY6dJxxvxh/ywqS6Fm8yhIRjLgscpQw== )
;; Received 810 bytes from 199.7.83.42#53(l.root-servers.net) in 100 ms

ietf.org.               86400 IN NS ns1.yyz1.afilias-nst.info.
ietf.org.               86400 IN NS ns0.amsl.com.
ietf.org.               86400 IN NS ns1.sea1.afilias-nst.info.
ietf.org.               86400 IN NS ns1.ams1.afilias-nst.info.
ietf.org.               86400 IN NS ns1.mia1.afilias-nst.info.
ietf.org.               86400 IN NS ns1.hkg1.afilias-nst.info.
ietf.org.               86400 IN DS 45586 5 1 (
                                D0FDF996D1AF2CCDBDC942B02CB02D379629E20B )
ietf.org.               86400 IN DS 45586 5 2 (
                                67FCD7E0B9E0366309F3B6F7476DFF931D5226EDC534
                                8CD80FD82A081DFCF6EE )
ietf.org.               86400 IN RRSIG DS 7 2 86400 (
                                20180302153210 20180209143210 1862 org.
                                K1JT67FsQ9Dl4W8V7pYp6MlbbNSe2IKfmgXiqXPlPLsy
                                5mZYhnUilXE40icI9Eea6KZY5eEZIdvEDzfMXaAshLXh
                                6gLAtPTviTa9aFUid2dd/McNUdSrWQjZKicpW//XJ6fw
                                9v5coQTrnP9HA9oCwb5TXWAKY7Ju+j5hkrBPy7M= )
;; Received 441 bytes from 199.19.54.1#53(b0.org.afilias-nst.org) in 134 ms

ietf.org.               1800 IN A 4.31.198.44
ietf.org.               1800 IN RRSIG A 5 2 1800 (
                                20190109135858 20180109130036 40452 ietf.org.
                                O8fJkB4ISG/SzpRd0EBvh49pLzR21cXJEH7ZWUSfpFjX
                                fv7pqIEX9FUMEjP+VHdsP7iCQ3Gkd3PQul7PNFqbdMnk
                                4O5NomCyg71J73G4rLlaBYZYTCTVW+8CdgviqrNoIFSz
                                gPcN7kxDdg25YKi5ywjbMqCU9BWhnGw+4kS7TrXtd92c
                                /YUqViYDN0OCTMn5b05+a6FJd0Fu4iKbYpFQJ1/dDh5F
                                /RAhIGFbOd2/zGK6xCE3IU8ICzRhIJL0ZiNMRtbZOc1u
                                POeHd3SQ66ZrNRbl0pxwQlzizRkaeFchCZ9+w71AmrGG
                                0K4BWNNsW1PwkgJwb/trlWSTroA4X/6oUg== )
ietf.org.               1800 IN NS ns1.yyz1.afilias-nst.info.
ietf.org.               1800 IN NS ns1.hkg1.afilias-nst.info.
ietf.org.               1800 IN NS ns1.ams1.afilias-nst.info.
ietf.org.               1800 IN NS ns0.amsl.com.
ietf.org.               1800 IN NS ns1.sea1.afilias-nst.info.
ietf.org.               1800 IN NS ns1.mia1.afilias-nst.info.
ietf.org.               1800 IN RRSIG NS 5 2 1800 (
                                20190109135847 20180109130036 40452 ietf.org.
                                nfZKxJsrSozyiyPvWcn0fJCAz4qVE5xiwLOTGkOAh/Mh
                                SH9xv6sNqWEJtul4rRYLJQ7S1AyFHT4PwhjyypG0KMnW
                                SAEMTpXhMqO2Mlf2/LoVPoPGsFfs3LqhgyAYxjgbOxix
                                zG1grS/AXHzUzudrLjWUfgQB+N4jb0VmvVBtp4XS6soa
                                C+ZHdyLr4pnT8PwE2Qbge405lhEIAHfx+RLWkrkQUJEU
                                JKTjyXsQcRp/2MRniHXf4udSWSvjcwNuFKEng6eHzWg7
                                tQwBHmluZVHhN7U/xcplREvKRg/5YV4K3OjRcXAXK0XW
                                kauSoZWiLHvRTgPnZJdhNDv5uqHvHVGNbw== )
;; Received 994 bytes from 65.22.8.1#53(ns1.sea1.afilias-nst.info) in 100 ms

However, if we run

$ dig ietf.org +dnssec

; <<>> DiG 9.9.5 <<>> ie

tf.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35753
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 8192
;; QUESTION SECTION:
;ietf.org.                      IN      A

;; ANSWER SECTION:
ietf.org.               1800    IN      A       4.31.198.44
ietf.org.               1800    IN      RRSIG   A 5 2 1800 20190109135858 20180109130036 40452 ietf.org. O8fJkB4ISG/SzpRd0EBvh49pLzR21cXJEH7ZWUSfpFjXfv7pqIEX9FUM EjP+VHdsP7iCQ3Gkd3PQul7PNFqbdMnk4O5NomCyg71J73G4rLlaBYZY TCTVW+8CdgviqrNoIFSzgPcN7kxDdg25YKi5ywjbMqCU9BWhnGw+4kS7 TrXtd92c/YUqViYDN0OCTMn5b05+a6FJd0Fu4iKbYpFQJ1/dDh5F/RAh IGFbOd2/zGK6xCE3IU8ICzRhIJL0ZiNMRtbZOc1uPOeHd3SQ66ZrNRbl 0pxwQlzizRkaeFchCZ9+w71AmrGG0K4BWNNsW1PwkgJwb/trlWSTroA4 X/6oUg==

;; Query time: 101 msec
;; SERVER: 10.211.254.254#53(10.211.254.254)
;; WHEN: Sat Feb 10 07:00:56 EST 2018
;; MSG SIZE  rcvd: 349

then observe that Dig does not set the "ad" flag, which leads me to believe perhaps the target host (ietf.org) is not DNSSEC secured.

Supposing that it is secured, I am trying to understand the chain of trust. The part I don't get is that during the DNS resolution, if you query

$ dig @199.19.54.1 ietf.org +dnssec +multi

; <<>> DiG 9.9.5 <<>> @199.19.54.1 ietf.org +dnssec +multi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30334
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ietf.org.              IN A

;; AUTHORITY SECTION:
ietf.org.               86400 IN NS ns1.ams1.afilias-nst.info.
ietf.org.               86400 IN NS ns0.amsl.com.
ietf.org.               86400 IN NS ns1.hkg1.afilias-nst.info.
ietf.org.               86400 IN NS ns1.mia1.afilias-nst.info.
ietf.org.               86400 IN NS ns1.sea1.afilias-nst.info.
ietf.org.               86400 IN NS ns1.yyz1.afilias-nst.info.
ietf.org.               86400 IN DS 45586 5 1 (
                                D0FDF996D1AF2CCDBDC942B02CB02D379629E20B )
ietf.org.               86400 IN DS 45586 5 2 (
                                67FCD7E0B9E0366309F3B6F7476DFF931D5226EDC534
                                8CD80FD82A081DFCF6EE )
ietf.org.               86400 IN RRSIG DS 7 2 86400 (
                                20180302153210 20180209143210 1862 org.
                                K1JT67FsQ9Dl4W8V7pYp6MlbbNSe2IKfmgXiqXPlPLsy
                                5mZYhnUilXE40icI9Eea6KZY5eEZIdvEDzfMXaAshLXh
                                6gLAtPTviTa9aFUid2dd/McNUdSrWQjZKicpW//XJ6fw
                                9v5coQTrnP9HA9oCwb5TXWAKY7Ju+j5hkrBPy7M= )

;; Query time: 143 msec
;; SERVER: 199.19.54.1#53(199.19.54.1)
;; WHEN: Sat Feb 10 06:55:30 EST 2018
;; MSG SIZE  rcvd: 441

then there is no A record for any of these name servers. So unless I am totally wrong, DNS must do some kind of additional resolution to obtain the IP address for these name servers (such as ns0.amsl.com.), so that they can in turn be queried for the A record of the final target host (ietf.org). The only problem is that none of these name servers, such as ns0.amsl.com., are DNSSEC secure, according to both Dig and http://dnsviz.net/d/ns1.sea1.afilias-nst.info/dnssec/ !

So how does DNSSEC establish security and how is trust preserved during this additional address resolution step? Perhaps I am not correctly understanding DNS or DNSSEC, and all help is appreciated!

Patrick Mevzek · Accepted Answer · 2018-02-11T00:45:34.667

Multiple points in your question:

1) dig +dnssec just requests dig to send you the DNSSEC related records, that is RRSIG with your results, it does not validate anything.

The +ad flag (but it is the default) requests DNSSEC validation... but that works only if you query a DNSSEC validation resolver. On the contrary +cd disables any kind of DNSSEC validation.

See:

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @9.9.9.9 +ad ietf.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31296
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ietf.org.          IN  A

;; ANSWER SECTION:
ietf.org.       1800    IN  A   4.31.198.44

;; Query time: 228 msec

2) about dig @199.19.54.1 ietf.org +dnssec +multi it is normal you do not get A records. 199.19.54.1 aka b0.org.afilias-nst.org. is not authoritative for ietf.org, it is only authoritative for org. So if you query it for a domain it has in its zone it will just give referrals, that is NS records. Some nameservers may also provide A/AAAA records in the additional section to help resolvers, but they are more used to distrust them.

But note that in the reply you had the DS of ietf.org and the associated RRSIG.

So the next step for the resolver is to use the NS records, query for their A/AAAA records and then contact them to get the A record of ietf.org. If they need to do DNSSEC validation they will query for DNSKEY and verify that the DNSKEY corresponds to the DS in the org zone and that the A record of ietf.org has a corresponding RRSIG signed with the DNSKEY (I am simplifying, most of the times you have KSK and ZSK, this just creates an extra level of signatures, but does not change conceptually what is above).

The nameservers domain name may not be DNSSEC enabled themselves, this will not impact DNSSEC validation of ietf.org. It has however practical security consequences because it means their domain name could be hijacked and hence you could, theoretically, divert traffic to rogue nameservers that would give other replies, and can cause either DNS or DNSSEC validation failures. At most these rogue nameservers will only be able to force SERVFAIL errors to all validating resolvers as they will not be able to serve signatures signed by a key matching the DS record in the parent zone. So DNSSEC here, even if the nameservers domain itself does not use DNSSEC, still allows to make sure no other/false records can be inserted.

Of course, in a perfect world, everything could or should be DNSSEC enabled, but it would still be a chicken and egg problem: the root zone . uses nameservers in the root-servers.net domain, so you would not be able to secure both parts at once. In fact, root-servers.net is not DNSSEC enabled to this day... which has little consequences to the resolution or the DNSSEC validation of all domains.

In short, DNSSEC does not work because authoritative nameservers would directly provide IP addresses of "children" nameservers, this part just work as before DNSSEC. DNSSEC works because, in very broad term, each zone publish keys used to generate signatures on each record in the zone, and a hash of the key is published in the parent zone to create a chain of trust up to the root trust anchor.

Good answer. But doesn't this make DNSSEC misleading though if the nameservers are not DNSSEC secured? Isn't the whole point of DNSSEC to have security? What's the point of calling it DNSSEC secure if the name servers can get hijacked? — user308485, Feb 10 '18 at 19:34
@user308485 The fact that DNSSEC only secures things when it is actually being used, and not in places where it's not being used, hardly makes it pointless or misleading. — Jenny D, Feb 10 '18 at 19:44
@user308485 I have edited my answer to add more explanations about the nameservers' domain being DNSSEC enabled or not. Note the case of `root-servers.net` which is not DNSSEC enabled but it is the domain used for all nameservers authoritative for `.` — Patrick Mevzek, Feb 11 '18 at 00:47

DNSSEC resolution when NS records are not accompanied by A records

1 Answers1