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

From: [email-masked] (Ted Lindgreen)
Date: Thu, 24 Apr 2003 09:50:14 +0200

[Quoting =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?=, on Apr 24,  4:20, in "Re: Q-03: inclusion  ..."]

> 	Additional section: glue addresses signed by gtld-servers.net.

Glue was never to be signed, or has this been changed recently?

-- ted

--
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: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 24 Apr 2003 09:51:40 -0400

>Glue was never to be signed, or has this been changed recently?

In this case the server is authoritative for .com and gtld-servers.net.,
so in this case the use of the word "glue" is wrong, but I'm not sure
what the right term is ?

         Olafur

---

From: Paul Vixie <[email-masked]>
Date: Thu, 24 Apr 2003 18:25:36 +0000

> so in this case the use of the word "glue" is wrong, but I'm not sure

it's still glue.  the protocol doesn't permit a client to impute authority
of additional data based on name-similarity to data in other sections which
is claimed as authoritative.

---

From: Peter Koch <[email-masked]>
Date: Thu, 24 Apr 2003 21:41:52 +0200

> it's still glue.  the protocol doesn't permit a client to impute authority

it's not. "glue" is a term for data origin, i.e. there's a difference
between additional data and "glue". The client can't tell that difference.

> 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?

-Peter

---

From: Paul Vixie <[email-masked]>
Date: Thu, 24 Apr 2003 20:27:28 +0000

> > > In this case the server is authoritative for .com and
> > > gtld-servers.net., so in this case the use of the word "glue" is
> > > wrong, but I'm not sure what the right term is ?
> > 
> > it's still glue.  the protocol doesn't permit a client to impute
> > authority ...
> 

correct, it may or may not be glue, depending on how deep the owner
names are.  and because the client can't tell the difference, it has to
be presumed "glue" or at least NOT presumed to be "authoritative".

> > ... 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.

---

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]>

---

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 28 Apr 2003 16:22:13 -0400

>Ed wanted #1 for a period so that we could understand the impact.

Naw, I was fer #3, DavidB was for #1.