Message-Id: <199605162307.QAA21043@toad.com>
To: dns-security@TIS.COM, gnu@toad.com
Subject: Lame delegation for sd-bogus.tis.com
Date: Thu, 16 May 1996 16:07:18 -0700
From: John Gilmore <gnu@toad.com>
Sender: dns-security-approval@neptune.tis.com
Precedence: bulk

I've been testing against your Secure DNS server.  This isn't a bug
report against the code, but against the domain records you are
serving from TIS.

The NS records for sd-bogus.tis.com at its parent, tis.com, say that
you have two name servers for it, relay.tis.com and uranus.tis.com.

This isn't actually true, though.  
relay.tis.com is not authoritative for sd-bogus.tis.com, and
uranus.tis.com only lists itself as a name server for sd-bogus.tis.com.

I suggest fixing the records at the tis.com servers, so that they
only list uranus.tis.com.

	John Gilmore


Received: from relay.tis.com by neptune.TIS.COM id aa04433; 17 May 96 13:33 EDT
Received: by relay.tis.com; id NAA16352; Fri, 17 May 1996 13:35:22 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
	id xma016320; Fri, 17 May 96 13:34:58 -0400
Received: from antares.tis.com by tis.com (4.1/SUN-5.64)
	id AA11648; Fri, 17 May 96 13:35:10 EDT
Message-Id: <9605171735.AA11648@tis.com>
To: John Gilmore <gnu@toad.com>
Cc: dns-security@TIS.COM
Subject: Re: Lame delegation for sd-bogus.tis.com 
In-Reply-To: Your message of "Thu, 16 May 1996 16:07:18 MST."
             <199605162307.QAA21043@toad.com> 
Date: Fri, 17 May 1996 13:35:16 -0500
From: Olafur Gudmundsson <ogud@TIS.COM>
Sender: dns-security-approval@neptune.tis.com
Precedence: bulk


John Gilmore writes:
 > I've been testing against your Secure DNS server.  This isn't a bug
 > report against the code, but against the domain records you are
 > serving from TIS.
 > 
 > The NS records for sd-bogus.tis.com at its parent, tis.com, say that
 > you have two name servers for it, relay.tis.com and uranus.tis.com.
 > 
 > This isn't actually true, though.  
 > relay.tis.com is not authoritative for sd-bogus.tis.com, and
 > uranus.tis.com only lists itself as a name server for sd-bogus.tis.com.
 > 
 > I suggest fixing the records at the tis.com servers, so that they
 > only list uranus.tis.com.
 > 
 > 	John Gilmore
 > 
Thanks pointing this out, the NS records have been fixed 

	Olafur

Received: from relay.tis.com by neptune.TIS.COM id aa24241; 29 May 96 8:07 EDT
Received: by relay.tis.com; id IAA22052; Wed, 29 May 1996 08:08:29 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
	id xma022050; Wed, 29 May 96 08:08:00 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
	id AA06752; Wed, 29 May 96 08:08:08 EDT
Received: by relay.tis.com; id IAA22047; Wed, 29 May 1996 08:07:59 -0400
Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1)
	id xma022045; Wed, 29 May 96 08:07:37 -0400
Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id FAA23126; Wed, 29 May 1996 05:10:11 -0700 (PDT)
Message-Id: <199605291210.FAA23126@toad.com>
X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol
To: dns-security@TIS.COM, gnu@toad.com
Subject: CD bit set incorrectly in query responses; SIG-only responses
Date: Wed, 29 May 1996 05:10:10 -0700
From: John Gilmore <gnu@toad.com>
Sender: dns-security-approval@neptune.tis.com
Precedence: bulk

[Last time I sent email to this address I received a flame back from
someone I had never met.  If this is the wrong address to report bugs
in the TIS DNS Security code, somebody please let me know the right one.]

I'm testing an independent implementation of DNS Security against the
TIS server.  I've found that when sending DNS requests to
uranus.tis.com, I get back query headers that set the "CD" bit
(checking disabled), even though my resolver never sent queries that
set the bit.  I verified this with an ethernet packet monitor.  (This
may have never been tested, since old dig's won't print the CD bit,
and your new dig's may be setting the CD bit themselves.)  Try:

	dig @uranus.tis.com sd-bogus.tis.com. soa

Here's what I get:

; <<>> DiG 2.1 <<>> @uranus.tis.com sd-bogus.tis.com. soa 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa rd ra cd; Ques: 1, Ans: 1, Auth: 1, Addit: 0
;; QUESTIONS:
;;	sd-bogus.tis.com, type = SOA, class = IN

;; ANSWERS:
sd-bogus.tis.com.	10000	SIG	SOA  1 10000 833143035 830551042 0xbfd2 sd-bogus.tis.com. PoW60a+MQzjdXjjF4xgvtZ9ZkAUKCKnlTkPitGAyzFbRzbJd136a8OHvnViRFo6udNJLUYccfdQvfVcS0o2kVsRTMkQpp/Z+/9/rHFAPHXE=

;; AUTHORITY RECORDS:
sd-bogus.tis.com.	10000	SIG	NS  1 10000 833143035 830551042 0xbfd2 sd-bogus.tis.com. u0ZPTKcyHyg6pZDb22nWPVDNlNqY2Bkeh6WyVwTIM0KPDi6ghaLybMsp2QhHOg4YawC4Ky0EtKcf/ckCOY/Zc+Q9apn+u5P2jcFRxSDOHgc=

;; Total query time: 90 msec
;; FROM: toad.com to SERVER: uranus.tis.com  192.94.214.95
;; WHEN: Wed May 29 05:03:58 1996
;; MSG SIZE  sent: 34  rcvd: 258


Note also that the query results themselves are also incorrect.
Though I asked for an SOA record, I got back one SIG record, but
no SOA records.  The additional data section includes a SIG record
but no NS records.

I get this same result (query results only include SIGs) using TIS's
dig program instead of my own.  I'll append that output below.

	John Gilmore

; <<>> DiG 2.1 <<>> @uranus.tis.com sd-bogus.tis.com. soa 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa rd ra ad; Ques: 1, Ans: 1, Auth: 1, Addit: 0
;; QUESTIONS:
;;	sd-bogus.tis.com, type = SOA, class = IN

;; ANSWERS:
sd-bogus.tis.com.	10000	SIG	SOA (
		1 ; alg labels=3
		10000  ; TTL
		19960526203715	; Signature expiration
		19960426203722	; time signed 
		49106	; Key foot print
		sd-bogus.tis.com.	; Signers name
		PoW60a+MQzjdXjjF4xgvtZ9ZkAUKCKnlTkPitGAyzFbRzbJd136a8OHvnViRFo6udNJLUYccfdQvfVcS0o2kVsRTMkQpp/Z+/9/rHFAPHXE=
	) ; END Signature

;; AUTHORITY RECORDS:
sd-bogus.tis.com.	10000	SIG	NS (
		1 ; alg labels=3
		10000  ; TTL
		19960526203715	; Signature expiration
		19960426203722	; time signed 
		49106	; Key foot print
		sd-bogus.tis.com.	; Signers name
		u0ZPTKcyHyg6pZDb22nWPVDNlNqY2Bkeh6WyVwTIM0KPDi6ghaLybMsp2QhHOg4YawC4Ky0EtKcf/ckCOY/Zc+Q9apn+u5P2jcFRxSDOHgc=
	) ; END Signature

;; Total query time: 116 msec
;; FROM: toad.com to SERVER: uranus.tis.com  192.94.214.95
;; WHEN: Wed May 29 05:04:09 1996
;; MSG SIZE  sent: 34  rcvd: 258


Received: from relay.tis.com by neptune.TIS.COM id aa25546; 29 May 96 9:22 EDT
Received: by relay.tis.com; id JAA25148; Wed, 29 May 1996 09:23:51 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
	id xma025131; Wed, 29 May 96 09:23:42 -0400
Received: from antares.tis.com by tis.com (4.1/SUN-5.64)
	id AA12299; Wed, 29 May 96 09:23:47 EDT
Message-Id: <9605291323.AA12299@tis.com>
To: John Gilmore <gnu@toad.com>
Cc: ogud@TIS.COM, tisdnssec-support@TIS.COM, dns-security@TIS.COM
Subject: Re: CD bit set incorrectly in query responses; SIG-only responses 
In-Reply-To: Your message of "Wed, 29 May 1996 05:10:10 PDT."
             <199605291210.FAA23126@toad.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <14082.833376243.1@tis.com>
Date: Wed, 29 May 1996 09:24:05 -0400
From: Olafur Gudmundsson <ogud@TIS.COM>
Sender: dns-security-approval@neptune.tis.com
Precedence: bulk

John Gilmore writes:
 > [Last time I sent email to this address I received a flame back from
 > someone I had never met.  If this is the wrong address to report bugs
 > in the TIS DNS Security code, somebody please let me know the nright one.]
The address to reach the implementers is 
	tisdnssec-support@tis.com  

I think this mailing list is an appropriate forum to discuss 
inter-operational issues. If someone has problems with that please speak 
up. 

I will reply to John's other questions after I have a cup of coffee and
check the code.
	Olafur 

Received: from relay.tis.com by neptune.TIS.COM id aa01522; 29 May 96 14:26 EDT
Received: by relay.tis.com; id OAA06101; Wed, 29 May 1996 14:28:31 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
	id xma006092; Wed, 29 May 96 14:28:23 -0400
Received: from antares.tis.com.tis.com by tis.com (4.1/SUN-5.64)
	id AA28649; Wed, 29 May 96 14:28:29 EDT
Date: Wed, 29 May 96 14:28:29 EDT
From: Olafur Gudmundsson <ogud@TIS.COM>
Message-Id: <9605291828.AA28649@tis.com>
Received: by antares.tis.com.tis.com (4.1/SMI-4.1)
	id AA14480; Wed, 29 May 96 14:28:48 EDT
To: John Gilmore <gnu@toad.com>
Cc: ogud@TIS.COM, tisdnssec-support@TIS.COM, dns-security@TIS.COM
Subject: Re: CD bit set incorrectly in query responses; SIG-only responses 
In-Reply-To: Your message of "Wed, 29 May 1996 05:10:10 PDT."
             <199605291210.FAA23126@toad.com> 
Sender: dns-security-approval@neptune.tis.com
Precedence: bulk


John Gilmore writes:
 > I'm testing an independent implementation of DNS Security against the
 > TIS server.  I've found that when sending DNS requests to
 > uranus.tis.com, I get back query headers that set the "CD" bit
 > (checking disabled), even though my resolver never sent queries that
 > set the bit.  I verified this with an ethernet packet monitor.  (This
 > may have never been tested, since old dig's won't print the CD bit,
 > and your new dig's may be setting the CD bit themselves.)  Try:
 > 
 > 	dig @uranus.tis.com sd-bogus.tis.com. soa
 > 
 > Here's what I get:
 > 
 > ; <<>> DiG 2.1 <<>> @uranus.tis.com sd-bogus.tis.com. soa 
 > ; (1 server found)
 > ;; res options: init recurs defnam dnsrch
 > ;; got answer:
 > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
 > ;; flags: qr aa rd ra cd; Ques: 1, Ans: 1, Auth: 1, Addit: 0
 > ;; QUESTIONS:
 > ;;	sd-bogus.tis.com, type = SOA, class = IN
 > 
 > ;; ANSWERS:
 > sd-bogus.tis.com.	10000	SIG	SOA  1 10000 833143035 830551042 0xbfd2
 >> sd-bogus.tis.com. PoW60a+MQzjdXjjF4xgvtZ9ZkAUKCKnlTkPitGAyzFbRzbJd136a8OHvn
 >>ViRFo6udNJLUYccfdQvfVcS0o2kVsRTMkQpp/Z+/9/rHFAPHXE=
 > 
 > ;; AUTHORITY RECORDS:
 > sd-bogus.tis.com.	10000	SIG	NS  1 10000 833143035 830551042 0xbfd2 
 >>sd-bogus.tis.com. u0ZPTKcyHyg6pZDb22nWPVDNlNqY2Bkeh6WyVwTIM0KPDi6ghaLybMsp2Q
 >>hHOg4YawC4Ky0EtKcf/ckCOY/Zc+Q9apn+u5P2jcFRxSDOHgc=
 > 
 > ;; Total query time: 90 msec
 > ;; FROM: toad.com to SERVER: uranus.tis.com  192.94.214.95
 > ;; WHEN: Wed May 29 05:03:58 1996
 > ;; MSG SIZE  sent: 34  rcvd: 258
John 
Good to have you implement DNSSEC.  

I do not see the CD bit set. (Notice that in the output from my version of dig 
in your original question below, the cd bit is not reported as set). 
There is one place in my code that sets the cd bit (in mk_query()).

When the bind server is answering the query above it does not execute that line. 
 
When running gdb dig I get the following header with the above query. 
(gdb) where
#0  __fp_nquery (msg=0xefffd778 "", len=136, file=0x232b4) at res_debug.c:342
#1  0x1a934 in res_send (buf=0xeffff778 "", buflen=34, ans=0xefffd778 "", 
    anssiz=8192) at res_send.c:708
#2  0x4598 in main (argc=3, argv=0xefffd384) at dig.c:660
(gdb) p *hp
$6 = {id = 6, qr = 1, opcode = 0, aa = 0, tc = 0, rd = 1, ra = 1, unused = 0, 
  cd = 0, ad = 0, rcode = 0, qdcount = 1, ancount = 1, nscount = 1, 
  arcount = 1}

Neither CD or AD bit is set. 
This looks like your and my implementation do not agree on the location of
cd bit. (an inter-operation problem that we need to figure out). 
The values of the third and fourth byte (header flags) are (on a Sparc)
(gdb) printf "%x %x\n", *(msg+2), *(msg+3) 
81 80

If the CD bit was set the value of the fourth byte would be "a0"

 > 
 > 
 > Note also that the query results themselves are also incorrect.
 > Though I asked for an SOA record, I got back one SIG record, but
 > no SOA records.  The additional data section includes a SIG record
 > but no NS records.
 > 
 > I get this same result (query results only include SIGs) using TIS's
 > dig program instead of my own.  I'll append that output below.
 > 
 > 	John Gilmore

This is the current behavior when the signatures have expired!!  
NOT correct and not the best one but one that people notice. 
This is one of the open questions in the DNSSEC work.
What to return when the signatures expire.
DNSSEC draft does not explicitly state what to return, and we should 
talk about this issue. 

John lets take the inter-operation question of the CD bit off-line and
resolve it. 

I will raise the larger question of what to return when the data is expired,
on this and other appropriate mailing lists. 

	Olafur 
 > 
 > ; <<>> DiG 2.1 <<>> @uranus.tis.com sd-bogus.tis.com. soa 
 > ; (1 server found)
 > ;; res options: init recurs defnam dnsrch
 > ;; got answer:
 > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
 > ;; flags: qr aa rd ra ad; Ques: 1, Ans: 1, Auth: 1, Addit: 0
 > ;; QUESTIONS:
 > ;;	sd-bogus.tis.com, type = SOA, class = IN
 > 
 > ;; ANSWERS:
 > sd-bogus.tis.com.	10000	SIG	SOA (
 > 		1 ; alg labels=3
 > 		10000  ; TTL
 > 		19960526203715	; Signature expiration
 > 		19960426203722	; time signed 
 > 		49106	; Key foot print
 > 		sd-bogus.tis.com.	; Signers name
 > 		PoW60a+MQzjdXjjF4xgvtZ9ZkAUKCKnlTkPitGAyzFbRzbJd136a8OHvnViRFo6
 >>udNJLUYccfdQvfVcS0o2kVsRTMkQpp/Z+/9/rHFAPHXE=
 > 	) ; END Signature
 > 
 > ;; AUTHORITY RECORDS:
 > sd-bogus.tis.com.	10000	SIG	NS (
 > 		1 ; alg labels=3
 > 		10000  ; TTL
 > 		19960526203715	; Signature expiration
 > 		19960426203722	; time signed 
 > 		49106	; Key foot print
 > 		sd-bogus.tis.com.	; Signers name
 > 		u0ZPTKcyHyg6pZDb22nWPVDNlNqY2Bkeh6WyVwTIM0KPDi6ghaLybMsp2QhHOg4
 >>YawC4Ky0EtKcf/ckCOY/Zc+Q9apn+u5P2jcFRxSDOHgc=
 > 	) ; END Signature
 > 
 > ;; Total query time: 116 msec
 > ;; FROM: toad.com to SERVER: uranus.tis.com  192.94.214.95
 > ;; WHEN: Wed May 29 05:04:09 1996
 > ;; MSG SIZE  sent: 34  rcvd: 258
 > 

Received: from relay.tis.com by neptune.TIS.COM id aa20855; 30 May 96 11:40 EDT
Received: by relay.tis.com; id LAA25186; Thu, 30 May 1996 11:41:38 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
	id xma025181; Thu, 30 May 96 11:41:11 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
	id AA19552; Thu, 30 May 96 11:41:18 EDT
Received: by relay.tis.com; id LAA25172; Thu, 30 May 1996 11:41:09 -0400
Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1)
	id xma025167; Thu, 30 May 96 11:41:01 -0400
Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id LAA19926 for <dns-security@TIS.COM>; Thu, 30 May 1996 11:43:55 -0400
Received: from edisto.watson.ibm.com (edisto.watson.ibm.com [9.2.23.43]) by mailhub1.watson.ibm.com (8.7.1/03-28-96) with SMTP id LAA43959 for <dns-security@TIS.COM>; Thu, 30 May 1996 11:43:36 -0400
Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524)
          id AA20189; Thu, 30 May 1996 11:43:46 -0400
Message-Id: <9605301543.AA20189@edisto.watson.ibm.com>
X-External-Networks: yes
To: dns-security@TIS.COM
Subject: Secure DNS Dynamic Update draft
Date: Thu, 30 May 96 11:43:46 -0500
From: "Edie E. Gunter" <edie@watson.ibm.com>
Sender: dns-security-approval@neptune.tis.com
Precedence: bulk

Using the security scheme outlined in this draft, how does one
dynamically add a new name to a DNS database?  That is, the name 
doesn't exist in DNS and I want to send in an update to create 
it there, so I need to authenticate the update with a KEY of some 
sort.  Which KEY would that be?  Section 3.1.1 seems to suggest that 
there would be a wildcard already defined for the zone, and I should 
have the private part of that key in order to sign my update.  Is
that correct?  What about the zone key?  If there is a zone
key defined (and there must be, right?) then can I use it
to sign an update that creates a new name?

Then, is there anything special about setting up a "user" KEY
RR for this new name?  I want to allow a user to do further
updates on that name using its own KEY rather than a wildcard
or zone key.  Would this new KEY RR being created dynamically
just be signed by the wildcard key or zone key as above?  This
would seem to satisfy the requirement that its authority be
traceable to the zone key, but is there some other subltely
I'm missing?

It seems that the wildcard key, like the zone key is one that
you'd want to keep to just an administrator or two.  You wouldn't
want everyone to have the private part of the wildcard key, or
they could step on each other's updates using it for authentication,
right?  So, this would imply that adding new names is something
that a sys-admin would do and is not something that individual
users would do on their own.  Is that the intention?

Edie