dig -- only RRSIG present.

[dE .]

I'm trying to see DNSSEC response of various sites; my DNS server is
8.8.8.8 (google's public DNS service)

Response is as such -

dig +dnssec -t SOA org

; <<>> DiG 9.8.1 <<>> +dnssec -t SOA org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20306
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;org. IN SOA

;; ANSWER SECTION:
org. 899 IN SOA a0.org.afilias-nst.info.
noc.afilias-nst.info. 2009954959 1800 900 604800 86400
org. 899 IN RRSIG SOA 7 1 900
20120304071611 20120212061611 55440 org.
M5Bi8pDPV3ux+FEK5GnJtxpL3X06reEIA+zkFk5YZK9U/LSAwAO+EdgG
EQVOBpegjTTobmKJZLxl2e9E3t3zm0zaoYXXLGBfnSSNRiI4x4NtTqXE
ElFtDCIyfqMwAMaiD9CAHwH/tiRfkV9VlWeAmCgIKZ6w7QVtXLPHwYA3 x2c=

;; Query time: 1371 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Feb 12 12:49:02 2012
;; MSG SIZE rcvd: 258

As we can see, the DNSKEY and DS RR is missing which's mandatory for
this to be of any use. So where is it?

If I explicitly specify the name server to be one of the root nameservers -

dig +dnssec -t SOA org 198.41.0.4

; <<>> DiG 9.8.1 <<>> +dnssec -t SOA org 198.41.0.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62972
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;org. IN SOA

;; ANSWER SECTION:
org. 451 IN SOA a0.org.afilias-nst.info.
noc.afilias-nst.info. 2009954959 1800 900 604800 86400
org. 451 IN RRSIG SOA 7 1 900
20120304071611 20120212061611 55440 org.
M5Bi8pDPV3ux+FEK5GnJtxpL3X06reEIA+zkFk5YZK9U/LSAwAO+EdgG
EQVOBpegjTTobmKJZLxl2e9E3t3zm0zaoYXXLGBfnSSNRiI4x4NtTqXE
ElFtDCIyfqMwAMaiD9CAHwH/tiRfkV9VlWeAmCgIKZ6w7QVtXLPHwYA3 x2c=

;; Query time: 131 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Feb 12 12:56:30 2012
;; MSG SIZE rcvd: 258

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26058
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;198.41.0.4. IN SOA

;; AUTHORITY SECTION:
. 0 IN SOA a.root-servers.net.
nstld.verisign-grs.com. 2012021200 1800 900 604800 86400
. 0 IN RRSIG SOA 8 0 86400
20120219000000 20120211230000 51201 .
Es1RsMErjNpgyBqjHbUIVQ77hrA6quuq45ZNhiL1CwXkLpd9wnPVSlcu
xAcF675og+exWPBUMUBrXNTpYOI4a2Wrvkafd7629kT21alDyiUa28FC
P/P/pWOFVa0ceDDQGnwKg7ec4r+UyhoTLGmvlVpDjqMhmR17a02SLz31 a/Q=
. 86399 IN NSEC ac. NS SOA RRSIG NSEC DNSKEY
. 86399 IN RRSIG NSEC 8 0 86400
20120219000000 20120211230000 51201 .
hFSp9EIMo7fEbc3gKaZD8gH5XzUUjNy9rRGf0cW3mtHy8FoqaLg1eIfg
9CGjjWqx58t2R68O+/f7sQ6F4aysMA30aiYsOJXJRENEuzGKSGQiuRZE
nP3K5AjqcKmxgkllKAQWMITFU2HDXzgHH3iWOhxh6zdCV8hZe4xPv60Z Zp4=

;; Query time: 195 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Feb 12 12:56:30 2012
;; MSG SIZE rcvd: 454


I get 3 completely different RRSIGs, and the DNSKEY and DS are still
missing.

The last thing that I want to ask is that, this string -

"M5Bi8pDPV3ux+FEK5GnJtxpL3X06reEIA+zkFk5YZK9U/LSAwAO+EdgG
EQVOBpegjTTobmKJZLxl2e9E3t3zm0zaoYXXLGBfnSSNRiI4x4NtTqXE
ElFtDCIyfqMwAMaiD9CAHwH/tiRfkV9VlWeAmCgIKZ6w7QVtXLPHwYA3 x2c="

Which's a part of the RRSIG, is this a single key or multiple keys?

[Miek Gieben]

[ Quoting <de.t...@gmail.com> at 23:10 on Feb 12 in "dig -- only RRSIG pr..." ]

> I'm trying to see DNSSEC response of various sites; my DNS server is
> 8.8.8.8 (google's public DNS service)

Google's public resolvers don't handle DNSSEC very well...

grtz Miek

[Michael Sinatra]

On 02/12/12 09:40, dE . wrote:
> I'm trying to see DNSSEC response of various sites; my DNS server is
> 8.8.8.8 (google's public DNS service)
>

> Response is as such -
>
> dig +dnssec -t SOA org
>
> ; <<>> DiG 9.8.1 <<>> +dnssec -t SOA org
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20306
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ;; QUESTION SECTION:
> ;org. IN SOA
>
> ;; ANSWER SECTION:
> org. 899 IN SOA a0.org.afilias-nst.info. noc.afilias-nst.info.
> 2009954959 1800 900 604800 86400
> org. 899 IN RRSIG SOA 7 1 900 20120304071611 20120212061611 55440 org.
> M5Bi8pDPV3ux+FEK5GnJtxpL3X06reEIA+zkFk5YZK9U/LSAwAO+EdgG
> EQVOBpegjTTobmKJZLxl2e9E3t3zm0zaoYXXLGBfnSSNRiI4x4NtTqXE
> ElFtDCIyfqMwAMaiD9CAHwH/tiRfkV9VlWeAmCgIKZ6w7QVtXLPHwYA3 x2c=
>
> ;; Query time: 1371 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Sun Feb 12 12:49:02 2012
> ;; MSG SIZE rcvd: 258
>
> As we can see, the DNSKEY and DS RR is missing which's mandatory for
> this to be of any use. So where is it?

Well, the DS RR resides in the parent, not in the zone you're querying.
You need to ask for it explicitly. Although DNSKEY records are in the
actual zone you're querying, you still need to ask for them explicitly.
They're there; you just need to ask for them.

> If I explicitly specify the name server to be one of the root nameservers -
>
> dig +dnssec -t SOA org 198.41.0.4

[snip]

Your dig foo is a bit off today. Remember, to explicitly specify a name
server, you need to prepend the IP address with @. You meant to say:

dig +dnssec -t SOA org @198.41.0.4

What you ended up getting is the RRSIG for the root SOA and for the NSEC
record for '198.41.0.4', since that doesn't exist in DNS.

michael

[Bill Owens]

On Sun, Feb 12, 2012 at 10:22:22AM -0800, Michael Sinatra wrote:
> On 02/12/12 09:40, dE . wrote:
> >I'm trying to see DNSSEC response of various sites; my DNS server is
> >8.8.8.8 (google's public DNS service)

. . .

> >As we can see, the DNSKEY and DS RR is missing which's mandatory for
> >this to be of any use. So where is it?
>
> Well, the DS RR resides in the parent, not in the zone you're querying.
> You need to ask for it explicitly. Although DNSKEY records are in the
> actual zone you're querying, you still need to ask for them explicitly.
> They're there; you just need to ask for them.

As Tony Finch pointed out to me a few days ago, the Google public servers don't understand that fact about DS records, and don't know to ask for them in the parent. But here's something interesting - as of my testing just now, they *do* respond with DS records:

[littledebian:~/dns] owens% dig isc.org @8.8.8.8 ds +dnssec

; <<>> DiG 9.9.0rc2 <<>> isc.org @8.8.8.8 ds +dnssec

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48488
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:

;isc.org. IN DS

;; ANSWER SECTION:
isc.org. 73847 IN DS 12892 5 1 982113D08B4C6A1D9F6AEE1E2237AEF69F3F9759
isc.org. 73847 IN DS 12892 5 2 F1E184C0E1D615D20EB3C223ACED3B03C773DD952D5F0EB5C777586D E18DA6B5
isc.org. 73847 IN RRSIG DS 7 2 86400 20120301160425 20120209150425 55440 org. AaHh8ATWNZqZAfqKxoFS2GyScv46ME2s2sS6lG/AzWzDn6r7R1aXRPIT 2zfDhLfP6yyQSREh8BSd4K98OKfWW2ZSDPxHx3soJotG+N9RFqs33HYR 2rfJNsKDelnLQZvql93HkhblDALFycKHxKZDocNF/DgANJZbhV0qh1c9 5Cs=

;; Query time: 63 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Feb 12 19:19:43 2012
;; MSG SIZE rcvd: 283

They're not setting AD so they aren't validating, and in fact they'll return records with broken signatures, like so:

[littledebian:~/dns] owens% dig pastdate-a.test.dnssec-tools.org @8.8.8.8

; <<>> DiG 9.9.0rc2 <<>> pastdate-a.test.dnssec-tools.org @8.8.8.8

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30272
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pastdate-a.test.dnssec-tools.org. IN A

;; ANSWER SECTION:
pastdate-a.test.dnssec-tools.org. 86400 IN A 75.119.216.33

;; Query time: 154 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Feb 12 19:23:11 2012
;; MSG SIZE rcvd: 77

Still, I think it's a good sign. . .

Bill.

[Mark Andrews]

8.8.8.8 returns servfail for me.

Note a RFC 1035 caching server should be be able to resolve "dig ds org"
though it may not return the response from the parent zone. It depends
on the cache state when the query is made.

Mark

% dig ds org @8.8.8.8

; <<>> DiG 9.7.3-P3 <<>> ds org @8.8.8.8

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62760
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;org. IN DS

;; Query time: 178 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Feb 13 13:40:13 2012
;; MSG SIZE rcvd: 21

%

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[Spain, Dr. Jeffry A.]

> As Tony Finch pointed out to me a few days ago, the Google public servers don't understand that fact about DS records, and don't know to ask for them in the parent. But here's something interesting - as of my testing just now, they *do* respond with DS records

This thread has been kind of confusing, but looking again at the original post (https://lists.isc.org/pipermail/bind-users/2012-February/086586.html), the author was concerned about the lack of DS records in response to his queries. Those two queries, directed to Google's server at 8.8.8.8, were:

dig +dnssec -t SOA org

dig +dnssec -t SOA org 198.41.0.4

I don't think any DS records should have been provided in the answers since SOA records were being requested. Your query:

dig isc.org @8.8.8.8 ds +dnssec

is requesting and receiving DS records, on the other hand.

I also see Mark's post just now where 'dig @8.8.8.8 ds org.' returns SERVFAIL while 'dig @8.8.8.8 ds isc.org.' returns the appropriate DS records. The same thing happens for me with 'dig @8.8.8.8 ds net.' and 'dig @8.8.8.8 ds jaspain.net.', and with 'dig @8.8.8.8 ds com.' and 'dig @8.8.8.8 ds countryday.com.'. Clearly Google's server is malfunctioning in this regard.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

[dE .]

On 02/12/12 23:13, Miek Gieben wrote:

[ Quoting <de.t...@gmail.com> at 23:10 on Feb 12 in "dig -- only RRSIG pr..." ]

I'm trying to see DNSSEC response of various sites; my DNS server is
8.8.8.8 (google's public DNS service)

Google's public resolvers don't handle DNSSEC very well...

grtz Miek

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

They claim that they do support -

http://code.google.com/speed/public-dns/faq.html#dnssec

But, that's not apparent -

dig +dnssec -t A yahoo.com @198.41.0.4

; <<>> DiG 9.8.1 <<>> +dnssec -t A yahoo.com @198.41.0.4

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47278
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 16
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:

;yahoo.com.                     IN      A

;; AUTHORITY SECTION:
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    86400   IN      DS      30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.                    86400   IN      RRSIG   DS 8 1 86400 20120219000000 20120211230000 51201 . lgz7WlGBmaimFXYL+W3TDqi0fFDZGyH2p2OunrTmx93yDdPatscOEm2c 19dxFFiZloABGT9fLrE+FYKmTtGUP/UFWdqfgX3MpTCJrJL2DeJ6m3q+ qMj+OOm+0RWi14jxnvLn8yLqwr5uwzvqpUBGBWJUBM/Qm07Bjg1Jr+pR Ibw=

;; ADDITIONAL SECTION:
a.gtld-servers.net.     86400   IN      AAAA    2001:503:a83e::2:30
a.gtld-servers.net.     86400   IN      A       192.5.6.30
b.gtld-servers.net.     86400   IN      AAAA    2001:503:231d::2:30
b.gtld-servers.net.     86400   IN      A       192.33.14.30
c.gtld-servers.net.     86400   IN      A       192.26.92.30
d.gtld-servers.net.     86400   IN      A       192.31.80.30
e.gtld-servers.net.     86400   IN      A       192.12.94.30
f.gtld-servers.net.     86400   IN      A       192.35.51.30
g.gtld-servers.net.     86400   IN      A       192.42.93.30
h.gtld-servers.net.     86400   IN      A       192.54.112.30
i.gtld-servers.net.     86400   IN      A       192.43.172.30
j.gtld-servers.net.     86400   IN      A       192.48.79.30
k.gtld-servers.net.     86400   IN      A       192.52.178.30
l.gtld-servers.net.     86400   IN      A       192.41.162.30
m.gtld-servers.net.     86400   IN      A       192.55.83.30

;; Query time: 202 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Feb 13 09:52:35 2012
;; MSG SIZE  rcvd: 733

---

dig +dnssec -t A yahoo.com @8.8.8.8

; <<>> DiG 9.8.1 <<>> +dnssec -t A yahoo.com @8.8.8.8

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33152
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:

;yahoo.com.                     IN      A

;; ANSWER SECTION:
yahoo.com.              1683    IN      A       98.137.149.56
yahoo.com.              1683    IN      A       98.139.183.24
yahoo.com.              1683    IN      A       209.191.122.70
yahoo.com.              1683    IN      A       72.30.2.43

;; Query time: 53 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Feb 13 09:53:26 2012
;; MSG SIZE  rcvd: 102

[dE .]

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

But another question remains, where's the DNSKEY record which's the
missing link as of the current time.

Querying --

dig +dnssec -t DNSKEY yahoo.com @198.41.0.4

Does not return anything.

[Spain, Dr. Jeffry A.]

> But another question remains, where's the DNSKEY record which's the missing link as of the current time.
> Querying --
> dig +dnssec -t DNSKEY yahoo.com @198.41.0.4
> Does not return anything.

I think that yahoo.com is probably not a DNSSEC-signed zone and so has no DNSKEY records. Otherwise the query below would return DNSSEC-related records and probably an AD flag. By the way, bind.odvr.dns-oarc.net is a publicly-available DNSSEC-enabled recursive resolver that is good to use for testing purposes. See https://www.dns-oarc.net/oarc/services/odvr. Jeff

PS C:\> dig '@bind.odvr.dns-oarc.net.' yahoo.com +dnssec

; <<>> DiG 9.9.0rc2 <<>> @bind.odvr.dns-oarc.net. yahoo.com +dnssec
; (2 servers found)

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6844
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096

;; QUESTION SECTION:
;yahoo.com. IN A

;; ANSWER SECTION:

yahoo.com. 3600 IN A 72.30.2.43
yahoo.com. 3600 IN A 98.137.149.56
yahoo.com. 3600 IN A 98.139.183.24
yahoo.com. 3600 IN A 209.191.122.70

;; AUTHORITY SECTION:
yahoo.com. 161515 IN NS ns1.yahoo.com.
yahoo.com. 161515 IN NS ns5.yahoo.com.
yahoo.com. 161515 IN NS ns4.yahoo.com.
yahoo.com. 161515 IN NS ns3.yahoo.com.
yahoo.com. 161515 IN NS ns2.yahoo.com.

;; Query time: 795 msec
;; SERVER: 2001:4f8:3:2bc:1:0:64:20#53(2001:4f8:3:2bc:1:0:64:20)
;; WHEN: Sun Feb 12 23:39:39 2012
;; MSG SIZE rcvd: 192

[Mark Andrews]

In message <4F38908...@gmail.com>, "dE ." writes:
>
> On 02/12/12 23:13, Miek Gieben wrote:
> > [ Quoting<de.t...@gmail.com> at 23:10 on Feb 12 in "dig -- only RRSIG pr
> ..." ]
> >> I'm trying to see DNSSEC response of various sites; my DNS server is
> >> 8.8.8.8 (google's public DNS service)
> > Google's public resolvers don't handle DNSSEC very well...
> >
> > grtz Miek
> >
> >

> > _______________________________________________
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscri
> be from this list
> >
> > bind-users mailing list
> > bind-...@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users

> They claim that they do support -
>
> http://code.google.com/speed/public-dns/faq.html#dnssec

Does Google Public DNS support the DNSSEC protocol?
Google Public DNS supports EDNS0 extensions, which means that
we accept and forward DNSSEC-formatted messages; however, we do
not yet validate responses. We will continue to work on improving
Google Public DNS.

Which says nothing about the special handling required for DS. You
also can't be a reliable DNSSEC aware recursive server without
validating the responses or without setting DO on upstream queries
when the client doesn't set DO. If you don't validate you leave
yourself open to cache poisioning which will be detected by downstream
validators and they will have no way to recover. If you don't set
DO on upstream queries you cache will be polluted by non DNSSEC
responses.

The DNSSEC aware recursive server needs a super set of the trust
anchors used by the clients.

All this has been pointed out on dns...@ietf.org so hopefully Google
is paying attention there.

Mark

[dE .]

Using this DNS server, I'm still not getting the DNSKEY for any DNSSEC capable domain; infact this server has issues -

dig +dnssec -t A dnssec.net @bind.odvr.dns-oarc.net.

; <<>> DiG 9.8.1 <<>> +dnssec -t A dnssec.net @bind.odvr.dns-oarc.net.

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40020
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:

;dnssec.net.                    IN      A

;; ANSWER SECTION:
dnssec.net.             43179   IN      A       80.69.95.164
dnssec.net.             43179   IN      A       80.69.93.34

;; AUTHORITY SECTION:
dnssec.net.             172778  IN      NS      ns2.dnssec.net.
dnssec.net.             172778  IN      NS      ns0.dnssec.net.
dnssec.net.             172778  IN      NS      ns3.dnssec.net.
dnssec.net.             172778  IN      NS      ns1.dnssec.net.

;; Query time: 883 msec
;; SERVER: 149.20.64.20#53(149.20.64.20)
;; WHEN: Mon Feb 13 10:41:19 2012
;; MSG SIZE  rcvd: 143

---

dig +dnssec -t A dnssec.net @198.41.0.4            

; <<>> DiG 9.8.1 <<>> +dnssec -t A dnssec.net @198.41.0.4

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18381

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 16
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;dnssec.net.                    IN      A

;; AUTHORITY SECTION:
net.                    172800  IN      NS      a.gtld-servers.net.
net.                    172800  IN      NS      b.gtld-servers.net.
net.                    172800  IN      NS      c.gtld-servers.net.
net.                    172800  IN      NS      d.gtld-servers.net.
net.                    172800  IN      NS      e.gtld-servers.net.
net.                    172800  IN      NS      f.gtld-servers.net.
net.                    172800  IN      NS      g.gtld-servers.net.
net.                    172800  IN      NS      h.gtld-servers.net.
net.                    172800  IN      NS      i.gtld-servers.net.
net.                    172800  IN      NS      j.gtld-servers.net.
net.                    172800  IN      NS      k.gtld-servers.net.
net.                    172800  IN      NS      l.gtld-servers.net.
net.                    172800  IN      NS      m.gtld-servers.net.
net.                    86400   IN      DS      35886 8 2 7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE
net.                    86400   IN      RRSIG   DS 8 1 86400 20120220000000 20120212230000 51201 . FG9Eoc3k1PvDfDoiE5GkpV8ui1/54dsqWoXfQg1OBHwoV915ileT944r 4CrkEKWgrss6YcmVvumbXRiTRaa4v0HM52Pmi/9IlU8KF2pM0thqZqLe liT/awh8uYyEZxludwvvN2AAZKK/uLwQdKwsIf0KCjZ7+RH3nUgG9osu /WU=

;; ADDITIONAL SECTION:
a.gtld-servers.net.     86400   IN      AAAA    2001:503:a83e::2:30
a.gtld-servers.net.     86400   IN      A       192.5.6.30
b.gtld-servers.net.     86400   IN      AAAA    2001:503:231d::2:30
b.gtld-servers.net.     86400   IN      A       192.33.14.30
c.gtld-servers.net.     86400   IN      A       192.26.92.30
d.gtld-servers.net.     86400   IN      A       192.31.80.30
e.gtld-servers.net.     86400   IN      A       192.12.94.30
f.gtld-servers.net.     86400   IN      A       192.35.51.30
g.gtld-servers.net.     86400   IN      A       192.42.93.30
h.gtld-servers.net.     86400   IN      A       192.54.112.30
i.gtld-servers.net.     86400   IN      A       192.43.172.30
j.gtld-servers.net.     86400   IN      A       192.48.79.30
k.gtld-servers.net.     86400   IN      A       192.52.178.30
l.gtld-servers.net.     86400   IN      A       192.41.162.30
m.gtld-servers.net.     86400   IN      A       192.55.83.30

;; Query time: 193 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Feb 13 10:41:12 2012
;; MSG SIZE  rcvd: 731

de@OLD_BROKEN_LAP ~ $ dig +dnssec -t A dnssec.net @bind.odvr.dns-oarc.net.

; <<>> DiG 9.8.1 <<>> +dnssec -t A dnssec.net @bind.odvr.dns-oarc.net.

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40020
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:

;dnssec.net.                    IN      A

;; ANSWER SECTION:
dnssec.net.             43179   IN      A       80.69.95.164
dnssec.net.             43179   IN      A       80.69.93.34

;; AUTHORITY SECTION:
dnssec.net.             172778  IN      NS      ns2.dnssec.net.
dnssec.net.             172778  IN      NS      ns0.dnssec.net.
dnssec.net.             172778  IN      NS      ns3.dnssec.net.
dnssec.net.             172778  IN      NS      ns1.dnssec.net.

;; Query time: 883 msec
;; SERVER: 149.20.64.20#53(149.20.64.20)
;; WHEN: Mon Feb 13 10:41:19 2012
;; MSG SIZE  rcvd: 143

---

I think root nameservers should be used for this purpose, they're definitely DNSSEC capable and the source of all caches.

Also, is it possible that the RRSIG and DS that I'm getting is from the root name servers instead of the servers of the TLD or the sub-domain?

I'd be really happy if I could get some domains which are signed.

[Spain, Dr. Jeffry A.]

> Using this DNS server, I'm still not getting the DNSKEY for any DNSSEC capable domain; infact this server has issues -
> dig +dnssec -t A dnssec.net @bind.odvr.dns-oarc.net.

> I'd be really happy if I could get some domains which are signed.

Try this one: dig @bind.odvr.dns-oarc.net. isc.org +dnssec
You should get an AD flag returned and a variety of RRSIG records. Jeff.

[Michael Sinatra]

On 02/12/12 18:48, Mark Andrews wrote:
>
> 8.8.8.8 returns servfail for me.
>
> Note a RFC 1035 caching server should be be able to resolve "dig ds org"
> though it may not return the response from the parent zone. It depends
> on the cache state when the query is made.

Google seems to be okay at looking up DS records (when asked for them)
for 2nd and 3rd level domains but not for TLDs. Based on some
experimentation with some obscure domains I own, it does seem to be
properly querying the parent. It just does the wrong thing for TLDs (at
this point).

michael

[dE .]

I hope I'm not missing any concepts here, but there should be a public
key to verify the RRSIG, where's that? Shouldn't the server return
additional DNSKEY records?

Also if I replace bind.odvr.dns-oarc.net. with one of the root
nameservers, why is it that AD flag is not set? The root nameservers are
DNSSEC capable.

[Phil Mayers]

On 13/02/12 12:28, dE . wrote:
> On 02/13/12 11:00, Spain, Dr. Jeffry A. wrote:
>>> Using this DNS server, I'm still not getting the DNSKEY for any
>>> DNSSEC capable domain; infact this server has issues -
>>> dig +dnssec -t A dnssec.net @bind.odvr.dns-oarc.net.
>>> I'd be really happy if I could get some domains which are signed.
>> Try this one: dig @bind.odvr.dns-oarc.net. isc.org +dnssec
>> You should get an AD flag returned and a variety of RRSIG records. Jeff.
>
> I hope I'm not missing any concepts here, but there should be a public
> key to verify the RRSIG, where's that? Shouldn't the server return
> additional DNSKEY records?

No.

The RRSIG records are signatures of the name you did the query for, so
are included in the same response.

The DNSKEY records are common to thousands of signatures, and it would
therefore be a waste of bandwidth to include them in every response.
They are separate records, which have to be fetched separately.

[Spain, Dr. Jeffry A.]

>> Try this one: dig @bind.odvr.dns-oarc.net. isc.org +dnssec You should
>> get an AD flag returned and a variety of RRSIG records. Jeff.

> I hope I'm not missing any concepts here, but there should be a public key to verify the RRSIG, where's that? Shouldn't the server return additional DNSKEY records?

The public key is the DNSKEY record whose private key was used to create the RRSIG. It's in the zone data but won't be returned in response to a query from dig unless you ask for it, e.g. 'dig @bind.odvr.dns-oarc.net. isc.org dnskey +dnssec'. That doesn't mean that the recursive resolver, in this case bind.odvr.dns-oarc.net, isn't looking at the DNSKEY records as part of its internal DNSSEC validation process.

> Also if I replace bind.odvr.dns-oarc.net. with one of the root nameservers, why is it that AD flag is not set? The root nameservers are DNSSEC capable.

The AD flag is only set by recursive resolvers that are capable of validating a DNSSEC chain of trust. The root servers are DNSSEC-capable but are authoritative servers, i.e. they only return information from their own zone files and can't validate a chain of trust.

Here's a possibly missing concept. There are three entities involved in your dig queries:
1. A stub resolver, which is your system running dig.
2. A recursive resolver, which is bind.odvr.dns-oarc.net, and which issues a series of queries on your behalf in order to get the answer you asked for and do DNSSEC validation on it. It does so without returning to you the internals of that process.
3. A series of authoritative name servers, which bind.odvr.dns-oarc.net queries to get the answer you want. Again you don't see this activity with dig.

[dE .]

Ok, thanks a lot. I thought it was a client process. Now I can query for
the DS, DNSKEY records from isc.org.

Final question -- bind.odvr.dns-oarc.net is a cache right? Does bind has
such a caching program? Do we have a DNSSEC capable resolver in BIND?

[Phil Mayers]

On 13/02/12 13:03, dE . wrote:

> Ok, thanks a lot. I thought it was a client process. Now I can query for
> the DS, DNSKEY records from isc.org.
>
> Final question -- bind.odvr.dns-oarc.net is a cache right? Does bind has
> such a caching program? Do we have a DNSSEC capable resolver in BIND?

Bind *is* a caching program.

Yes, bind is a DNSSEC-capable resolver.

[Spain, Dr. Jeffry A.]

Given your interest in the internals of the DNSSEC validation process, you should consider building your own bind recursive resolver. You could use wireshark to see all the information flow between it and the various authoritative servers it queries following a 'dig @localhost ...' command. You could use 'rndc flush' between queries so that the cache does not obscure what is happening. Jeff.

[dE .]

On 02/13/12 18:41, Phil Mayers wrote:
> On 13/02/12 13:03, dE . wrote:
>

>> Ok, thanks a lot. I thought it was a client process. Now I can query for
>> the DS, DNSKEY records from isc.org.
>>
>> Final question -- bind.odvr.dns-oarc.net is a cache right? Does bind has
>> such a caching program? Do we have a DNSSEC capable resolver in BIND?
>
> Bind *is* a caching program.
>

I meant the bind package, named is the server.

> Yes, bind is a DNSSEC-capable resolver.

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to

> unsubscribe from this list

>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Thanks for the info! :-)

[dE .]

On 02/13/12 18:57, Spain, Dr. Jeffry A. wrote:
>>> Ok, thanks a lot. I thought it was a client process. Now I can query
>>> for the DS, DNSKEY records from isc.org.
>>> Final question -- bind.odvr.dns-oarc.net is a cache right? Does bind
>>> has such a caching program? Do we have a DNSSEC capable resolver in BIND?
>> Bind *is* a caching program.

>> Yes, bind is a DNSSEC-capable resolver.

> Given your interest in the internals of the DNSSEC validation process, you should consider building your own bind recursive resolver. You could use wireshark to see all the information flow between it and the various authoritative servers it queries following a 'dig @localhost ...' command. You could use 'rndc flush' between queries so that the cache does not obscure what is happening. Jeff.
>

Yes, that's on the way. DNS server/cache using BIND tools. I already
know how to do it with djbdns.

Thanks for all the help!! :-)