RIPE 49

• content to the Chair of the working group.
• format to webmaster@ripe.net.

DNS-WG Notes.
Scribes: Peter Banik with assistance from Olaf Kolkman.


1st Session. Wednesday 22nd, 2004.
09:00-10:30

Agenda for this session.

* A. Administrivia [5 mins]
* B. IETF Reports
DNSEXT & DNSOP [15 min]
Sam Weiler, Sparta

MARID [10 min]
Ed Lewis, ARIN

draft-ymbk-dns-choices-00.txt
Patrik Faltstrom


CRISP [10 min]
Dave Blacka, Verisign


* C. CORE News [20 min]
Marcus Faure, CORE
* D. State and Future of the RIPE Hostcount [20 min]
Henk Uijterwaal, RIPE NCC & Peter Koch, Univ. of Bielefeld


---------------------------

A. Administrivia

Nobody available for jabber transfer.
Minutes have been approved
Agenda was changed, as reflected in these minutes.

---------------------------

B. IETF Updates

-- Sam Weiler's DNSEXT/DNSOP update.
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-ietf-update.pdf)

Sam Weiler presented an update on the work in the IETF DNSEXT and DNSOP
working group.

Suzanne Woolf: ServerID draft acts as a requirements draft for DNSEXT.
there is operational need for identifying anycast instances. Please
submit requirements to Woolf via the mailing list.


-- MARID Report by Peter Koch.
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-ietf-madrid.pdf)

Peter presented the work done in the MARID group that designs DNS based
mechanism to authorize mailagents to originate mails.

Bill Manning: The slides hint that MARID deployment may drive DNSSEC;
why is DNSSEC applicable as the problem really is in mail agents?

Peter Koch: Spammers are criminals, once MARID technology is deployed, the
DNS is likely to be used to forge identities.

Lesly Daigle: Explained the deployment path.

Olaf Kolkman: Once DNSSEC is deployed, spammers will attack the DNS,
but it will be harder to target. This might drive DNSSEC
deployment.

Patrik Faltstrom: The deployment of DNSSEC implies that there are tools
to verify data.


-- Patrik Faltstrom on: draft-ymbk-dns-choices-00.txt
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-expanding.pdf)

Patrik Faltstrom presented a document, that will become an IAB advisory, which
explains the choices for publishing data in the DNS and requested for
feedback.


Bill Manning: Unknown RR level needs to be dealt with at the application
level.

Patrik Faltstrom: Anything between the wire and the application needs to be
unknown aware. (e.g. Microsoft RPC, Sun Yellow Pages, etc).

Bill Manning: there are a number of studies on the distribution of SW that
implemented RFC3597, what is the distribution?

Patrik Faltstrom: Lots of apps can implement 3597 because the firewalls
already have a hole for TCP/53

-- David Blacka. Crisp report
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-crisp.pdf)

Leslie Daigle: David Blacka is one of the implementors.


---------------------------

C. CORE News
Marcus Faure, CORE
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-core.pdf)

Marcus Faure gave an update on CORE and explained some of the services that CORE
offers.

Jaap Akkerhuis questions the usefulness of Core's service: You have
80 members, but in the NL there are 1800 registries; with this
number of providers why would the customer choose an additional
level of indirection instead of going to providers directly?

Marcus Faure: This is something that our membership thinks is useful.

During the 2nd part of the presentation on Whois DB information
accuracy:

Stephen Dyer: Phishing may get easier, as a yearly mail is sent out
and can be used

Stephen Dyer: People usually change address 1 every 8 years, 1 out of about 12
will half of the messages will not be accurate every year. At this
moment 50% of the addresses will not work.

Marcus Faure: This is ICANN policy, and will need to be done. The problem is
acknowledged

Bill Manning comments on the format of the mail: text may be best as he
disregards anything other than text/plain.

---------------------------



D. State and Future of the RIPE Hostcount/
Henk Uijterwaal, RIPE NCC.
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-hostcount.pdf)

Henk Uijterwaal explains the RIPE NCC hostcount and request for feedback on
the activity.



A case for continued DNS Data collection
Peter Koch, Bielefeld University.

(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-datacol.pdf)


Peter Koch makes the case for continuing the hostcount he argued that the
data remains interesting for other reasons than just counting
hosts. He stresses that the RIPE hostcount has trust and goodwill
which is an important asset for getting access to this useful data.

Andrei Robachevsky: You opened a different approach to hostcount.
What do we want to know about the size of the Internet? What is more
important, absolute numbers of trends? Unless you want to do data
mining of dns data, we don't need full datasets, otherwise you end
up creating snapshots of the DNS.

Peter Koch: The Data collection is interesting from a historical perspective
and one may find out methods to look at the data that are not
possible if statistical samples have been collected.

What are the requirements on building DNS samples. Chair request for
volunteers.

ACTION ITEM 49.1: Requirements for the DNS samples and statistics to
be collected.


2nd and 3rd Session. Thursday 23nd, 2004. -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
09:00-10:30 and 11:00-12:30

Agenda for this session

* E. RIPE NCC report on K root operations deployment [10 min]
Andrei Robachevsky, RIPE NCC


* F. Status update on anycasting of I root server [10 min]
Johan Ihren, Autonomica
* G. RIPE DISI project
Olaf Kolkman, RIPE NCC
* H. BIND News [20 min]
Joao Damas, ISC
* I. MODA News [10 min]
Jim Reid, DNS-MODA
* J. Open Action Items [20 min]

See http://www.ripe.net/wg/dns/action-list.html
48.1
48.2
48.3
48.4


(start of 2nd Tursday session)
* K. DNS recommendations and procedure during IP migrations.
Fernando Garcia, Eurocommercial

* L. SiteFinder report from SECSAC [20 min]
Jaap Akkerhuis, SIDN


---------------------------

Administrivia.

Agenda changes (Olaf inserted, Jaap moved)

Update from Peter Koch on MARID: The MARID working group is suggested
to be shut down, the WG is probably not able to meet the goals in due time.

---------------------------

E. RIPE NCC report on K root operation deployment
Andrei Robachevsky, RIPE NCC
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-kroot.pdf)

Andrei Robachevsky provides an overview of the operational history and current
operational status and future plans of the K root-server.

Jim Reid: Will instances of the servers be deployed in
N. America. N.America is over-provisioned. Why move there.

Andrei Robachevsky: In a DDOS attack scenario having nodes globally
distributed will help to protect the regions not under attack.

Jim Reid: But why is the RIPE NCC sponsoring these activities?

Andrei Robachevsky: DDOS attacks are against individual nodes so it is in the
interest of the RIPE region as well to have better resilience
globally.


---------------------------

F. I-Root update
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-iroot.pdf)

Johan Ihren provides an overview of the anycast deployment of the I
root-server. And explains that a change in the funding model may
change the total number of servers to be deployed to increase. He also
explains that the peering model I-root uses is different from the
"global/local" model that F and K-root use.



Jim Reid: Reid remembers that the requirements for sites that are
interested in hosting a site would be made available.

Johan Ihren: This has not been done, and the requirements are subject to
change e.g. because of the change in the financial model and the
increase of the number of sites that provides operational
resiliency. We now accept financial contributions. The goal is to
be less dependent on any single site. Right now we have 17
instances, next year we'll have 25.


Peter Koch: Are there technical limitations on the upper bound on the number
of anycast sites for a given instance.

Johan Ihren: There are no technical reasons. Although more sites may lead to
operational problems with e.g route flapping. There are anycast
projects that target at 100s of anycast deployments. Otherwise
only financial/political reasons that determine this.

---------------------------

G. DISI update
Olaf Kolkman, RIPE NCC
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-disi.pdf)

Olaf Kolkman presented an update on the DISI project which focuses on
deployment of DNSSEC on the reverse tree.

No Questions.

---------------------------

H. BIND news

Joao Damas provides an overview on F-root anycast deployment, explains
the DNS OARC effort and its status and gives a update on the BIND
Forum.

BIND9.3.0 has been released yesterday.


Bill Manning: When is 9.3.1 coming out.

Damas: 9.3.1. will come out when the code 9.3.0 has some exposure.


Peter Koch: 9.2.4 also came out. Can you give us a rough migration path?


Joao Damas: WE call 9.2.x as end of life tree. 9.2.x and 9.3.x do share
code, but people have strange feelings against "version 0" releases.
We're going to keep fixing bugs in 9.2.x.



Jaap Akkerhuis: BIND8 is end of life, but it is still around? When will
BIND8 bug fixes be stopped.

Joao Damas: There are many arguments to move from BIND8 to BIND9, but BIND8
has some non-RFC behavior but people base their operations
on. Besides there are some myths on BIND9's performance (Joao went
into some detail on query loads for TLDs). BIND9 is faster than
BIND8 in the majority of the situations.


Jim Reid: Will Bind9.3 have threaded support so that zone loading and
serving can be done simultaneously.


Joao Damas: Because of the security focus during development the thread
locking was done very carefully that causes the system with thread
support to be slower. This is a work in progress, the problem is not
trivial to solve.


Andre Koopal (via IRC/Jabber) how about bind 9 performance for ISP
servers with lot's of small zones

Joao Damas: This only comes into play when a lot of threads are running
simultaneously. We have to duplicate the conditions the user is
operating under in our lab.


Roy Arends: RAICES project, what is ISC's and LacNICs role in this?

Joao Damas: LacNIC colaborates with ISC on deployment of F-Roots in the
LacNIC region. The Brazil and Mexico nodes are not part of this
project.

Roy Arends: congratulates because it's good to see these local efforts
going on in South America


---------------------------

I. Moda (Jim Reid)


Jim Reid gave an update on the MODA effort and presented a revised Fee
structure.

No questions

---------------------------

J. Open Actions


48.1 Peter Koch

Collect experiences with lameness problems due to vanished
customers/AXFR sources. Initiate document on (best) current practice
and "wishlist" for support by TLD and IN-ADDR.ARPA registries.

Peter Koch: I've done some research contacting ISPs and got feedback, sent
to mailing list. There'll be a draft by the next meeting. Work in
progress.


48.2 Mans Nilsson

Write proposal to support integrity checked/source authenticated DNS
zone transfers to ns.ripe.net in case it is secondary for an
IN-ADDR.ARPA zone. Take into account key generation an distribution as
well as integration with the current automated system..

Peter Koch: Work started, but more time is needed. Work in progress.
Something will be presented at the next meeting or on the mailing
list beforehand.


48.3 Olaf Kolkman

Send to the mailing list (a pointer to) the current list of checks
applied to IN-ADDR.ARPA zones before reverse delegation is activated
or updated. Initiate review of those checks and propose, if necessary,
updates and/or additional tests.


Kolkman: 
* Pointer was posted on the mailing list Sept 9
* We will wait for comments on this posting, if no specific
suggestion for change or addition of tests are received within 6
weeks the action item will be closed. It can be re-opened anytime
if there's need.


48.4 David Malone

Write up a draft RIPE document summarizing the observations made
regarding AAAA resolution problems. Circulate to the list, initiate
discussion what to do, i.e. whom to approach with the list of
errors/problems seen.

David Malone presented an update.
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-aaaa.pdf)


Arends: How did you identify implementations?

Malone: Used FPD to identify servers, happy to get to know the author.

Peter Koch points the audience to http://www.ripe.net/wg/dns and urges
people to look at this material. It contains among other things the
up-to-data action list.


---------------------------
(2nd Thursday session)


K. DNS recommendations and procedure during IP migrations.
Fernando Garcia, Eurocommercial
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-migration.pdf)

Fernando Garcia explained that his documentation will be published in two
documents. One as a guide line for DNS administrators and one as a
policy document. He described the content of the first document. And
invites discussion on the topics of: + Duplicate DNS servers vs Single
DNS server with dual IP address + The need for a "traumatic" procedure

Proposal on a "design team" to shape the document.

Jim Reid: Sense from the room that this is good work and should become
a RIPE document. The document is 30 pages long -- perhaps too long
for some people to read.


Peter Koch: There is a side note in the doc: there is a feature called
instant registration (proposed by one registry), I'd suggest we have
a closer look on this. What is the real effect of those TTL? Can
we lower it indefinitely or is there a 'bottom line'?


Jim Reid: Suggest to split the document in a "cookbook" and a document to
discuss the "policy" on e.g. on ones policy with respect to TTLs and
delegations.

Patrik Faltstrom: The document should start with the steps and then
explain. So one can check off ones actions. What is missing is
analysis of what to do with respect to zone transfers and TSIG
keying.


ACTION ITEM 49.2 Action on Chair: Coordinate the production of a RIPE Document
based on Fernando Garcia's DNS Server Migration document. (Volunteer
team: Geoff Sisson, Patrik Faltstrom, Bruce , Daniel Diaz, Joao Damas
and ,Jarle Greipsland, Jim Reid)

---------------------------

L. Secsac Report on wildcard in the root.
Jaap Akkerhuis, NLnet Labs.
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-wildcard.pdf)

Jaap Akkerhuis presents an annotated version of an earlier
presentation by Steve Crocker on the Security Advisory Committee.

Jaap Akkerhuis recommends to turn off BIND's delegations only hack.
Insprired by the IPv6 deployement lot of TLD's are changing the names
of their nameserver to optimize the name compression. These new names
are often not delegated causing lookups to be blocked by this hack.


Jim Reid: Is all technical detail on the "delegation hack only"
consequences documented or is this task for the working group?

ACTION ITEM 49.3 on Akkerhuis: Do some research on the problems that
the BIND delegation hack causes and document these.


---------------------------

M. Nameserver Statistics
Bruce Campbell, RIPE NCC
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-stats.pdf)

Bruce Campell explained why, how and what statics have been collected
from the RIPE NCC operated nameservers.


Gert Doering (in relation to peaks in the IPv6 reverse query load graphs):
It might be that one sees peeks in the query load for reverse IP6
while the reverse is not yet been setup.

Peter Koch: Did you check what was answered during the "peaks" NXDOMAIN or
referrals?

Bruce Campbell: The responses where not matched to the queries.

Peter Koch: Did you check if the "john.doe.hotmail.com A" queries had the
recursive bit on i.e. do people use ns.ripe.net as a recursive
server? You could tailor the answer.

Peter Koch: You could also record the answers for further detailed analysis.


---------------------------


N. DNS Performance Monitoring
Carsten Strotmann, Men and Mice
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-dnspm.pdf)

Carsten Strotmann presents the "Men and Mice" company, their products and its
architecture and gave a demo of their DNS performance monitoring
product.


Jaap Akkerhuis: Is there data on serverIDs? Do you sniff UDP and TCP?

Carsten Srotmann: Only UDP/53 right now. The system framework can do TCP as
well though, it was not asked for yet.


Jim Reid: what about EDNS0

Carsten Strotmann: EDNS0 is probably not analysed but is on our roadmap for
the end of this year.

Jaap Akkerhuis: It would be usefull to analyse EDNS0 support vs IPv6
support. Same goes with TCP vs IPv6 support.


Sam Weiler: Do you provide real time monitoring?

Carsten Strotmann: There about half a minute delay. The system has an alarm
functionality that provides SMTP traps and puts warnings in the
report



---------------------------

AOB.

A decision has not yet been made about the addition of another
co-chair but communication with the volunteers has taken place, so
the wg will be presented a suggestion by end of October.


Joint DNS-IPv6 meeting may be a good idea as there is some
overlap. The room has no outspoken opinion.

Meulenkamp advertises the DNSSEC training
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-dns-dnssec-course.pdf)

Thanks to the speakers, the RIPE NCC for providing infrastructure and
scribes.










49.1: Requirements for the DNS samples and statistics to be
collected. (ref agenda item D).


49.2 Action on Chair: Coordinate the production of a RIPE Document
based on Fernando Garcia's DNS Server Migration document. Investigate
impact of TTL on NS RRs in TLD (delegation) zones, work towards
recommendations document.
(Volunteer team: Geoff Sisson, Patrik Faltstrom, Bruce , Daniel Diaz,
Joao Damas, Jarle Greipsland and Jim Reid) (ref agenda item L)


49.3 Action on Akkerhuis: Do some research on the problems that the
BIND delegation hack causes and document these


.

Action item 48.3 to be closed in 6 weeks, other RIPE 48 action items remain
open.