minutes for RIPE36 meeting

Dear working group members,

I apologize for sitting a bit too long on Vesna's draft minutes for the
Budapest session.  Vesna did a really good job;  please find the draft
below.
I'll wait for comments until Sept. 30th. So the draft is expected to become
final on October 1st.

I'm sorry that some problems in my day job escalated yesterday evening in
ways so that today in the early morning it turned out that there would be
no way to make the planned trip to Amsterdam safely and in time.
(There is a down side to having the conference locally - or "within short
driving distance":-(

I hope those attending the current meeting do have a good time;
looking forward to see you again at future meetings.

Regards,
  Ruediger


Ruediger Volk

Deutsche Telekom AG -- Internet Backbone Engineering

E-Mail:  rv at NIC.DTAG.DE
Phone:   +49 251 7985 200	fax:  +49 251 7985 109


DNS Working Group
RIPE #36, Budapest
18 May 2000

Chair: Rudiger Volk
Scribe: Vesna Manojlovic

Agenda:

0. Agenda bashing
1. David Conrad, ISC: BIND 9
2. Bill Manning: Preparing for DNS evolution
-=-
coffee break
-=-
3. Report from CENTR DNSSEC workshop
4. IETF - Randy Bush
5. AOB
  5.1. Fernando - Document about re-delegation
  5.2. RIPE documents published since the previous meeting


1. David Conrad gave quick update of current status of BIND

	BIND9
	* complete rewrite of code
	* includes support for everything
	- full IPv6 support
	- DNSSEC support
	- not supporting EDNS1
	- multi-lingual support
	- MS interoperablity 
	* RFC compliant (first time, cheers from the audience :)
	- first time it has lots of documentation :)
	* 1.2 mil $ to develop
	* release - 30.6.
	* availability now - beta

	David was asking the audience for help :
	- to support INN (BIND and DHCP are supported by Nominum)
	- from people with NT experience to debug NT port of BIND 8.2.3
	- to test BIND9 
		- performance
		- IPv6 support in BIND 9
		- DNSSEC

2. Bill Manning -- Wither DNS?

	PPT presentation available on 
	http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/ 

	Current assumptions:
	- constant MTU
	- ASCII
	- BIND (UNIX based)
	- single authority (server)
		- hierarchy
		- zone management
	- static behaviour (client)
	- merged server and resolver
	- reachability: reliable network (up, end-to-end)

	On the horizon:
	DNSsec
	IPv6
	dynamic DNS
	integration with other applications - database back-end
	(LDAP,Oracle,mail) I18N (internationalisation)

	DNS version diffusion survey Q&A session:

	Q: how is this taken?
	A: exhaustive search of inaddr tree.

	Q: is it biased?
	A (audience): it is security biased! they are not responding if
	they are security conscious => shows higher % of vulnerable

	Q: how big is the percentage of the servers that are blocked by
	firewall and therefore not included?
	A: few years ago - 20%. recently - 25%

	Conclusion: people are moving into new code but not (as) fast (as ... )

Discussion about IPv6 inverse tree

	Randy Bush: Is IPv6 inaddr tree going to be set-up separately? 
	(rfc 2826)

	Bill: That is the suggestion (to use separate set of root nameservers)

	Randy: That would cause technical and other problems. Other
	possibility is to take one of existing root servers.

-= coffee break =-

3. Report from DNSSEC workshop 

	Workshop was initiated by CENTR, held in NLnet labs in Amsterdam.

	One report was already done by Jaap Akkerhuis in CENTR DNR-wg;
	technical report - here.

	The goal was to check resources needed for introducing DNSSEC on the
	level of TLD zones.

	Result of the previous previous attempts was: it is still hard
	work, not feasible at this time. This new workshop gave different
	results.

	In Europe, .de tld zone is chosen as the worst case. Experiment
	was done with off-the-shelf PC, with extra large memory.

	"Signer" software was provided by Nominum. 

	Two test runs were done:

	1. on original data 
	signing -- ~ 14 hours CPU time
	expansion factor of 4.4 (of adding all the dnssec data)

	2. modified zone 
	(taken out mx & A records; left just ns)
	runtime -- 3.2 hours of CPU time
	117 mb -> 380 mb, so expansion factor a bit lower (3.2) for
	smaller base data

	Conclusion:  you need some resources, but it's within the reach of
	current hw and sw.
	the few people with much larger zones will have more work -
	but it can be assumed they'll have more revenues.

	Q: Does it mean a recommendation to DEnic to get rid of mx only
	domains?
	A: yes

	Q: Compared  with Swedish workshops?

	Liman: different, smaller results. Bigger times & data. Used
	signer from bind8.

	Q: What do you consider normal zones? 
	A: Less then a million records. (.de = 3,000,000 RR)

	Liman: Does it make a difference if you have to include ns or mx/a
	records? 
	David: Not significant.

	David: Wildcards in the sign zone makes signing 2 orders of
	magnitude more difficult. We don't support them!
	Liman: Only in DNSSEC?  
	David: Yes, only if you try to sign them; we either ignore them or
	generate an error. 

4. Randy Bush: DNS from IETF perspective

	What features are important? 

	For a log time, specifications were stable, code was fairly
	unstable. Now we are in period when specifications are fairly
	stable, and the code is little unstable.

	The increased features that are being specified will cause code
	instability that will last forever (you can't have all this sugar
	and not be unhealthy).

	Main new features: security / DNSSEC & multi-lingual support / IPv6

	Security problem:

	For example: the size of the root zone sign becomes larger then
	bits in the MTU of the standard UDP packet and therefore all the
	sessions will fall back to TCP and cause 6 times bigger amount of
	traffic.

	Multi-lingual problem: 

	It's not really the DNS problem, but application problem - what is
	my web browser going to be able to read. i like to call it not
	internationalisation but localisation, which can cause that our	
	customers not able to do e-commerce with Japanese customers

	David: stability of the code: bind9 _designed_ and not _evolved_ ;
	therefore more stable. architectured much better.

	Bill: operational community has to find the way to provide the
	feedback to engineering community. this forum might be a right
	place for it.

	Randy: yes - we need operators back in ietf. protocols became
	designed without taking a consideration operational issues.

	David(?): ietf is quite large cumbersome. having smaller groups of
	operational people come to some consensus, and then having
	spokesperson is probably a better solution.

	Chair: in communities like this there is opportunity to keep
	information flow in both directions.

	The survey was conducted by Bill to check who is using which
	version of BIND. 
	Results: [ ]

5.1. Document about re-delegation

	Draft paper on how to help re-delegation was presented in RIPE #33
	in Vienna by Fernando [ ].

	Paper was describing the case of DNS transfer of customers from
	one ISP to another - how that can be done without losing the
	service, how to minimise problems, including variations of cases
	of (non)cooperating ISPs.

	Help is needed about transfer procedures in ccTLD zones other then
	.es .

	Question from the audience: Wouldn't CENTR think they should take
	 part in it? Since large amount of these re-delegations problems
	are from ccTLD registrars.

	Chair: Indication of involvement should come from CENTR. However,
	administrative procedures in many registrars are much worse then
	they should be; we should push CENTR in the right direction.

	Liman: There should be one document describing technical issues
	(in which order what.. ), which are the same all over the world;
	then, what are the implications of administrative models; and in
	the different part of the same document, point to possible
	pitfalls.

	ACTION on Fernando to sent index/draft to the DNS-WG mailing list;
	make appendix about procedures in the registries/registrars that
	we know about.


5.2. RIPE documents published since the previous meeting

	- Recommendations for DNS SOA Values (RIPE-203)

	- Simple DNS Configuration Example (RIPE-192)

	There is work in progress on more detailed documentation. Peter
	Koch was encouraged to work more on it.

	Chair invited everyone to express their need for new documents.

	Q: There is confusion about old and new minimum value in bind4
	and bind8.

	Liman: Dummy guide is meant for "the newest version of BIND".
	Comments about other versions are welcome, but should be published
	as separate document.





--==_Exmh_9077542070--