WG minutes draft
- Date: Mon, 22 May 95 23:54:49 +0300 (MSD)
- Organization: Institute for High Energy Physics, SU
Hello,
Below you find the minutes draft of our meeting during RIPE 21
at Rome. You comments are welcome.
- Leonid Yegoshin, LY22
--------------------------------------------------------------
DNS working group
Chair: Leonid Yegoshin
Scribe: Leonid Yegoshin
We discussed agenda points in reverse order due to chair initiative.
Leonid Yegoshin proposed to speak about new topics before old ones.
1. Mail routing & DNS - what about network load balancing ?
Leonid Yegoshin gave short introduction about network resourse
load balancing. The primary purpose of it are to diminish load on server
hosts and decrease network traffic. Also it is very unlike then mail from one
internal host to another internal host going to neigbour organisation
or just country follow a MX record set of destination point.
There are some activities to split load on network resourses:
- use round-robin in DNS answers (BIND 4.9.3)
- use short TTL of A records with recalculation of hosts load
(see RFC 1794)
- use separate sets of name servers for internal and world nets
with different representation of DNS tree.
Leonid Yegoshin described yet another decision for network resourse
load balancing and gave short overview of experimental version of RU-BIND
with "region" Resourse Records. This approach based on diversity of
sourse IP addresses of DNS requests and description CIDR-syntax net regions
in DNS zone.
Some discussion were at this point about problems and dangers of this
approach. One question was about caching RR's in high level name servers.
Answer was that there is TTL=0 which don't cached but used an any way.
Another question was about multiply RR's and it's combination in regions.
There is the difference in security goal and load balancing - it is not
a way to hide some RR's due to forwarder use. Dmitri Sidelnikov said
that it is very dangerous approach - it can increase chaos in Internet
and debug problems.
Leonid Yegoshin lets take in attention that DNS UDP packet size limit
is too small to transfer "region" RR of some providers and can be increased
for it. Moreover XFER of "regions" require to change XFER format.
Carl Malamud suggest Leonid Yegoshin to write RFC draft about it.
This suggestion was supported by somebody else.
Leonid Yegoshin final question "how many providers are interesting
in network resourse load balancing" was remained without definite answer
but there was opinion that it will be interesting.
2. DNS & network security (incl DNS security itself)
The question "why is it need?" was clear. Commercial server providing
require the relayable check of client source domain name (as another
information in DNS). No objection was against this point expounded by
Leonid Yegoshin. Now there are three ways to check it:
- reverse domain check. It is very popular but in general case
it is very simple to crash by experienced hacker. Moreover
it is crashed time-to-time by some BIND bugs.
- Source Responsibility Check (in RU-BIND, ftp://ftp.kiae.su/)
or VALIDITY option in BIND 4.9.3. It accept RR's the only
from responsible name server, not from arbitrary source.
It is powerfull feature but unfortunately it is not work (yet?)
in 4.9.3 - some comment exists that VALIDITY is not fully debugged.
And it can't protect packet spoofing.
- cryptographic sign of DNS exchange. There is RFC draft from
DNSSEC WG of IETF for it.
Some discussion was started from this point about situation in different
countries with cryptography and electronic sign.
- Russia (Dmitri Sidelnikov, Leonid Yegoshin cont.)
forbidden by default, but license can be obtained from goverment body.
Unfortunately it is already clear that the only methods from Russian
FAPSI would be licensed (FAPSI is Federal Agency for Goverment
Communication and Information). There is the difference between
encryption and electronic sign in FAPSI policy, but it is unclear yet.
Also the reality is the only FAPSI methods would be used as proof
in court - all cryptoanalitic experts are FAPSI experts.
- NL (Rob Blokjil) - draft to forbidden was rejected now.
- France (Francis Dupont) - forbidden. Electronic sign is legal the only
after announce the partners name for message exchange.
No any proposal or decision for Europe was done yet about DNS electronic
sign. It is obvious that there is very difficult political problem.
I think that addition mail discussion is need about situation.
Also it is important due to IPv6 authentication & encryption options.
3. What is need to keep in RIPE DB about DNS ?
There was not very long discussion about agenda point.
There is the objection against keeping information in two places - RIPE DB
and DNS. Moreover Piet Beertema has the strong objection against
the hold any information about DNS in RIPE DB which was repated in his mail
to dns-wg after WG meeting. Nobody insist on holding. After short discussion
how we can find in DNS tree the phone/fax and other (TXT records was again
proposed for that) David Kessens was offered to propose "something"
about distributed access to info (in offline, after meeting).
Nobody said anything about separation the organisation and
interorganisation domains.
4. What about primary/secondary disposition ?
Net failure & DNS - where is the level of backup,
what connectivity lost is essential for the European nets ?
This topics was discussed together due to lack of time.
France and some other time-to-time meet strange problems with root name server
access. Discussion about influence of short UDP packet size problem
and long root DNS list started.
Carl Malamud said what root name servers are need to re-establish
near *IX and it can help the problem.
Leonid Yegoshin suppose to investigate problems with DNS failure
to find the reasons (by himself) in offline. Any provider who has
unexplained DNS problem is suggested to contact him about study.
5. After WG meeting.
Some talks at lunches found yet another problem with current DNS
in CIDR environment - reverse domains for Very Small Enterprises.
Now in-addr.arpa standart has minimum 256 hosts in a single zone,
and it is an uncomfortable maintenance with VSE. If DNS would be changed
some way can be found to decide this large limit.
|