Hi,

Although I'm not new to DNS, I'm new to DNSSEC.  I have read
documentation and howtos regarding DNSSEC.

I believe that I have it configured and working for my domain,
lotspeich.org.  I have registered with the ISC's DLV registry.  I am
having trouble finding the best way for me to validate that my setup is
working and that my zone validates.  I've looked into drill and
dnssec-tools, but it isn't clear to me how to use these tools with ISC's
DLV.

Any help would be greatly appreciated.

Regards,

Erik.

Hi Erik,

For me:

dig +dnssec lotspeich.org
does return RRSIG but no "ad" (authenticated data) flag.

lotspeich.org.dlv.isc.org doesn't yet exist in ISC's DLV.

dig +dnssec lotspeich.org.dlv.isc.org DLV
for me is flagged "ad" and NXDOMAIN

(Maybe wait until served by the ISC DLV nameservers? I didn't check
internally if was registered.)

The simplest way is to configure a caching only server to
    use dlv and run queries against it.

    dig +adflag soa <zone>
    dig +dnssec soa <zone>

    and look for the "ad" flag in the response.

e.g.

; <<>> DiG 9.3.6-P1 <<>> +adflag isc.org soa
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41624
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;isc.org.            IN    SOA

;; ANSWER SECTION:
isc.org.        7030    IN    SOA    ns-int.isc.org. hostmaster.isc.org. 2009061200 7200 3600 24796800 3600

;; AUTHORITY SECTION:
isc.org.        35695    IN    NS    ns-ext.nrt1.isc.org.
isc.org.        35695    IN    NS    ams.sns-pb.isc.org.
isc.org.        35695    IN    NS    ord.sns-pb.isc.org.
isc.org.        35695    IN    NS    sfba.sns-pb.isc.org.

;; ADDITIONAL SECTION:
ams.sns-pb.isc.org.    35695    IN    A    199.6.1.30
ord.sns-pb.isc.org.    35695    IN    A    199.6.0.30
sfba.sns-pb.isc.org.    35695    IN    A    149.20.64.3
sfba.sns-pb.isc.org.    35693    IN    AAAA    2001:4f8:0:2::19

;; Query time: 180 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jun 12 12:07:03 2009
;; MSG SIZE  rcvd: 243

    Note the DLV record for lotspeich.org is not currently being
    published.  When you look at "Managed Zones" you should see
    as green tick and "Good" for the records to be published.
    If you don't see this then look at "Help" to what is being
    reported.   If you can't address the problem use the
    "Contact Us" link.

; <<>> DiG 9.3.6-P1 <<>> dlv lotspeich.org.dlv.isc.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25701
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;lotspeich.org.dlv.isc.org.    IN    DLV

;; AUTHORITY SECTION:
dlv.isc.org.        3440    IN    SOA    ns-int.isc.org. hostmaster.isc.org. 2009060800 7200 3600 2419200 3600

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jun 12 12:00:30 2009
;; MSG SIZE  rcvd: 97

    Mark

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka*******

dlv.isc.org doesn't list your keys yet. It can take a day or two for DLV
records to appear after your DNSKEY and cookie records have been
checked. If you just added the zone to dlv.isc.org and it still shows a
"pending validation" state, try "request re-check" in the DNSKEY Details
section to force immediate validation.

Once your DLV record shows up, you may query external validating
resolvers and see if they set the AD flag in response. OARC operates
resolvers validating against dlv.isc.org. See their website at: https://www.dns-oarc.net/oarc/services/odvr

dig +adflag lotspeich.org @149.20.64.20
dig +adflag lotspeich.org @149.20.64.21

A successful validation should look like this:
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6841
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
[...]              ^^

Future reference: Once .org completes their testing phase *and* your
registrar allows you to register DS records for your domain, queries
should also return AD when validated against the ITAR trust anchor
repository (at  https://itar.iana.org/ ):

dig +adflag lotspeich.org @149.20.64.22

I also run a somewhat-public resolver using the dnssec.iks-jena.de DLV
( http://www.iks-jena.de/leistungen/dnssec.php ):

dig +adflag lotspeich.org @85.10.240.255

Hauke.

I got that one wrong. My apologies. That resolver uses IANA's version of a
signed root ( https://ns.iana.org/ ), not ITAR.

Personally, I don't expect to add DS records for my .org domains within the
next two or three years, anyway. By the time the domain registration
services I use add working DS support, the root zone could possibly already
be signed.

Hauke.

The root is supposed to be signed by the end of the year.
    IANA is already collecting DS / DNSKEY records for inclusion
    in the signed root.

    A compentent registrar would be looking to add support for
    DS records now as once the root is signed there is no longer
    any real excuse to delay anymore.

    Similarly there is no excuse for not accepting AAAA as glue
    these days.

    Mark

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka*******

Hi Hauke,

I now get the AD flag when querying external validating resolvers such
as the ones you mention.

I believe that my BIND is configured properly to be a validating
resolver as well:

# dig +adflag *******.

; <<>> DiG 9.6.1 <<>> +adflag *******.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62029
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

Is it normal that a validating resolver can't validate a domain it is
authoritative for?

# dig +adflag *******.

; <<>> DiG 9.6.1 <<>> +adflag *******.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1087
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

I don't get the AD flag here.

Thanks again,

Erik.

That's good.
May your signatures never expire and your keys always be valid.

Looks good.

It could but it doesn't, as it implicitly trusts its storage backend.
Instead, you see the AA (authoritative answer) flag instead of AD.

If you want BIND to check signatures and set the AD flag, you would have
to set up views, with the authoritative zones in one view and forwarding
zones in another.

Hauke.

a DNSSEC validating resolver should not be authoritative for any  
signed zones.

Chris Buxton
Professional Services
Men & Mice

In message <69BEB178-F30D-4AC2-8E7A-B13C1F5F85CF*******>, Chris Buxton
writes:

    That's also why there is the "recursion-only" option with
    view selection.


Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka*******

You presumably refer to

   https://lists.isc.org/pipermail/bind-users/2009-January/0747[..]

which I *suppose* counts as "not long ago" ... :-)

This seems too strong to me, There are lots of good reasons why one may
want a resolver to stealth slave local (possibly signed) zones, and thus
be "authoritative" for them. However, it is certainly the case that because
no other validation is performed on these zones, they should be fetched
by secure means, e.g. TSIG-signed transfers from trusted master servers.

--
Chris Thompson
Email: cet1*******

That's not long ago to me... it was this year after all. :-)

As a purist, I dislike stealth slaves. They're too error-prone. It's  
better to use a stub zone if necessary, in my opinion.

resolvers) are querying the server, then yes, there is a valid case to  
be made for a stealth slave. But even then, if the zone has any  
subzones, or might ever be given any subzones, then I believe there  
will be problems unless the resolving stealth slave is also given  
trust anchors for all such subzones. It's better and simpler, then, to  
use a single trust anchor and a stub zone (a resolver hint) for the  
domain apex rather than a slave zone.

Chris Buxton
Professional Services
Men & Mice

Hi Chris,

Thanks for your response -- that explains it.  I hope that you don't
mind if I continue this discussion with another question.

I changed my configuration to use views to separate my external zone
(for which BIND is authoritative) from internal clients (which should
use BIND as a validating resolver).  I now receive the expected behavior
- -- sort of.

root*******

; <<>> DiG 9.6.1 <<>> +dnssec +adflag *******
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60454
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

root*******

; <<>> DiG 9.6.1 <<>> +adflag *******
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3194
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

As you can see, the ad bit is set when +dnssec is used along with
+adflag.  However, I can receive the ad bit without +dnssec when making
other queries:

root*******.

; <<>> DiG 9.6.1 <<>> +adflag isc.org.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6612
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

Is this expected or do I need to fine-tune my configuration further?

Thanks,

Erik.