Minutes from RIPE 39
| RIPE Meeting: 39 |
|
| Working Group: DNS |
|
| Status: |
Final |
| Revision Number: |
1 |
Minutes from the DNS working group at ripe-39 in Bologna, Italy
1 reports
IETF
SW
Others
2 Documents
3 Issue areas
IDN - Patrick Falstrom
IPv6
DNSsec
root-servers operational testing - Bill Manning
4 Security/Abuse
5 I/O other working groups
6 Suggestion Prague RIPE 40
7 AOB
- ------------------------------------------------------------------------
1 Reports
- ------------------------------
1.1. IETF report skipped.
2.2 Software
Jim Reid (Nominum)
BIND issues
bind 8:
- Two more versions.
- 8.2.4 release in a month or so.
- 8.3 release will be the last release it will contain IPv6 resolver.
- Paul Vixie, best effort bind 8 development.
Bind 9:
- bind 9 9.1.2 in the next 2 month
- 9.2 release later in the summer: July/august
more conf file options.
new control protocol.
better performance... closer to bind 8.
better cache management: size control of cache.
bind8 resolver library with ipv6 support
man pages rewrite.
- 9.3 at the end of the year.
Performance improvement
More tools
Support for IDN (depends on IETF actions)
More IPv6
Nominum contract from ISC ends with release of 9.3. (end of the year) unless
new developments take place and funding is arranged.
Question
How will IDN be supported?
Answer:
Implementation once IETF converged.
- ------------------------------------------------------------------------
2 Documents.
- ------------------------------
Peter Koch on the 'long document':
- Please read and review the document and
provide input.
- Final draft at RIPE 40.
- ----------------------------------------
- ------------------------------------------------------------------------
3. Issues Area.
- ------------------------------
3.1 IDN status. Patrick Falstrom
a. General problem
The DNS is a DB with a limited lookup mechanism it also is a protocol
definition.
b. labels and identifiers
Technically DNS is based on identifiers, but people want to register
words and phrases, preferably in their own language.
The labels need to be translated into identifiers, this could be solved
by putting a directory service on top of DNS designed in the application
area.
c. character sets
Until dir. service has been implemented Identifiers have to be in
in a defined character set.
DNS need to be able to recognise and convert and between character sets.
Applications need to know about this.
Even though 8 bit are handled by the DNS, the applications have problems.
Can one come up with a solution that is backwards compatible so
applications do not need to be fixed.
Problem with domain names that may be equal but maybe are not. Some
examples were given. e.g.
Swedish lakes: A.com or a physical unit
A.com (lake - angstrom).
d. IDNA proposal
Make up a algorithm that defines what is equal in unicode.
The algorithm used is the algorithm from unicode consortium.
If labels look the same but are not the same in the definition of the
unicode consortium (nameprep) then registrant should register those names.
User interface (local language) <->
Application (Conversion to unicode, nameprep algorithm, ACE) <->
DNS
e. Nameprep basics
Mapping of characters -> Normalisation character
-> prohibition of code points
1 - Mapping of chars. (map all upper to lower, additional
folding for 'special cases'. mapped out, 'deleted').
2 - Normalising characters. KC in UTR15 a' will be translated
to a with dieresis.
3 - Prohibition of code point:
- There are lot of domain names that are not allowed to be
part of a domain name (space, eol, private use space chars,
replacement chars).
- Display property marks.
- Inappropriate for some input systems (o). (small ring,
circular dot).
f. Patent issues.
A company name Walid have a patent filed that refers to a IETF draft.
The patent includes various things that IDNA talked about.
Wahid require licensing. US PAtent 6,182,148 B1
g. IETF process.
- IETF has nothing that prohibits an RFC to require licensing.
- For Draft standard: two implementations needed but two different
licences.
- IDN wg does not have a consensus because IDNA licensing is needed.
- Work in WG has stalled because of this.
- It is not clear the patent is not covering IDNA.
- The WG is stuck....
If IDNA does not make it UTf8 is neede but then protocols (SNMP,
x.509, etc etc) need to be changed.
3.2 IPv6
Dupont: Case for A6 DNAME needs to be build. If these arguments are so
good that we go forward.
Reid: Bind 9.2 server will do the DNAME chains...
QST: is the move to ipv6 from int to arpa related related bitstring
decision.
Answer: A6 vs AAAA is different from bitstring. There is no recommendation yet
on nibble to bitstring. The move from int to arpa is unrelated.
There was some discussion on approaches to make the clients to find
resolvers for A6 RRs. This is a complex problem, discussion started at
the Minneapolis IETF
3.3 DNSSEC
Kolkman:
Reported on the DISI project, the DISI BOF the formation of
(incooperation in) a Security working group.
The RIPE NCC has started a project to deploy DNSSEC over the reverse
tree and is cooperating with NLnet Labs and other groups to gain
expertise and iron out operational details.
General comment from Johan Ihren on IPv6/DNSSEC: is getting more
complicated. New tools are needed!!! bitstrings cannot be edited with
vi or emacs. Tools can help but bitstream needs to be implemented
from the root down.
Comment from audience: Root-server: Referring to any-cast:
organizational problems who to call...
Rudiger: Expressed his worries about alternatives root.
3.4 Root-Servers
Bill Manning:
Operational Testing of new DNS and RR types.
"No user serviceable parts inside"
About Testing proposed standard track.
A funded project to determine operation impact of new DNS features wrt
DNS Apex.
Works with and reports through RSSAC.
Standard Track Protocols
Community demand: v6 forum, DNSSEC groups, IDN issues.
Lab environment tests are done but they do not persistent and are of
small size; larger scale experiments are needed.
This is attained by using in the same database (ICANN ROOT) to test
technical setup.
Develop viability reports to ICANN: operational impact of standard
track protocols.
Future activities:
- Regression testing
- Fingerprinting
- Operational testing of ANycast
- Test EDNS
Defining environmental impact statements before live work commences.
slides at
www.isi.edu/~bmanning/OTDR.html
- ------------------------------------------------------------------------
4 Security and Abuse.
- ------------------------------
Manning: Use of TSIG requires NTP. There was a recent NTP exploit; fix
your NTP!
- ------------------------------------------------------------------------
5 Other working groups
- ------------------------------
NO I/O for other working groups...
- ------------------------------------------------------------------------
6. Suggestion for prague RIPE 40
- ------------------------------
Akkerhuis: Suggests a little more PR; Publish agenda well before the
- ------------------------------
Manning: Use of TSIG requires NTP. There was a recent NTP exploit; fix
your NTP!
- ------------------------------------------------------------------------
5 Other working groups
- ------------------------------
NO I/O for other working groups...
- ------------------------------------------------------------------------
6. Suggestion for prague RIPE 40
- ------------------------------
Akkerhuis: Suggests a little more PR; Publish agenda well before the
meeting.
People might not get a justification for attending when there is no
Agenda available.
- ------------------------------------------------------------------------
7. AOB
- ------------------------------
None.
|
|
 |
| RELATED TOPICS |
|
|
|
|
