[Apologies for duplicates]
Dear colleagues,
In April 2011, Denis Walker sent a proposal to the DNS and Database
Working Groups outlining some reverse DNS-related changes to the RIPE
Database.
You can see the full proposal here:
http://www.ripe.net/ripe/maillists/archives/db-wg/2011/msg00080.html
I'm happy to report that this proposal has been fully implemented. This
means that:
- Dashes in the third octet of a DOMAIN object are no longer allowed
- Dashes in the fourth octet are now allowed
A dash in the fourth octet allows for RFC 2317-style reverse DNS
delegation for Provider Independent (PI) address allocations which don't
fall on octet boundaries.
For this second change, we converted all existing delegations into
appropriate DOMAIN objects in the RIPE Database. We will update the
reverse DNS "how-to" on the RIPE NCC website over the next few days.
If you have any questions, please send an email to <dns(a)ripe.net>.
Regards,
Anand Buddhdev
DNS Services, RIPE NCC
Dear colleagues,
Prompted by a recent news story on hacking into the computer systems of
a security firm, Geoff Huston published an article on RIPE Labs titled
"Hacking Away at the Internet's Security":
http://labs.ripe.net/Members/gih/hacking-away-at-the-internets-security
If you have any comments or questions, please feel free to post them
under the article.
Kind Regards,
Mirjam Kuehne
RIPE NCC
Colleagues, here are the draft minutes from the last RIPE meeting.
Please speak up if there are any errors or omissions. Thanks.
DNS WG – Session 1, Grand Ballroom, Wednesday 4 May 11:00
A. Administrivia
The session started on time with Peter Koch, one of the Working Group
co-Chairs, introducing himself and presenting the items on the agenda.
He asked attendees to approach him and the other co-Chairs with any
feedback or to write them an e-mail.
B. Report from the RIPE NCC – Wolfgang Nagele
The first talk was by Wolfgang Nagele from the RIPE NCC, reporting about
the status and projects of the DNS Services department.
The presentation is available here:
http://ripe62.ripe.net/presentations/85-RIPE62_WolfgangNagele_DNS_update_ed…
Jim Reid asked a question not only to Wolfgang but the whole Working
Group, wondering if there was a need for better mechanisms or processes
for reporting validation failures back to the zone owners or signers.
Wolfgang responded that they had considered the issue in relation to
e164.arpa and outages that in the future could even prevent people from
communicating about the problem. No good solution for that had been
found yet, and he said he would welcome input both from the DNS Working
Group and the community outside RIPE on what could be done about it.
Peter Koch then had a question about the transition of the reverse space
in-addr.arpa to the route servers to dedicated systems. He inquired
whether any analysis of the query counts had been performed, and whether
the reduction of the queries at the root name servers was consistent
with the queries that showed up on the dedicated systems.
Wolfgang replied that the queries were largely consistent, but he could
not speak for every root server. However, since the RIRs were operating
the system there were differences in the query loads for the new F
reverse, the A reverse and so on. On the K and F instances though the
drops were consistent, with no increase in traffic nor disappearing
traffic being observed.
The were no further questions.
C. IETF Report – Peter Koch
Peter Koch then stepped on the stage to present the IETF Report.
The presentation is available here:
http://ripe62.ripe.net/presentations/108-ietfupdate.pdf
Jim Reid commented that he had heard about a DNS API BoF, and asked if
it had actually taken place and if anything significant came out of it.
Peter Koch replied that attempts to standardize APIs did have a history
in the IETF and the IETF was kind of adverse to take out work on this
because they usually point to different entities. But to his knowledge
so far the group had not come up with an Internet draft or similar
document. He also asked Jaap Akkerhuis for more details on the subject.
Jaap responded that attendance was by invitation only and very formal,
and since he had not been invited he did not know what happened.
There were no further questions.
D. OpenDNSSEC – Jakob Schlyter
Jakob Schlyter was next with an update on the status of OpenDNSSEC.
The presentation is available here:
http://ripe62.ripe.net/presentations/82-ripe62-opendnssec.pdf
There were no questions.
E. BIND10 Live Demo – Shane Kerr
Next on stage was Shane Kerr from ISC with a live demonstration of BIND
10, asking the audience to fasten their seat-belts.
There are no slides for this presentation, but a recording of the demo
can be seen in the webcast archives here:
http://ripe62.ripe.net/archives/video/87
Peter Koch thanked Shane for giving the demonstration, then asked who
would be brave enough to put the new software into production.
Shane Kerr answered that it was already in production at ISC, but only
for BIND 10 itself. Also a lot of developers were running it for their
own vanity domains. Shane also planned to speak to the RIPE operations
team and their managers to convince them to run the software on AS112,
perhaps over the following weeks. He also wanted to set up for the
recursive side an open revolver using BIND 10 as a revolver.
There were no other questions.
F. Update on .uk DNSSEC Deployment – Brett Carr
Brett Carr presented an update on the .uk DNSSEC Deployment.
The presentation is available here:
http://ripe62.ripe.net/presentations/219-uk_DNSSEC_Status_Ripe_62.pdf
John Dickinson from Sinodun Internet Technologies Ltd. asked for
clarification about the rollover. He wanted to make sure he understood
that they were not doing scheduled rollovers because they wanted people
to use the root key and not because they were doing 5011.
Brett replied that they definitely wanted people to use the root key,
and they didn't want to do a rollover if there was no good reason for
that, since it would just add complexities.
John asked again if they were not doing 5011s, and Brett confirmed.
John commented that it could be another reason for people not to need to
notice, and Brett agreed.
Jim Reid commented that by his understanding, sch.uk was a registry of
UK schools, and Brett confirmed. Then Jim asked what would happen if the
department of education decided they didn't want to use NSEC 3 but
wanted to use DNSSEC Bis, what impact would that have on the presented
architecture and processes.
Brett said it was simple for them to do, as they could sign any of those
zones with NSEC or NSEC 3. He also said they were not using a KSK or
ZSK, but a single key for each zone. Then he asked any registrar or
interested attendees to meet him for further talks after the
presentation.
There were no other questions.
G. DNS Anomaly Detection – Ondřej Surý
The final talk of the session was by Ondřej Surý, about DNS Anomaly
Detection.
The presentation is available here:
http://ripe62.ripe.net/presentations/101-DNS-20110504-OS-RIPE62.pdf
Richard Barnes from BBN Technologies asked for clarification about the
method used: the graphs were presented for a few different query names
were spikes had been observed, and as such were those query names chosen
specifically, or did the algorithm automatically detect the spikes
occurring?
Ondřej replied that the algorithm did it automatically.
There were no further questions.
The session ended on time. Peter Koch thanked the presenters and
reminded everyone to return for the second DNS Working Group session the
next day.
DNS WG – Session 2, St. John's II Room, Thursday 5 May 11:00
Jaap Akkerhuis started the session on time by introducing himself and
the other two co-Chairs. He then reminding everyone the fact that the
session was being recorded and stenographed and asked attendees to
introduce themselves when speaking or asking a question.
O. NSD4 Plans – Wouter Wijngaards
The first talk was by Wouter Wijngaards, and it centered around the
plans for the next version of the NSD authoritative DNS server – NSD4.
The presentation is available here:
http://ripe62.ripe.net/presentations/146-NSD4-RIPE62-03.pdf
Peter Koch stated that one thing he liked about NSD was that it did not
suffer from “featurism”. He then asked if there was a list of
explicit
“non-goals” for NSD4, i.e. things that would never make it into the
release. He gave an example of it being dangerous to use the name server
for signing, and asked for a guarantee that such a thing would never
happen, or alternatively what compromises would have to be made to
ensure that.
Wouter Wijngaards confirmed that NSD4 was not a signer and it would not
do that, therefore there was also no need for dynamic updates. While the
implementation itself would not be difficult as most of the
infrastructure was already there, it would just not make sense. He
acknowledged the fact that many users want to have signers because they
want to host zones that are signed, but that would probably have to be
done by IXFR since it was already an established protocol for sending
data and the right way to go.
Olaf Kolkman, director of NLnet Labs commented that their goal with
Unbound, NSD and also OpenDNSSEC in which they were participating was to
target software to specific functions. Since signing and dynamic updates
were not authoritative name server core functionality, but rather a
provisioning function, the way he envisioned that going forward would be
a system encompassing different pieces of software, like with OpenDNSSEC
accepting the dynamic updates and NSD serving them.
He also added that they were striving to find a balance between keeping
NSD very simple and seeing the software used by as many people as
possible; there were environments where using NSD was too hard, for
example systems with 50000 zones, where restarting and recompiling the
data set every time a new zone was added would not work very well. This
was the kind of environment they were targeting with NSD4: making sure
that adding zones was easy and that the dynamic nature of the market was
well supported, while at the same time keeping the functionality bloat
at a minimal level.
While Jaap intervened to cut the discussion short, Olaf apologised for
taking the discussion in a marketing direction.
Shane Kerr from ISC asked if it was true that someone had submitted
patches for NSD3 to support SQL.
Wouter answered that he had no recollection of that, and Shane clarified
that his question was about external contributions, he wanted to know if
there was any plan on having plugins or hooks or anything like that
implemented in NSD.
Wouter replied that while there used to be some support for plugins in
version 2.0 it was subsequently removed since nobody was using the
feature and it was obviously not needed. Therefore they had no such
plans for the future, however to be in the spirit of the week he
mentioned they did plan to support IPv6 in NSD4.
There were no further questions.
P. IP6.ARPA and IN-ADDR.ARPA Changes – Dave Knight
The next presentation was by Dave Knight, about the recent changes in
the ip6.arpa and in-addr.arpa reverse delegation infrastructure.
The presentation is available here:
http://ripe62.ripe.net/presentations/161-ip6-in-addr-arpa-changes.pdf
Jim Reid expressed his surprise that only the reverse IP zones were
being moved. He asked why was not the whole .arpa domain moved off the
route servers.
Dave Knight said he had no opinion on the subject.
Jaap asked if there was discussion about that, and Dave responded that
he was not aware of any discussion, but it would be something for the
IEB to talk about.
There were no other questions.
Q. Towards a Name Server Control Protocol – John Dickinson
Next to speak was John Dickinson on the subject of a a Name Server
Control Protocol.
The presentation is available here:
http://ripe62.ripe.net/presentations/166-NSCP_RIPE.pdf
Jim Reid asked if there was any input from registrars about their
requirements for a control protocol, since they probably had a specific
set of requirements that would not fit into the conventional ISP model
with hundreds of thousands of small zones instead of a single large one.
John Dickinson explained that there had not been any comments about the
draft at that point of any technical nature. While many people when
asked directly expressed interest in such a system, getting actual
comments was proving difficult, and that was one of the reasons John was
giving the presentation.
Erik Klein from Google admitted he had not read the actual
specification, but inquired whether there was a provision for large
farms of name servers in geographically diverse areas where staging was
necessary when pushing complex zone updates to insure everything was
transferred successfully and verified before going live.
John answered that there was nothing about specific implementation in
the draft, but they did have a plan about how to implement it and that
the flexibility of NETCONF would make it possible to address the issue.
Jaap said he remembered from the NETCONF description that there was a
way for staging and final call. John added that if one were to use
JuneOS, that kind of functionality was quite familiar, or alternatively
the ability to not commit on rollback.
There were no other questions.
R. DNSSEC Client Behaviour – Sander Degen
Sander Degen was next with a presentation about various timeouts caused
by the behavior of name resolution clients on different Operating
Systems, something that will become even more important with DNSSEC as
there will be more SERVFail responses.
The presentation is available here:
http://ripe62.ripe.net/presentations/145-DNS_Client_analysis_presentation_R…
Kai Storbeck from XS4ALL asked if IPv6 was enabled on the presented
results.
Sander Degen replied that the test was performed with several
combinations and IPv6 was enabled, so double the packets could be seen.
Kai Storbeck commented that it would not only be double the packets, but
for every search list entry there would be a try for both v6 and v4, and
Sander agreed.
Roy Arends from Nominet inquired about how the caching was performed in
the case of BIND 9 and Unbound, if the client timed out because it did
not get a response.
Sander acknowledged it was a good question, and explained that while the
recursor would retry the query six times, it would cache all the client
requests until establishing that there would be no response so the
request would not get sent back to the server any more.
Roy commented that this meant the state was being kept in the cache, and
Sander agreed.
Shane Kerr from ISC inquired about the analysis of GLIBC that Sander
mentioned and what the results were thereof.
Sander answered that they could discuss that further at another time as
it would take too long.
Richard Barnes from BBN Technologies inquired whether they had
considered how the clients reacted to invalid signatures in DNS, if all
the records were returned and the protocol still worked just with an
invalid signature.
Sander agreed that it would be an interesting subject to study, however
it did not fit into the scope of the presented research and they would
like to see it in the next research.
Jaap then asked whether they had looked at one particular implementation
of GLIBC or whether they had compared it to others.
Sander replied that they had focused on the GLIBC that was opened in the
used browser (Firefox) and specifically analysed only that on a recent
version of the Ubuntu OS.
There were no further questions.
S. Changes to JP DNS traffic by DNSSEC – Masato Minda
The next presentation was by Masato Minda on the subject of DNSSEC in
the .jp ccTLD.
The presentation is available here:
http://ripe62.ripe.net/presentations/150-dnssec-in-jp-10.pdf
Jaap commented that more results will be forthcoming after they would
change the sizes, and Masato replied that it would be about 1400 to 3000
maybe.
There were no questions.
T. HSM survey – Jakob Schlyter
Jakob Schlyter was next with a talk about Hardware Security Modules
(HSMs).
The presentation is available here:
http://ripe62.ripe.net/presentations/165-ripe62-hsm.pdf
Joao Damas from ISC asked why one would invest more in protecting their
key compared to protecting their zone file.
Jakob Schlyter gave a short answer of “blame shift”, then expanded
on
it by explaining that it was all about moving risk away from operations,
which could make sense in some cases and not others depending on their
risk analysis.
Joao then inquired if the HSM would be able to detect that a mistake had
been made when signing a zone or just serve it with the wrong signature.
Jakob replied that the HSM would not be able to detect such a scenario
as the system is basically “garbage-in, garbage-out” so if the
operator
made a mistake or if there was a compromise it could serve false
signatures for quite some time before the keys were rolled. However,
there were some good scenarios for using HSMs in his opinion even though
other people might disagree.
John Dickinson from Sinodun Internet Technologies Ltd. commented that he
had conducted a similar study while working for Nominet and a big
difference between the various models was the quality of the
documentation. In the ned he concluded that a company that was not able
to write good documentation could not be trusted to write good security
code. He then asked if the quality of the documentation was considered
in the presented study.
Jakob responded that there were two parts of the documentation – on
one
hand the documentation for certification which was usually pretty good,
and on the other hand the end-user documentation which had varying
levels of quality. While some parts of that analyses were included in
the report, he would advise people to ask the vendors for documentation
before buying.
Jaap intervened and asked for a very short question since the time was
running short.
LG Forsberg from .NU Domain Ltd asked how a software signer on a
decently sized server would compare in regards to performance.
Jakob replied that it would depend on the number of cores and other
parameters, but in general around 1000-2000 keys per second, which could
as well be considered “good enough”.
There were no further questions.
U. The “Dancing F-Root” Story – Wilfried Woeber
The final presentation was by Wilfried Woeber regarding an analysis
performed on the DNS root-servers using the infrastructure provided by
the RIPE NCC Atlas project.
The presentation is available here:
http://ripe62.ripe.net/presentations/116-Atlas-n-F-Root.pdf
Joao Damas commented that the behaviour described was typical of
root-servers – multi-homed layers, with multiple exit points being
basically one way of looking at Anycast. He described his experience
with asking GEANT to carry F-Root from more than one instance which
turned out to be too complicated to do for various internal reasons,
leaving the whole set of networks that depended on GEANT for accessing
the Internet or parts of it at the whim of what GEANT would choose,
which was not under their direct control. What they did implement was a
system for rapid detection of such events that would allow network
administrators to quickly pinpoint the leak by looking at AS paths,
allowing them to fix it in time.
Faidon Liambotis from GRNET inquired when the described problems took
place.
Wilfried responded that it had happened two-three weeks before the date.
Faidon commented that they had seen a similar problem in 2009 with GEANT
and F-Root, with v4 going to South America and v6 to Hong Kong; he
notified both ISC and GEANT which resulted in them fixing the issue
fairly quickly – in the end, it all boiled down to finding the right
people which would now how to debug the issue.
Wolfgang Nagele from the RIPE NCC added that in terms of K-Root, they
used to have the same strategy with more or less specific prefixes
depending on node capacities. Shortly before the date they actually
decided to replace the system with one consistent prefix announcement
size, because from their experience it produced more problems than it
solved and it was difficult to troubleshoot. The same was true for
Anycast too, since it became very hard to control when a lot of
locations were involved and side-effects were impossible to estimate in
advance.
Jaap asked for one last quick question.
Rober Kisteleki from the RIPE NCC said that he was the one responsible
for the Atlas project, and it put him in a difficult situation because
they had so many good ideas about the project and too little time to
implement them all while also taking into account the community's
desires. One of the things they were planning to do was a kind of tie-in
between traceroute measurements and RTT measurements so that when a
sudden change would be observed the modification in the path could be
recorded and analysed; a warning system could also be implemented in
relation to that. He explained that the described features would be
implemented since they made a lot of sense and were the way forward.
Jaap commented that looking at ICMP would be interesting, but it would
only measure when the “light was on” and there was an actual
response,
otherwise yielding no information.
Z. A.O.B.
There was no other business.
Jaap thanked the NCC staff for supporting the meeting and ended the
session.
Dear all,
How time flies. End of October the dns-wg will meet again, this time in
Vienna. Therefore we are asking again for agenda items. Please send you
suggestions to the dns-wg chairs or me directly.
jaap
[Apologies for duplicate emails]
Dear colleagues,
On Monday, 5 September, the RIPE NCC will roll over the Key-Signing Keys
(KSKs) of all our signed zones.
Once we verify that the roll-over has been successful, we will update
the trust anchors of most zones in their respective parent zones. We
still have a small number of islands of trust, and we will publish
updated trust anchor files for these zones on the RIPE NCC website at:
https://www.ripe.net/data-tools/dns/dnssec/dnssec-keys
If you're still using our trust anchors in your resolvers, please update
them next week.
Regards,
Anand Buddhdev
DNS Services, RIPE NCC
