Minutes from RIPE 32

DNS Working Group Minutes

RIPE 32
Jan 28th, 1998

Grand Hotel Krasnapolsky, Amsterdam, The Netherlands

Chair:     Rudiger Volk
Scribe:    Lee Wilmot
Attendees: 64 [?]

AGENDA

1) Document Roadmap
2) SOA timer values document
3) General BCP recommendations document
4) Dummies guide.
5) RIPE NCC:
     - inaddr.arpa. statistics update
     - deployment
6) Recent error observations (Peter Koch)
7) DNSSEC
8) Y2K
9) AOB

1) DOCUMENT ROADMAP

The Chair explained the current status of the BCP and Guide-type
documents which have been progressing over the last few meetings.

Currently three visualised, each to be discussed individually on
the agenda.

2) SOA TIMER VALUES DOCUMENT

Peter Koch presented a proposal, title

'Yet Another DNS Recommendations Document'.

Broke up SOA record fields according to party of interest to
show clearly who would be affected by the recommended values.

Peter proposed fixed values for times. Argued that suggesting ranges
was a bad idea, combinations of various values may not be checked and
be damaging.

RNAMES
RFC 2142 mentioned: a proposed standard for RNAMEs.
Some points brought up in meeting
     1) don't accept suggested defaults from software
     2) *do* use role accounts where possible

SERIAL
Some possibilities: YYYYMMDDnn, seconds or N
YYYYMMDDnn is a useful policy. But be aware of potential problem:
if automatic software is introduced, it would most likely just
increase this by one upon every update, thus providing a misleading
interpretation of the SOA value for third parties.

Problems were mentioned with the method sometimes used of dividing
seconds of day by 15 for nn.

REFRESH
86400
Objection expressed to higher refresh: not everyone running Bind 8.
Value accepted with this caveat.

RETRY
7200
Should be lower. Not always case. Peter suggests 1/4 of REFRESH as rule of 
thumb.

EXPIRE
3600000
Want to avoid having values around 5-7 days. Too short in the case of an
admin taking a long weekend for example.

Objection from group: with such a long expire, problem won't be noticed for a
long time.
Peter responds: really such problems should be picked up from the log files
in any case, not from expiring zones.

MINIMUM TTL
172800/3600 (ttl/neg)
3 possible meanings developed over time. Peter has seen problems
with this. See BCP document for more detail.


Chair: OK to proceed with document formatting etc ?
Group: general assent.


3) GENERAL BCP RECOMMENDATIONS DOCUMENTS

Author Peter Koch.
Draft was circulated to the RIPE DNS WG list 5 days before the meeting.

Peter said a few words on the document, working from memory.
Target: low populated zones ( 1-10 hosts )
See document itself for more info.

Comment from group: shouldn't advice on how to proceed with changes
to a zone setup be included ?

Chair: words to the effect that this was not in the scope of the
document. Too many variations in things that might need to be changed.

4) RECENT ERRORS/ QUALITY REPORT

Peter Koch mentioned a couple of things he had been seeing
recently in the de hostcount files.

- bad NX foo.xx. MX 42 193.4.5.6.

- address as data part of NS record (this to be mentioned in BCP doc)

- turning on WINS (NT) results in proprietary (none-standard) record types
in zone. Secondaries running BIND will choke when transferring zone
(unknown record type).
Liman suggests either
- all secondaries run WINS
- or ... [Scribe: didn't catch this]

-  secure_zone
( BIND versions ( 8 )
secure_zone results in NS only handing out data to queryers matching
prefix/mask or whatever specified in data section.

Peter has seen

secure_zone foo TXT "127.0.0.0:H"

showing up sometimes in customer zones. Created by some firewall admin tool.

- someone in group mentioned some Mac server software restricts no NS'S to 1

5) DUMMIES GUIDE

Liman.

Copies were handed round at start of meeting.

Target ISP customers domain admins.

Intention: Generic doc should use BIND/UNIX as explanations
base. Intended follow up derivative documents for different platforms.

Idea is to be very brief. No explanations why. Go elswehere for
explanation. 2-3 pages. Basic setup, no twists/variations.

Suggestions from group: make all examples consistent throughout
the document to allow global search-replace

Liman: summary: *almost* done, one more turn on the list to go with
latest changes.

Action on Liman: to do this.

6) INADDR STATS

Paula Caslav, RIPE NCC presented some summary stats taken from the
RIPE NCC web pages.

Question from group: are there any numbers about the proportion
of the assigned address space which is reversed ?

Lee Wilmot: no. Around 320000 reverse zones for the RIPE NCC address
allocations potentially exist, at the current time 80500
/24's are reversed. Don't know how many of the potential
/24's actually are in use. Will look into this for Vienna
meeting in may.

Peter: should / should not reverse delegation be set up
in any case ?

People were slightly surprised by this question.

Group: not providing this means a reduced service set which
means it *must* be done.

Group: It's a two-way problem, not just reduced service set
for the end user. All sorts of servers all over the
Internet are slowed up when an end-user does not have
his addresses reversed (and reversed correctly).

Group suggestion: if ns.ripe.net at the RIPE NCC is receiving
queries for none-delegated domains, some action should be
taken, for example, informing the ISP/LIR.

Group: we'd like to know the extent of this problem.

Action on RIPE NCC: analyse nameserver stats for ns.ripe.net,
especially for NXDOMAIN on reverse lookups.

Group suggestion: why not remind ISP/LIR to get reverse delegation
set up correctly when any address space assigned - address space
assignment documents should be ammended maybe.

Group suggestion: how about getting a contractual statement that
reverse delegation will be set up (and correctly) upon receiving
the address space ?

Group felt that this was too strong.

Summary: group felt that *strongly encouraging* setting up of the
reverse delegation was definitely a must

Action on RIPE NCC: check the current assignment documents for this
and with a view to making the necessary ammendments.

7) SOFTWARE VERSIONS USED

Peter Koch spoke briefly.
He had used the NS records from the de hostcount to check
for NS versions.

Some BIND versions return version number when given a TXT query of a
particular type. Discovery: lot's of people still running old
software. No figures were given.

BIND 8.2 was mentioned, currently alpha. DNSSEC expected to be fully
implemented in this version.

RFC 2308: change of meaning of minimum TTL field in SOA record.
Peter sees problems.

Chair: people active in discussion should investigate further and
report back to the WG.

8) DNSSEC

Chair: DNSSEC moving along, software becoming available. Should this
group make any preparations ?

Liman: need for...
- guidelines/clear documents
- software tools for signatures
- guidelines for certificates
- plan for deployment
- justification to end-users.

Chair proposed ...
Action on Liman to collate a list and inform the WG before next meeting
at Vienna in May.

9) AOB

Peter Koch was asked about making available the post-processing scripts
he uses on the de hostcount.

Peter said that in the first instance he would hand these over to RIPE NCC
as first step, but all were welcome to get involved.

10) Y2K

The general feeling seemed to be that this would not be a major problem.

Some people expressed concerns about older versions of BIND and other
implementations. Probably the most can be said is that the protocol
has no problems ?

An overflow problem with serial numbers in format (SOA record) YYYYMMDDnnn 
was
mentioned.

Chair: it would be good form for LIRs/ISPs to notify customers of
potential problems of this kind.

CLOSE

------------
RESULTING ACTION POINTS

DNS 32.1 Liman. Circulate ammendments to 'dummies guide', for final
approval.

DNS 32.2 Peter Koch. Continue on BCP doc, circulate.

DNS 32.3 RIPE NCC, Lee Wilmot. Analyse query stats for ns.ripe.net,
especially for none existent targets of reverse lookups.

DNS 32.4 RIPE NCC, Paula Caslav. Check the current address space
assignment documents for wording post-assignment reverse delegation
with a view to making the necessary ammendments to strongly encourage
reverse delegation setup after address assignment.

DNS 32.5 Liman: collate list of DNSSEC issues, inform WG mailing list
before Vienna meeting in May.
-------------