Subject: Re: Q-03: inclusion of KEY records in additional records section

From: "Scott Rose" <[email-masked]>
Date: Fri, 25 Apr 2003 14:08:15 -0400

Should this be option 4?
4. "Add KEY/SIG if and only if it can fit without causing truncation"  Or
words to that effect.

But when exactly:  Referrals, or any authoritative response?  And should it
even matter?

Scott

----- Original Message -----
From: "Paul Vixie" <[email-masked]>
>
> > > ... of additional data based on name-similarity to data in other
> > > sections which is claimed as authoritative.
> >
> > Well, the client may not, but why shouldn't the server feed the
> > additional section with authoritative data - if it's signed?
>
> i don't know what the dnssec docset currently says about that, but
> it sounds like a good idea (or a good interpretation if the docset
> is ambiguous on the issue.)
>
> this gets back to the TC question, though.  if the sig/key for
> "authoritative additional data" is available and it will fit then
> i see no problem in adding it.  if it's available but it won't
> fit, though, then it ought not be added, and TC ought not be set.
> so, it's additional-additional-data, or meta-additional-data.
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Apr 2003 14:46:35 -0400

>But when exactly:  Referrals, or any authoritative response?  And should it

I'd say no - don't encourage the extra data until it is demonstrated 
that there is a need for it.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

A compiler-directive person living in an HTML-tagged world.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Apr 2003 16:10:57 -0400

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

>>>>> "Scott" == Scott Rose <[email-masked]> writes:
    Scott> Should this be option 4?
    Scott> 4. "Add KEY/SIG if and only if it can fit without causing
    Scott> truncation"  Or words to that effect.

  This just seems to sensible to me!
  I couldn't understand the origin of this whole conversation, except that
Ed wanted #1 for a period so that we could understand the impact.
 
  And, btw, if the request is TCP *already*, then add it. I.e. TCP doesn't
have a limit.

  The thing that I want, as an application writer, is an audit trail.

  That means that I want to receive the following back when I do a DNS
request (oops, I have RFC2535 in brain, and no useful DS records to pull
down, but, you get the idea), if I have, for instance pre-configured the
trust for the in-addr.arpa. key.
  This is, however, a *local* issue. ("lwres" in bind9-speak)

  The application needs this for auditing.

  But, more to the point, the application needs to also get back data when
there is a signature *FAILURE* that explains the failure. This will require
innovations in the local format.

marajade-[~] mcr 1101 %dig -x 192.139.46.38 txt
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.3.0s20021115 <<>> -x 192.139.46.38 txt
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35628
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 6

;; QUESTION SECTION:
;38.46.139.192.in-addr.arpa.    IN      TXT

;; ANSWER SECTION:
38.46.139.192.in-addr.arpa. 7200 IN     TXT     "X-IPsec-Server(10)=192.139.46.38 AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZTh48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh149ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRR" "RCMWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3fejrfi1H"

;; AUTHORITY SECTION:
...
;; ADDITIONAL SECTION:
38.46.139.192.in-addr.arpa. 7200 IN     SIG     TXT 1 6 7200 20030511005658 20030411005658 28815 46.139.192.in-addr.arpa. DVbqbMbp+Cddqcy+bsNsX6s3CCNpDKqJ4xf5EfMdsoX5b1yLKFwdsrFm hNVAyglQEh2IDmvBfYpTDfbMkGEJUM0/sqmLi2E20mMMUAM3xq7XNNZm AXy1Y5jBSiWGou7q
46.139.192.in-addr.arpa.    7200 IN     SIG     DNSKEY 1 6 7200 20030511005658 20030411005658 1234 139.192.in-addr.arpa. DVbqblahblahblah
46.139.192.in-addr.arpa.    7200 IN     DNSKEY	28815 4 1 AQOrwhatever
139.192.in-addr.arpa.       7200 IN     SIG     DNSKEY 1 6 7200 20030511005658 20030411005658 4523 192.in-addr.arpa. DVbqmoreblahblahblah
139.192.in-addr.arpa.       7200 IN     DNSKEY	1234 4 1 AQOrwhatever
192.in-addr.arpa.           7200 IN     SIG     DNSKEY 1 6 7200 20030511005658 20030411005658 4523 in-addr.arpa. DVbqmoreblahblahblah
192.in-addr.arpa.           7200 IN     DNSKEY	4523 4 1 AQOrwhatever
192.in-addr.arpa.           7200 IN     SIG     DNSKEY 1 6 7200 20030511005658 20030411005658 7789 in-addr.arpa. DVbqmoreblahblahblah
in-addr.arpa.               7200 IN     DNSKEY	7789 4 1 AQOrwhatever
; the following key was axiomatic
in-addr.arpa.               7200 IN     SIG     DNSKEY 1 6 7200 20030511005658 20030411005658 7789 in-addr.arpa. DVbqmoreblahblahblah