Subject: dnsind minutes (first pass)

From: Randy Bush <[email-masked]>
Date: Tue, 15 Dec 1998 10:31:58 -0800 (PST)

[ i am too ill to check these, but they need to go out.  please send
comments to me.  apologies -- rb ]

DNSIND-WG
December 8, 1998
10:15 - 11:30
Chair: Randy Bush
Minutes: David Conrad

Agenda Items:
- IND Interoperability testing at the Orlando IETF
- RFC 1982
- Binary Labels
- DNAME
- DNS Error
- EDNS0
- EDNS1
- Local Compression
- 2052bis
- TSIG
- UTF-8
- Simple Update
- DNS Lookup (A6) 
- Test TLDs
- Local Name
- APL RR

IND interoperability
- Start testing around 3:30 on Dec 8
- Testing dynamic update, notify
- Only 1 IXFR implementation, so won't be tested
- Talk to Olafur Gudmundsson <[email-masked]> about interoperability
  testing at the next IETF

RFC 1982
- Suggestion to move RFC1982 from proposed to draft standard: no dissention

Binary Labels
- Draft currently waiting in the IESG queue due to dependencies (edns0).
- One known implementation of converters to/from binary labels (ISC)

DNAME
- Draft currently waiting in the IESG queue due to dependencies (EDNS0).

DNS Error
- Subsumed under EDNS1, should it be broken out and revitalized?  
- No response so no action
- Further work on DNS Error waits on EDNS1

EDNS0
- Down to the nits
- Question asked by chair: ready to go?  No dissention
- Document will be pushed to the IESG

EDNS1
- Question asked by the chair: any progress? No

Local Compression
Some changes in draft
- pointers into owner name count labels not octets
- fixed offset base for local pointers into rdata: 128 max
- offset 127 reserved for future use
- open issue: rr candidates for implementation (a6, dname)
- open issue: domain name compression for very large rdata
	- edns will address this
- ready for PS?
Discussion:
- local compression will only work on rdatas up to 16 K
- draft changes compression for all previous records after 1034/1035
- draft clarifies in all record types not well known, standard and
  local compression must not be used
Question: what about local compression interaction with bitstring
          labels, is a max value of 128 enough?
Followup: in binary labels, each bit can be a label, so more than 128
          labels can be in a name
Answer: don't use compression in cases that won't work.  Document the
        limits in an applicability statement.
Question asked: can 128 be increased?
Followup: is there a maximum label length if bitstring labels included?  
Answer to Followup: 256 is maximum implied by DNSSEC
Action: change 128 to 256 to conform with DNSSEC
Action: revise document and submit it for WG last call

2052bis 
- Needs new draft and another last call
- IESG requests limited scope applicabilty statement -- who is required
  to implement 2052bis?
- Answer: implementation up to implementor, this to be noted in the
  revised draft.

TSIG
In last call
Question: should cannonicalization be performed before signing?
Discussion: implications when using non-ASCII characters sets
            need to define canonicalization for non-ASCII
            all US ASCII values should be downcased.
Question: how does this operate with binary labels
Answer: binary labels can be identified so canonnicalization is required

UTF-8
Last suggestion: declare extended label type to define language using
                 chararcter set MIB
Question: would it be possible to create a separate DNS tree using
          UTF-8 (e.g. utf-8 .COM differ from us-ascii .COM)?
Response: draft needs to be revised -- no straightforward solution
Discussion: RFC 2181 indicates non-ASCII allowed, this causes a
            problem for which there is no straightforward solution
Stuart Kwan will revise and repost a draft, further discussion should
move to the mailing list

Simple Update
Description
- Easy to implement and comprehend
- Fast TSIG authentication on dynamic update messages
- Server specified policy for validation of auth updates
	- Any policy can be implemented
		- All policy specified in server, arbitrary policy allowed
	- Extendible without modifications to the protocol
- Does not require DNSSEC
- Zone key must be online
- DNSSEC is not used to authenticated updates, TSIG authentication is used
- All updated records are signed by the zone key
- Simplifies DNSSEC validation
	- Only a zone key can sign records
Summary:
		   Simple Update	DNSSEC Update
		   -------------    	-------------
authentication:	   tsig(fast)		dnssec(slow)
policy: 	   server specified	encoded in key signatory field
policy extensions: unlimited		limited by number of signatory bits
DNSSEC		   zone key online	mode a/b
		   all data signed 
		   by zone key
DNSSEC required	   no			yes
Iplementations	   BIND 8.x (soon)	none
Discussion:
- Simple update would be useful, can work with not against DNSSEC updates
- There may be security implications uncomfortable with keys sitting online
	- An applicability statement may be useful
	- Access control is a key policy consideration that needs to be 
	  addressed
		- admissability of updates may need to be defined
	- Are update2 policies the right policies to standarize on?
		- May want to put policy into the DNS to facilitate zone 
		  transfers across different server implementations
			- Multi-master DNS servers might be difficult 
			  without it
		- Would need to define policy in standard way, what is 
		  scope of that policy?
- Concerns about scalability, in particular key propagation
	- Using tkey may help

DNS Lookup (A6)
Draft currently waiting in the IESG queue due to dependencies (edns0).
Comment: An applicability statement for operations would be useful
Extra informational document will be forthcoming
IPNG-WG has will get the input it has requested

Test TLDs
Description: reserve a few TLDs for name testing and documentation
- IANA, when asked, had no objections with the four names in the draft
- Current draft has no assertion that they will be in the root, however 
  this has been discussed
Question: significant support for the draft?
Action: move the draft forward

Local Name
Description: domain name equivalent of RFC 1918 private address space
Currently handled now via split DNS, implementation dependent
Formalize/standarize the idea.  One way would be creating a new TLD 'local'
Move draft to last call

APL RR
Description:
- network prefix coding (rfc 1101)
- resolvers' sortlist
- secure_zone (no longer supported in BIND)
- documentation of assingment/delegation of CIDR blocks
- multihomed hosts, multi-identity hosts
- routing information
- create new rr type: apl

foo.example		APL	192.168.322.0/21 !192.168.38.0/28
                     	APL 	10.20.30.40/17
_axfr_.sbo.example 	APL 	127.0.0.1/32 172.16.64.0/22

- horizontally ordered, vertically unordered
- number of prefixes limited by RDATA length (> 10000)
- coding space left for extensions, ipv6 addresses, syntax elements
- be careful: this is apl , not acl
- comments to list please
Discussion:
- there are a number of issues with draft that need to be looked at, e.g.,
	- need address type declaration
- not an outrageous idea, but it needs work
Action: draft will be revised