[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
dnsind minutes (first pass)
[ 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 <ogud@tis.com> 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