[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: dnssec@cafax.se
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Date: Thu, 13 May 2004 14:38:04 -0400
In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Thu, 13 May 2004 13:57:16 EDT." <a06020411bcc96241b621@[192.136.136.83]>
Sender: owner-dnssec@cafax.se
Subject: Re: a view from an application person

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Edward" == Edward Lewis <edlewis@arin.net> writes:
    >> #3 is the MOST likely reason. Particulary when the security aware
    >> local caching name server is on the end-user's laptop.  How does
    >> IT guy find that out?

    Edward> Well, if the log's are engineered right, then the
    Edward> determination of an expired signature would result in this:

    Edward> DATE TIME validation: error: signature out of time
    Edward> (start-end) for NAME/TYPE/CLASS and key <key identifier>

    Edward> ...or something like that.  It would be enough evidence that
    Edward> perhaps the clock was out of sync.

  Yes, that would work. But, that won't be in the logs. 
  This is what will be in the logs:

       DATE TIME ServFAIL for for NAME/TYPE/CLASS

  What I'm advocating is that when I do:

marajade-[/corp/projects/sw5000/proj] mcr 1149 %dig +dnssec @istari4.sandelman.ca. www.sandelman.ca.

; <<>> DiG 9.3.0s20021115 <<>> +dnssec @istari4.sandelman.ca. www.sandelman.ca.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1546
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 12

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.sandelman.ca.              IN      A

;; ANSWER SECTION:
www.sandelman.ca.       7200    IN      CNAME   lox.sandelman.ottawa.on.ca.
www.sandelman.ca.       7200    IN      SIG     CNAME 1 3 7200 20040602001126 20040503001126 3649 sandelman.ca. Gq0B...y7Q=
lox.sandelman.ottawa.on.ca. 7200 IN     A       205.150.200.178
lox.sandelman.ottawa.on.ca. 7200 IN     SIG     A 1 5 7200 20040602001125 20040503001125 21577 sandelman.ottawa.on.ca. T3m....L8T

;; AUTHORITY SECTION:
sandelman.ottawa.on.ca. 7200    IN      NS      nic.sandelman.ottawa.on.ca.
sandelman.ottawa.on.ca. 7200    IN      NS      sns.flora.ca.
sandelman.ottawa.on.ca. 7200    IN      NS      nox6.sandelman.ottawa.on.ca.
sandelman.ottawa.on.ca. 7200    IN      SIG     NS 1 4 7200 20040602001125 20040503001125 21577 sandelman.ottawa.on.ca. PzRI...MtJ6

;; ADDITIONAL SECTION:
nic.sandelman.ottawa.on.ca. 7200 IN     A       207.176.162.14
nic.sandelman.ottawa.on.ca. 7200 IN     A       192.139.46.33
nic.sandelman.ottawa.on.ca. 7200 IN     A       205.150.200.129
nic.sandelman.ottawa.on.ca. 7200 IN     A       205.150.200.177
nic.sandelman.ottawa.on.ca. 7200 IN     AAAA    2002:c08b:2e21:1:2c0:a8ff:fe4e:818c
nox6.sandelman.ottawa.on.ca. 7200 IN    AAAA    2002:cd96:c8a1::20
nic.sandelman.ottawa.on.ca. 7200 IN     SIG     A 1 5 7200 20040602001125 20040503001125 21577 sandelman.ottawa.on.ca. DxK...2wnC
nic.sandelman.ottawa.on.ca. 7200 IN     SIG     AAAA 1 5 7200 20040602001125 20040503001125 21577 sandelman.ottawa.on.ca. eTE...wfi
nox6.sandelman.ottawa.on.ca. 7200 IN    SIG     AAAA 1 5 7200 20040602001125 20040503001125 21577 sandelman.ottawa.on.ca. D1U.../4rX
sandelman.ottawa.on.ca. 7200    IN      KEY     256 3 1 AQO...SbU=
sandelman.ottawa.on.ca. 7200    IN      SIG     KEY 1 4 7200 20040602001125 20040503001125 21577 sandelman.ottawa.on.ca. L+Cd...dhr


That I should get the following back in addition:

     1) a SIG for ottawa.on.ca/on.ca/ca/. (if that was the route things
	took). 
     2) some kind of extra data that told me that things stopped at .
	because it was where the trusted anchor was.
	(in this case, it was locally trusted to sandelman.ottawa.on.ca.)

And, that I want all of this stuff on SERVFAIL as well. I want to know
how far we got before things failed.

    Edward> No - I've never suggested that the victim in the situation
    Edward> do the debugging.

    >> Ask them to click on the "email details to IT" button on the
    >> dialogue?  I think so.

    Edward> The email would just need to identify the query details and
    Edward> the iterative server used to do the lookup.  From there it
    Edward> should work.

  Doubtful. 

  If the iterative server follows BCP, then the IT guy won't be able to
do recursive queries to it to find out what it thinks. Worst, the
iterative server is local, and the laptop is off by the time the query
gets to the IT guy.

  Note I am specifically assuming that the end-user is in some remote
location - i.e. a hotel room, and that calling the Hotel's IT is a total
loss.  The user contacts their own IT people first. 

    >> Ed might answer, "but that is the debugger application" - but I
    >> disagree. It isn't.  It is a bunch of information that got
    >> captured as a text file and got emailed. (or printed. Maybe email
    >> doesn't work as a result)

    Edward> I don't understand you.  The email is part of the error
    Edward> notification, not even part of debugging.  The debugging
    Edward> tools come into play later.

  Sure, but the error notification under the "ServFAIL is enough" policy
is content free.

    >> I just want additional information returned in all cases.

    Edward> That's an untestable requirement.  "What additional?" for
    Edward> starters. Define that for the realm of applications, not any
    Edward> one or ones in particular.  

  My application is Opportunistic Encryption, it's purpose is privacy.
  But, I think my arguments would apply to SSHKEY use as well.

  I know of no other DNSSEC aware applications to date.

- --
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQKPAioqHRg3pndX9AQHkTQP+ONVy4Sxx9K8iQ7do9lQxVAMNrKSTfOlF
JsLpHsttp8uoLzjLlCuB1sX2NWowsYghxN4tkqz/Qlvj2UcX5hl/z3JMh3Dsh54G
YhB/RFnGWQTzkt1hO7C/sawnqIT3NkoFXrF3V0aY+FthFdOki0YTLPPNedRa5dv4
ylUy+8c9rUI=
=TQqD
-----END PGP SIGNATURE-----

Home | Date list | Subject list