[Apologies for duplicates]
Dear Colleagues,
On 9 November 2006, authoritative Reverse DNS Services on ns.ripe.net
will be unavailable between 10:00 and 11:00 UTC. During this time we
need to carry out important server maintenance work.
We apologise in advance for any inconvenience.
If you have any questions or concerns about this, please send an e-mail
to dns(a)ripe.net.
Regards,
--
Brett Carr Ripe Network Coordination Centre
Manager -- DNS Services Group Singel 258 Amsterdam NL
GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8
Hi,
is there any reason for ns.ripe.net missing NS records of /24 reverse
zones out of /16 reverse zones?
Anyway we've a problem resolving ip addresses out of a couple of /16
reverse zones when asking ns.ripe.net as one of the secondaries for such
a zone.
Any thoughts or hints?
Thanks,
Christian
Hi Dmitry!
Yeah, I see the big difference and using double-standards about two
domains SU/EU are both not in ISO list :(
But hope we can help to move it right way ;)
Dmitriy V Menzulskiy wrote:
>
> Hi Max ! Hi everybody !
>
> Now I understand: people who want to destroy Soviet Union - they still
> want to destroy it comletely :-(((
>
> Maybe, it's time to start CIS TLD ?
>
> WBR,
>
> Dmitry Menzulskiy
>
> ----- Переслано: Dmitriy V Menzulskiy/BeeLine дата: 02.11.2006 13:39 -----
>
> dns-wg-admin(a)ripe.net написано 02.11.2006 13:30:47:
>
>> On Thu, 2006-11-02 at 11:34 +0300, Max Tulyev wrote:
>> > Doug Barton wrote:
>> > >> This domain grows even it have huge price (
>> > >> http://www.nic.ru/en/index.html ). So people really need it.
>> > >
>> > > A) Wanting something is not the same as needing it.
>> >
>> > The magic is who decides what I need and what I don't need.
>>
>> That you _prefer_ .su doesn't mean that the TLDs it's been split into
>> can't meet your _needs_.
>>
>> preferences != needs
>>
>> >
>> > > B) My feeling is that what you're saying here (substantial
>> > > registration growth in spite of the high price) speaks more to the
>> > > motivations of the SU operators for maintaining their domain than it
>> > > does for the necessity of keeping it in the root.
>> >
>> > Nobody push people to buy .SU domains. Only issue they do it - they need
>> > it. Am I wrong?
>> >
>>
>> Are anybody pushing people to avoid .su? I.e. how much effort are
>> the .su-maintainers putting into convincing people to use the individual
>> ccTLDs instead? ;-)
>>
>>
>>
>> --
>>
>>
>> Per Heldal - http://heldal.eml.cc/
>>
--
WBR,
Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Dear WG,
please find below the draft minutes of last week's two DNS WG sessions.
Thanks to Susannah for being the Jabber Proxy and to Adrian for the
fast delivery of the minutes. All errors are still mine.
There were no new action items generated for the DNS WG last week, but
a couple of old ones made progress or were closed, in some cases pending
mailing list approval. Please expect some 'last calls' soon.
Please review the minutes, especially if you are quoted by name. The
deadline for this first round is October, 30th. Thanks!
-Peter
-----------------------------------------------------------------------------
D R A F T [1] RIPE DNS WG minutes for RIPE 53, Amsterdam
-----------------------------------------------------------------------------
WG: DNS
Meeting: RIPE 53, Istanbul
Date-1: Wednesday, 4 October 2006
Time-1: 16:00 - 17:00 (UTC +0200)
Chair-1: Peter Koch
Minutes-1: Adrian Bedford
Jabber: xmpp:dns@conference.ripe.net
J-Scribe-1: Susannah Gray
J-Script-1: TBD
Audio-1: TBD
WG URL: http://www.ripe.net/ripe/wg/dns/
Material-1: http://www.ripe.net/ripe/meetings/ripe-53/presentations/wednesday.html
Agenda: http://www.ripe.net/ripe/meetings/ripe-53/agendas/dns.html
-----------------------------------------------------------------------------
A. Administrative Matters - Working Group Chairs
<http://www.ripe.net/ripe/meetings/ripe-53/presentations/dns_agenda1.pdf>
Appointment of scribe -- Adrian Bedford (RIPE NCC)
Jabber monitor -- Susannah Gray (RIPE NCC)
Agenda bashing -- no changes
-----------------------------------------------------------------------------
B. Status Reports - Working Group Chairs
IETF, DNSEXT, DNSOP and others
(Olaf Kolkman, NLNet Labs)
<http://www.ripe.net/ripe/meetings/ripe-53/presentations/dns_wg_update.pdf>
Questions:
Ole Jacobsen asked about the team set up to discuss operational aspects
of DNS security. Although the aim of the team was to lead the rapid
deployment of the technology, little has been heard since it inception
almost two years ago.
Olaf replied that the DNSSEC deployment initiative led by Steve Crocker is
essentially a web-based forum. There is a move to involve more people. It
certainly remains a good place to go to find information or help with the
deployment of DNSSEC in any organisation.
In terms of results, Olaf feels there is much going on behind the
scenes. He clarified that there is no formal liaison between the forum
and the IETF.
ICANN/IANA Update
(John Crain, ICANN)
<http://www.ripe.net/ripe/meetings/ripe-53/presentations/icann_dns_wg.pdf>
Questions:
Rob Blokzijl asked why there was a move to retire old ccTLDs.
He could see no technical reason to do this. John agreed that there was
no compelling reason. He added that the question remained about whether
this should be done. Rob pointed out that current guidelines preclude
reuse of ISO3166 country codes for a period of five years. New guidelines
will change this to 50 years. Carsten Schiefner commented that .cs was
reused recently. Previously it was the code for Czechoslovakia; it was
then used for Serbia and Montenegro.
CENTR
(Marcos Sanz, DENIC)
<http://www.ripe.net/ripe/meetings/ripe-53/presentations/centr.pdf>
Questions:
Peter Koch asked if interested operators might be able to present at the
normally closed CENTR meetings. Marco said that active participation in
the meetings was encouraged, provided there was not a confidential matter
under discussion.
-----------------------------------------------------------------------------
C. Action Items Review
(Working Group Chairs)
The action list for the working group was reviewed.
<http://www.ripe.net/ripe/wg/dns/dns-actions.html>
48.1 Peter Koch has written this up in an Internet draft.
<http://www.ietf.org/internet-drafts/draft-koch-dns-unsolicited-queries-00.t…>
[[Ongoing]]
48.2 Mans Nilsson -- TSIG/SIG(0) for ns.ripe.net
[[Ongoing]]
48.4 David Malone -- AAAA misbehavior.
<http://www.ripe.net/ripe/meetings/ripe-53/presentations/aaa.pdf>
Dave Wilson gave a short presentation on the issue on behalf of Dave
Malone. The document has been written and circulated to the list. There
is a question about whether this document would just repeat work done
elsewhere in the Internet Protocol Journal.
After a show of hands, it was decided to mark the item done and regard
the IPJ article as the authoritative source.
[[Done, pending mailing list approval]]
49.1 Peter Koch -- DNS Hostcount successor requirements
Peter is to discuss this with RIPE NCC staff.
[[Ongoing]]
49.2 Jim Reid -- Server Migration Document
A document will go to the review panel after this meeting and be
circulated through the working group mailing list. Hopefully, this
can be marked as completed in time for RIPE 54.
[[Ongoing]]
51.1 RIPE NCC -- K-Root anycast measurement
The publication of the report from the RIPE NCC is nearing publication.
After this happens, the working group will then need to decide whether
to ask the RIPE NCC to look into other types of measurement.
[[Ongoing, draft RIPE document to be last called]]
51.3 Lars-Johan Liman -- NCC Secondary Service Policy
Lars commented that the RIPE NCC has announced it will limit
involvement in provision of slave servers for TLDs. Lars suggested
this be closed for now and marked as overtaken by events.
The working group agreed.
[[Done, pending mailing list approval]]
51.4 Peter Koch -- ripe-203 Update
[[Ongoing]]
Brett Carr gave an update on the various outstanding actions on the RIPE
NCC
<http://www.ripe.net/ripe/meetings/ripe-53/presentations/ncc_dnswg_update.pdf>
52.1 Report into the causes for extra DNSSEC network traffic.
[[Ongoing]]
52.2 Report numbers of signed zones and delegations in reverse tree
Jim suggested this be considered closed, but ask the RIPE NCC to give
regular updates once or twice a year. As a result, this will remain
a standing item on the working group agenda.
[[Done]]
Questions:
Max Tulyev asked why there are so few DNSSEC delegations.
Brett replied that the answer for this would lie with the community.
He agreed with comments from Max that people need to understand the
benefits and that implementation is easy.
52.3 Lame delegation proposal
WG Last call to be issued, chairs to discuss and declare consensus
[[Ongoing]]
52.4 Automate and streamline ENUM delegation process.
[[Done]]
52.5 Carsten Schiefner -- Proposal for regular lameness checks in e164.arpa
Carsten has reported on this in the ENUM working group. They will come
up with a task force to take this work forward and report at RIPE 54.
Carsten suggests that the DNS working group mark this action as closed.
[[Done]]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
Date-2: Thursday, 5 October 2006
Time-2: 11:00 - 12:30 (UTC +0200)
Chair-2: Jim Reid
Minutes-2: Adrian Bedford
J-Scribe-2: Susannah Gray
WG URL: http://www.ripe.net/ripe/wg/dns/
Material-2: http://www.ripe.net/ripe/meetings/ripe-53/presentations/thursday.html
J-Script-2: TBD
Audio-2: TBD
-----------------------------------------------------------------------------
D. Plenary Follow Up
(Working Group Chairs)
There was a discussion around the issues raised by Duane Wessels on
problems with DNS and Steve Gibbard on DNS Infrastructure Distribution.
Jim Reid commented that much of what Duane had said was reasonably valid
and much was already good practice, such separating out authoritative
and caching-only nameservers and issues surrounding lameness. Jim
however did take exception to was the talk of using TCP-based DNS
queries. He pointed out that most DNS clients will make a single DNS
lookup before taking any action. Using TCP for this seemed somewhat
inefficient, considering the small amounts of data that are being
transferred. It would also add to latency. A high latency, low bandwidth
network or one with a busy nameserver might find handling short-lived
TCP connections painful.
Olaf Kolkman mentioned that he had heard that under a DoS attack, an
operator had first sent back a result with a TC-bit leading to a re-test
on TCP, after this the UDP source was white listed. Duane confirmed that
there is a company producing software that can create a white list in
this way.
Replying to Jim's concerns about using TCP on busy servers, he stated
that there are applications that can handle large volumes of queries
each second. He also agreed that maintaining state for TCP would be painful.
Lars Liman asked Duane to clarify if he thought TCP should be a
preferred transport. Duane said that he did suggest this. Lars voiced
the general mood that high TCP loads would be painful for a server.
Duane commented that it would still be preferable to a DDos attack. Lars
clarified that he was not against using TCP, but felt unable to advocate
using it as his preferred mode of transport. The first defence against a
DDos attack would be to rate limit the traffic in his upstream router.
Ed Lewis favoured the expansion of DNS beyond its use in root servers;
it is a quick reacting database. Recommending using TCP as a default way
of contacting DNS goes against its very nature. He also recognises that
the way UDP uses DNS manifests considerable problems, which is perhaps
why Duane sees TCP as the best way to go. Ed felt the group should first
look at the UDP problem in terms of operational practices, buffers and
the brakes put on its use. The working group might like to look into
suggestions for time-outs and back-offs, maintaining statistics about
efficient routing and so on.
Jim concurred that this was a good point. There was a short discussion
about whether the DNS Working Group is the right arena for such
investigation. Jim suggested that it might be worth the working group
gathering information about the work done by various parties and put
them into a single document identifying key elements of operational best
current practice.
Lars asked if anyone had previously measured the difference between DNS
over UDP and DNS locked down to TCP. It would appear that little
specific work has been done already in this area.
Peter Koch commented that creating a RIPE Document or bibliography style
web page containing links to the various best common practices within
DNS operation is not a bad idea. Lars pointed out that an operator
facing a problem might not first think of looking at the RIPE Document
Store for information about how to resolve his problems. Keith Mitchell
commented that a project to address this was under way with ORAC. Lars
Liman suggested that this might be well incorporated into a conventional
book.
-----------------------------------------------------------------------------
E. Software Update
(Joao Damas, ISC)
<http://www.ripe.net/ripe/meetings/ripe-53/presentations/software_update.pdf>
There was a short discussion after Peter Koch asked who in the room was
already using BIND 9.4 and had found issues with how it handles zones.
It was clear this needed some attention, introduction of checks on
sibling glue seems to have caused some problems. Joao replied that there
is no solution as yet. The change simply produces warnings, although it
can produce many of these depending on the zone in question. He pointed
out that it is possible to disable that check. Jim asks about the new
resolver library. He wanted know if this now meant that the lightweight
resolver library (LWRES) was to be phased out. He asked if anyone was
using LWRES. Joao said it was impossible to say.
-----------------------------------------------------------------------------
F. PowerDNS Update (PowerDNS Recursor)
(Bert Hubert, PowerDNS/Netherlabs)
<http://www.ripe.net/ripe/meetings/ripe-53/presentations/powerdns_update.pdf>
Tomas Simonaitis asked if PowerDNS was scalable. Bert replied it can
scale as each instance operates independently and does not communicate
with another. They do not share a cache. There is a chance that in the
future, PowerDNS will look at cache sharing. Roy Arends asked if
dnsreplay, dnsstat and dnsscope are publicly available. Bert confirmed
that they were all in the PowerDNS repository. Roy asked if the recursor
also dealt with unknown records. Bert said that it did.
-----------------------------------------------------------------------------
G. OARC Update
(Keith Mitchell, ISC)
<http://www.ripe.net/ripe/meetings/ripe-53/presentations/oarc_update.pdf>
Lars Liman commented that it was important to be aware of problems with
protecting privacy laws when researching DNS data. There are some
nations that impose far stricter rules on how such data can be used than
others do. Keith replied that the OARC secretariat is aware of these
rules and the various regulations around data protection.
-----------------------------------------------------------------------------
H. CADR
(Bill Manning)
<http://www.ripe.net/ripe/meetings/ripe-53/presentations/caadr_update.pdf>
After the presentation, Bill did a demonstration using live data. There
were no questions on the presentation.
Geoff Huston asked if the web interface was necessary to do the work.
Bill replied that this was necessary to ensure any updates were made
correctly.
Ed Lewis asked how do I find all the other delegations to change when
changing glue records. Bill replied that it did not really matter as
changes did not need to be synchronized between all of them. The child
would change the list. Host records are equivalent in peering terms, to
a registry or delegation. To change the attributes for a record, it is
necessary to log in as an administrator and change the glue records.
Ed felt that although the application demonstrated by Bill was useful,
it might not suit all registries due to the different issues each faced.
Bill agreed that not everything should be run the same way throughout
the DNS.
Peter Koch wondered if it might be better to feed the glue from the data
that has been verified through DNSSEC, rather than from host registrations.
Bill agreed that it would and that it should work in 98% of cases.
Jim Reid mentioned Keyman used by .se. He wondered if CADR could be used
in the .se environment. Bill felt Lars could answer better on this. Lars
gave his personal opinion on this. There is a fundamental difference
between CADR and Keyman models. The difference lies in authorisation.
Keyman is based on individual generating a certificate that has to be
signed by a selected group of CAs. The certificate is installed into a
browser that then handles authentication. Although both models pick up
their data from live DNS, CADR relies on DNS signatures. Bill clarified
that the CADR web interface relied on user ID and password authentication.
Anyone could request the change, but if it was not visible in the
nameservers, then nothing would happen.
-----------------------------------------------------------------------------
X. I/O with other WGs
Already dealt with under action item 52.5.
-----------------------------------------------------------------------------
Y. AOB
No other items were raised.
-----------------------------------------------------------------------------
Z. Wrap Up and Close
-----------------------------------------------------------------------------
Dear Colleagues,
The RIPE NCC Training Services Department invites you to register for
one of our upcoming DNS for LIRs Training Courses:
Date: Friday 26 January 2007
Time: 09:00-17:00
Location: Ljubljana, Slovenia
And
Date: Friday 9 March 2007
Time: 09:00-17:00
Location: Edinburgh, United Kingdom
And
Date: Friday 30 March 2007
Time: 09:00-17:00
Location: Lisbon, Portugal
The main objective of the DNS for LIRs Training Course is to provide
LIRs with information about the different DNS related services the
RIPE NCC has available for them. It covers reverse DNS procedures and
checks, as well as giving information about DNS Monitoring (DNSMON),
K-Root and anycasting.
The course also covers DNSSEC and the specific procedures set up by
the RIPE NCC to secure the in-addr.arpa zones.
Please note that the DNS for LIRs course focuses on DNS services and
procedures related to being an LIR. The course does: - NOT teach the
basics of DNS - NOT describe how to receive Internet resources from
the RIPE NCC - NOT describe fully how to operate a Local Internet
Registry (LIR)
The course is intended for technical staff of LIRs. It is assumed that
all attendees are familiar with common DNS terminology and have a
practical knowledge of operating DNS servers.
The course is free of charge. We provide lunch and printed training
materials.
We do not cover any of your travel expenses or accommodation. We give
all of our training courses in English.
You can find more information about the course at:
http://www.ripe.net/training/dns
REGISTRATION:
============
To register for this course, please use the LIR Portal or complete the
registration via our website on:
http://www.ripe.net/cgi-bin/trainingform.pl.cgi
If you have any questions please do not hesitate to contact us at
<training(a)ripe.net>.
Kind regards,
Rumy Kanis
Training Services Manager
RIPE NCC
Dear WG,
action item 48.4 reads <http://www.ripe.net/ripe/wg/dns/dns-actions.html>:
Write up a draft RIPE Document summarising the observations made regarding
AAAA resolution problems. Circulate to the list, initiate discussion what
to do, i.e. who to approach with the list of errors/problems seen.
After the presentation given by Dave Wilson (stepping in for David Malone)
<http://www.ripe.net/ripe/meetings/ripe-53/presentations/aaa.pdf>, and
also judging from the previous discussion, the majority of the wg seemed
to agree that a separate RIPE document would not be necessary. David had
already published his findings in the publicly accessible Cisco IPJ, volume 8.1
<http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-1/ipj_8-1.…>
The wg chairs would like to thank David and Dave for their work and
contributions and propose this AI be considered done. If you disagree,
please speak up until October, 27th, preferrably with identification of
any issue(s) you feel still need to be addressed. My understanding is that
David is happy to continue his monitoring efforts, but as far as the
WG is considered, the goal of raising awareness has been achieved.
-Peter
PS: Silence will be taken as consent.
Dear Colleagues,
We are pleased to announce that we will be able to accept e-mailed
requests for assignments for anycasting DNS servers from 2 October
2006. The request form and supporting notes will be available from
the RIPE Document Store at:
http://www.ripe.net/ripe/docs/internet-registries.html
We will make a separate announcement when it is possible to make
requests via the LIR Portal.
Assignments for anycasting DNS will come from reserved blocks:
* IPv4 Anycast Assignments (/24) from 194.0.0.0/18
* IPv6 Anycast Assignments (/48) from 2001:0678::/29
You may want to update your filters.
Regards,
--
leo vegoda
Registration Services Manager
RIPE NCC
