DNSSec und NS resource records (RR)

[Kruzifix]

Moin moin,

meine Frage ist, ob es eine Regelung bezüglich das Signierens von NS RRs gibt. In einem Video [YT DNSSec; ab 9:00] wird gesagt, dass die Refferals non-secure (heißt für mich ohne Signatur) zurückgegeben werden.
Wenn ich allerdings einen Test mit dig laufen lasse, tauchen sehr wohl RRSig Felder für NS RRs auf:

Spoiler: Ergebnis für A RR auf www.computerbase.de

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +multiline +dnssec +trace www.computerbase.de A
;; global options: +cmd
.            5 IN NS    e.root-servers.net.
.            5 IN NS    f.root-servers.net.
.            5 IN NS    g.root-servers.net.
.            5 IN NS    h.root-servers.net.
.            5 IN NS    i.root-servers.net.
.            5 IN NS    j.root-servers.net.
.            5 IN NS    k.root-servers.net.
.            5 IN NS    l.root-servers.net.
.            5 IN NS    m.root-servers.net.
.            5 IN NS    a.root-servers.net.
.            5 IN NS    b.root-servers.net.
.            5 IN NS    c.root-servers.net.
.            5 IN NS    d.root-servers.net.
.            5 IN RRSIG NS 8 0 518400 (
                20180730050000 20180717040000 41656 .
                hi9IzsVxRnnMY1dWxdj30ACLs3XuyJMCJyphv9bv8Psl
                8AuKjc8IHTCx9D5yItmnPsk8nDfAIxicn6w6n5wjfUel
                /sgMKenAK8NKMRaeEqo3jHq/ePu8FlaYIHq2zwbXGIJ4
                RF88sB6IlDQvl1ioD3oU8ScbS9h6fE44DnMsLjTgigZS
                7snBGZAmNnnQ+oa0sQIoLZm9OjhjVdayAT1hNT2RNOKy
                ArsKbVcZvSVmxbLHd2M0XSpAZR4HV0jUK7mnx9B1JRPS
                K9M1X1HgVA+sam3J6joF28JxOO/dO22JfQerA7/JoD8B
                dCtKyfcpKHO9FdvA7uekp6gfXMwgYceDew== )
;; Received 1097 bytes from 127.0.1.1#53(127.0.1.1) in 1 ms

de.            172800 IN NS a.nic.de.
de.            172800 IN NS f.nic.de.
de.            172800 IN NS l.de.net.
de.            172800 IN NS n.de.net.
de.            172800 IN NS s.de.net.
de.            172800 IN NS z.nic.de.
de.            86400 IN DS 39227 8 2 (
                AAB73083B9EF70E4A5E94769A418AC12E887FC3C0875
                EF206C3451DC40B6C4FA )
de.            86400 IN RRSIG DS 8 1 86400 (
                20180730050000 20180717040000 41656 .
                bg+B88qSDUTx1/+aXACOnwJaribd3DRPR15ZrCGDPXWV
                EIQbaCkT/Rf37aUuBX9m+mG9PGOPAeo3su/MaIUvhfKg
                lQLJZ30BlmxpZR3zgxRnyek11jYrjmjEHGJ94XGnV5qw
                nbrzpd0iX8WopwZPZW1GnacA3bp/r3O0PTtXCFd6X2nt
                vS+fBPI2rYep2j7iumY5BB1Z4ZfS0ukSBf3VziVRRbw+
                vsrzFO/53I1wFKaLA4HtVfX8V/Yiz8DAPe6+B220ogv2
                iPCUloFUYunNu0nRyGz7amrDvN4FjungUAsJvdpliYoU
                Cb8Uy/Atu83RFR+omAV5R8KCQ6PNrAt21A== )
;; Received 725 bytes from 198.97.190.53#53(h.root-servers.net) in 97 ms

computerbase.de.    86400 IN NS ns.inwx.de.
computerbase.de.    86400 IN NS ns4.inwx.com.
computerbase.de.    86400 IN NS ns5.inwx.net.
computerbase.de.    86400 IN NS ns2.inwx.de.
computerbase.de.    86400 IN NS ns3.inwx.eu.
H319DM5GC3EDEK691VQBHEHOT7VGGJ2B.de. 7200 IN NSEC3 1 1 15 BA5EBA11 (
                H319HUM18PNIGRCGMBUB2K4L031P8C74
                NS SOA RRSIG DNSKEY NSEC3PARAM )
H319DM5GC3EDEK691VQBHEHOT7VGGJ2B.de. 7200 IN RRSIG NSEC3 8 2 7200 (
                20180724090055 20180717090055 57228 de.
                KUlB2VZybCTvVhMpx6yx8U2HmQaWNF9JaIiJcw6JxfiH
                W+9ZpJJ7uf3HcCpgtudCnLZfFe8aGIm1bBeLLEm1VhGd
                U1kr/+e4phK47IeOQF1f/PVCZ5JHqtj+FNuuqOY0RgzX
                +w6leOBX0bAKwdqPWUA/4vpQnJ7jLOxGKJ4K1Sw= )
FFRPHGPOATCRK7KRGOFQ9DO3GBN3C4CC.de. 7200 IN NSEC3 1 1 15 BA5EBA11 (
                FFRU6FSEML5BQVPMM6GJFIPV0V4L2HF0
                A RRSIG )
FFRPHGPOATCRK7KRGOFQ9DO3GBN3C4CC.de. 7200 IN RRSIG NSEC3 8 2 7200 (
                20180724090055 20180717090055 57228 de.
                HUO91RFg5jKRmdIioFbjhgfrDJW46PGossJY5xe5/0ZF
                C11PIs8xtFIyelDeMhE2Mvvbechzv2CsPMuh4TXTYrmT
                1KNo2rWsxkcVjQ1F8vK2S/V1ZobqZS4wgxoQIFe7Cdo0
                2jKJhqeVIVj7+EPegtQ5ikkwOuO0BZJ/sm2FeOw= )
;; Received 656 bytes from 195.243.137.26#53(s.de.net) in 23 ms

www.computerbase.de.    86400 IN A 87.230.75.2
;; Received 64 bytes from 46.165.212.97#53(ns3.inwx.eu) in 21 ms

Kann mir jemand sagen, ob es da eine einheitliche Regelung gibt, oder je nach Implementierung variieren darf ? Die Chain of Trust wird dadurch meiner Auffassung nach nicht beeinflusst..

 

[MisC]

Schau dir den Output nochmal an, dort ist nur eine RRSIG NS und die passt so.

 

[Kruzifix]

Jau das stimmt. Die root NS RRs scheinen vom localhost zu kommen. Sprich die Signatur dafür liegt lokal auf dem Rechner ? Wenn ja, ist das standardmäßig so ?

Vielen Dank

 

[MisC]

dig fragt bei einem +trace als erstes den lokal eingestellten DNS-Resolver nach den Root-Nameservern. Ob das bei dir nun ein Ergebniss aus dem DNS-Cache ist oder ob dein DNS-Resolver eine Kopie der Root-Zone hat kann man hier nicht direkt beurteilen. Letzteres ist aber noch nicht sehr weit verbreitet.

Rufe es mehrmals im Abstand von mehreren Sekunden auf und schau ob sich die TTL verändert. Wenn ja kommen die Infos aus einem DNS-Cache ansonsten hat der Resolver die Root-Zone lokal.

 

[Kruzifix]

Die TTL ist bei jeder Anfrage gleich. Allerdings sehe ich auch keinen Grund, warum sie sich verändern sollte. Das Feld wird soweit ich weiß nicht genutzt (dekrementiert) um festzustellen, ob ein RR aus dem Cache fliegen muss, sondern gibt eben nur die maximal erlaubte Verweildauer an. Das sollte ja gleich bleiben, unabhängig von der bisherigen Dauer im Cache. (Außer der authoritative Nameserver ändert die mitgelieferte TTL) Bitte korrigier mich, falls ich da falsch liege.
Ich denke generell kann man festhalten, dass die NS RRs ohne Signatur zurück kommen. (Jedenfalls wenn es um Zonenwechsel geht).

 

[MisC]

Dann hält dein Resolver die Root-Zone lokal bereit.

Ein Caching-Resolver nennt dir nicht die echte TTL es sei denn er hat sich den Record selbst eben erst geholt. Dadurch ist es möglich mehrere Caching-Resolver in Reihe zu schalten ohne Problemen zu bekommen. Ändere ich einen Record erwarte ich ja, dass spätestens nach Ablauf der alten TTL alle Clients den neuen Record kennen. Das wäre unmöglich wenn Resolver in Reihe geschaltet sind und die Original TTL weitergeben.