- dns-wg - mailman.ripe.net

Re: DNS Problem
by e07＠nikhef.nl 15 Sep '95

15 Sep '95

> your dislike of the new ABC system. For the sake of > alphabetical order it sacrifices useful positional > information. No, the only reason for the change was to be able to use much better name compression to prevent udp packet overflow for those replies that need the list of all root servers and their addresses. -- Eric

1 0

Re: DNS Problem
by zsako＠banknet.net 15 Sep '95

15 Sep '95

> From: Robert Martin-Legene <robert(a)dknet.dk> > To: Piet Beertema <Piet.Beertema(a)cwi.nl> > Cc: dns-wg(a)ripe.net > On Fri, 15 Sep 1995, Piet Beertema wrote: > > > - In the init file one could still see where a given > > root server is located, by comparing the A record > > with the A records of the root servers. > > A bit complicated.. If the in-addr.arpa didn't map to the root-servers.net > zone, but to the old name you could easily use host -A e.root-servers.net > and find the old "location". Why they didn't do that I'm not really sure.= I suppose it is mainly because the "old location" can have several IP addresses only one of which is defined in the root-servers.net domain (ns.nasa.gov is such an example). This can probably allow for security features such as packet filtering on destination address. By the way, PSI.NET has solved the problem in a similar manner to what you suggest, but the other way round: c.psi.net CNAME c.root-servers.net c.root-servers.net A 192.33.4.12 Janos Zsako

1 0

Announcement: new procedure for in-addr.arpa reverse delegations
by RIPE NCC IN-ADDR. ARPA Role Account 19 Jun '95

19 Jun '95

Dear all, As of today the RIPE NCC offers an automated method for the submission of reverse zone delegations in 193.in-addr.arpa and 194.in-addr.arpa. Your delegation requests and the zone files on all nameservers will be checked automatically. The diagnostics generated by these checks will be returned to you automatically too. This will make you aware of any problems very quickly, so that you can correct them and re-submit your request. When the automated procedure does not detect any errors, the request is forwarded to the inaddr role account person for some additional manual checks and the processing of the delegation itself. Of course, you will receive an acknowledgement when this has been done. To use the new automated procedure send your request in ripe-105 format to: <auto-inaddr(a)ripe.net> You can use some keywords in the 'Subject:' line of your E-mail to control the checking process. The use of the LONGACK keyword is very recommended. HELP - will send you a (patched) ripe-105 document CHANGE - is needed if you want to change an existing reverse delegation LONGACK - will give you the most verbose output as possible RIPE document ripe-105 requires you to send in a RIPE database 'inetnum' object with a 'rev-srv' attribute for each nameserver for single/multiple C's reverse delegation requests and for whole blocks 'domain' objects with 'nserver' attributes for each nameserver. I recommend to use the following procedure for doing your request: Send an E-mail to <auto-inaddr(a)ripe.net> with LONGACK in the 'Subject:' line and an appropriate RIPE database object as described in ripe-105 in the body of the message. We still accept the old method for reverse delegation requests (ripe-105 format request to <inaddr(a)ripe.net>), however it might take some more time to process them. After some time, when the software doesn't change daily anymore, the source code will be published. I am neither a DNS expert or native English writer ;-) so all your comments are welcome! Please send them together with complaints, bug reports or special requests to <inaddr(a)ripe.net>. Kind regards, David Kessens RIPE NCC

1 0

WG minutes draft
by egoshin＠ihep.su 22 May '95

22 May '95

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.

1 0

Re: URGENT: WG agendas
by egoshin＠ihep.su 08 May '95

08 May '95

Hello, I can support the proposal about changing current working of DNS WG by the next topic list for agenda: 1. What is need to keep in RIPE DB about DNS ? 2. Whats about primary/secondary disposition ? (in terms of rules for service providers & customers) 3. Net failure & DNS - where is level of backup, what connectivity lost is essential for Europe net ? 4. DNS & network security (incl DNS security itself) 5. Mail routing & DNS - whats about network load balancing ? - Leonid Yegoshin, LY22.

2 1

A tool to check DNS zones before installing them
by Benoit Grange 05 May '95

05 May '95

Hello, I've written a tool to check if a zone is correctly configured before delegating it (or to check tge zone anyway, but the tool does not require that the zone is delegated from the upper level servers). This tool is being used locally at NIC France and I make it available, hoping this will interest other sites. http://www.nic.fr/ZoneCheck Please try it, and report comments to Benoit.Grange(a)inria.fr At this time, this tool is completly experimental... please do *not* advertise it now to end users. -- Benoit Grange NIC France E-Mail: nic(a)nic.fr Personnal E-Mail : Benoit.Grange(a)inria.fr

1 0

A tool to check if a host takes care of UDP checksum
by Benoit Grange 05 May '95

05 May '95

Hello, I've written a small tool to see if a host takes care of UDP checksums. This may be important for DNS operation, as corrupted packets without UDP checksums can break some DNS servers. Thanks to an idea of Francis Dupont, the motus operandi is to send a packet with a BAD udp checksum and to see if the host processes it, usually responding with an ICMP PORT UNREACHABLE. If yes, the host is broken. If no ICMP message is received, either the network is broken or the host is fine. This work because most of the host that do not generate UDP checksums will not check UDP checksums of incoming packets (this clearly violates the RFCs...). It is a lot easier to do things this way by sending bad packets and waiting for a reply than trying to look into received packets to see if the checksum is corret. The latter solution requires some network tapping, and may not be easily portable. ckudpcksum is available at: ftp://ftp.nic.fr/pub/autres/dns-wg/ckudpcksum.tar.gz Read the manual, and please DO NOT overuse the program as remote hosts will increment MIB counters each time a wrong packet is received. -- Benoit Grange NIC France E-Mail: nic(a)nic.fr Personnal E-Mail : Benoit.Grange(a)inria.fr

1 0

Number of domain objects in RIPE database
by RIPE NCC Staff 04 May '95

04 May '95

Action: 20.11 RIPE NCC To investigate (as time permits) distribution of the domain information in the RIPE database and to investigate a "private" approach for referrals. Dear working group members, Relating to Action Item 20.11 from the previous RIPE meeting I have been asked to produce and send out some statistics about the number of domain objects in the RIPE database. You will find them below. I hope they are self-explanatory. Regards, Roderik Muit RIPE NCC AT : 132 objects, 25 different second-level domains BE : 481 objects, 458 different second-level domains BG : 28 objects, 28 different second-level domains CH : 709 objects, 709 different second-level domains COM : 5 objects, 5 different second-level domains CS : 4 objects, 4 different second-level domains CZ : 276 objects, 276 different second-level domains DE : 1512 objects, 1510 different second-level domains DK : 219 objects, 219 different second-level domains EE : 5 objects, 3 different second-level domains ES : 1 objects, 1 different second-level domains FI : 166 objects, 165 different second-level domains FO : 13 objects, 13 different second-level domains FR : 878 objects, 869 different second-level domains GA : 2 objects, 2 different second-level domains GL : 2 objects, 2 different second-level domains GR : 6 objects, 6 different second-level domains HU : 260 objects, 259 different second-level domains IE : 10 objects, 10 different second-level domains IL : 270 objects, 7 different second-level domains IS : 63 objects, 52 different second-level domains IT : 713 objects, 487 different second-level domains LI : 5 objects, 5 different second-level domains LT : 60 objects, 60 different second-level domains LU : 6 objects, 6 different second-level domains LV : 2 objects, 2 different second-level domains NET : 13 objects, 12 different second-level domains NL : 1559 objects, 1558 different second-level domains NO : 936 objects, 771 different second-level domains PL : 7 objects, 4 different second-level domains PT : 105 objects, 105 different second-level domains RO : 1 objects, 1 different second-level domains RU : 1 objects, 1 different second-level domains SE : 7 objects, 7 different second-level domains SK : 165 objects, 165 different second-level domains SU : 4 objects, 4 different second-level domains TN : 3 objects, 3 different second-level domains TR : 6 objects, 3 different second-level domains UA : 3 objects, 2 different second-level domains UK : 20 objects, 3 different second-level domains YU : 7 objects, 7 different second-level domains 164: 1 reverse delegations 192: 22 reverse delegations 193: 297 reverse delegations 194: 105 reverse delegations

1 0

DNS vs. RIPE DB checking tool
by Havard Eidnes 12 Mar '95

12 Mar '95

Hi, as promised at the last RIPE meeting, please find below a copy of the perl script I have which checks for the consistency between what is registered in the RIPE database for the domains and what is registered in the DNS. Do note, this script does nothing more than report what it thinks is inconsistencies, you still need to sift through the error reports this script produces and fix any inconsistencies yourselves. This script relies on a number of conventions and is a bit picky about what needs to be in the RIPE database if it is to not complain too much. First, the script has to know which domains it should check. It performs this decision by "traversing" the domain objects in the RIPE database starting from the object for the top-level domain. If the object in question has at least one sub-dom: attbibute, my script assumes that all names registered in this domain should be registered in the RIPE database with it's own domain object. This way, you use the "sub-dom" attbiutes to span out a subset of the DNS hierarchy under a given top-level domain where administrative registration in the RIPE database is required for DNS registration. The script subsequently does zone transfers for the DNS domains corresponding to the domains which should be checked as decided above. When querying the RIPE database, the set of name server records for each domain is recorded, so that the script can compare these with what is registered in the DNS. This is one point where my script deviates slightly from or is slightly more strict than the RIPE-49 document, in that it 1) does not permit IP addresses in the nserver: attribute (since you do not delegate to an IP address in the DNS, this makes sense) 2) does not permit more than one word in each nserver: attribute This makes registration such as: nserver: aun.uninett.no / 129.241.1.99 illegal, and nserver: aun.uninett.no nserver: 129.241.1.99 would also be flagged as an error when compared to the DNS output. It is my beleif that the RIPE database does not adequatly support the registration of glue records (I do not think it needs to either), and putting the glue record information in together in the nserver: attribute is bad when seen from the database normalization and maintenance side. If a domain is registerd in the DNS with only MX information, my script demands that the corresponding registration in the RIPE database should contain the string "MX-only" in one of the remarks: attributes of the domain. Subsequently, what has been harvested via the RIPE database and what has been fetched from the DNS is compared, and any inconsistencies are reported. These are: 1) Check for domains registered in the RIPE database but not in the DNS, report these as errors 2) Check for domains registered in the DNS but not in the RIPE database, report these as errors 3) For delegated domains, report any inconsistencies between the set of nserver: attribute values and the NS records in the DNS 4) Check for domains with both MX and NS records in the DNS, report these as errors 5) Check that only domains marked in the RIPE database as "MX-only" really have an MX-only registration in the DNS. Lastly, this script depends on dig version 2.0 (forget the one which comes with BIND 4.9.3 -- the external interface changed for the worse, IMHO) and on a whois client which uses getopt() to parse it's arguments (so that I can use the '--' construct to separate the options and the arguments). If you have another version of whois than this, the fix should be trivial (at the top of "get_ripe_data". Note: the script creates a "cache file" with name cc.ripe-cache in the current directory containing all the domain objects without sub-dom attributes, so that multiple runs in quick succession can be a little faster (do however remember to remove any objects you sent in updates for, or remove the cache after substantial modifications). Well, other than this, read the script -- it's some 450 lines of simple straight-forward Perl code. - Håvard #!/local/bin/perl # $Id: domain-check.pl,v 1.7 1995/03/12 18:37:22 he Exp $ # # Perl script to check the consistency between what is registered in the # RIPE database and what is registered in the DNS for the domain objects # under a given domain. Missing pieces (i.e. inconsistencies) for either # registration is reported. # Pull in data for a given domain from the DNS using dig sub get_dns_data { local($domain) = @_; local($ns, $label, $zoneok); local($wildcard_label); $zoneok = 0; $ns = &get_primary_ns($domain); if (!defined($ns)) { &err("Could not get SOA for $domain\n"); return undef; } $digcmd = "dig @$ns $domain axfr +nodefname +pfset=0xa024"; $digcmd = $digcmd . " | tr '[A-Z]' '[a-z]' |"; open(dig, $digcmd) || return undef; while(<dig>) { chop; split; if ( $_[1] eq "in" ) { chop($_[0]); $label = $_[0]; $wildcard_label = 0; if ($label =~ /^\*\./) { $label = substr($label, 2); $wildcard_label = 1; } } else { if (( $_[1] eq "matching" && $_[0] eq ";" ) || ( $_[1] eq "received" && $_[0] eq ";;" && $_[3] eq "records" )) { $zoneok = 1; } next; } if ( $_[2] eq "a" ) { $dns_glued{$label} = 1; } elsif ( $_[2] eq "ns" ) { chop($_[3]); $dns_ns{$label} = $dns_ns{$label} . ":" . $_[3]; $dns_delegated{$label} = 1; $in_dns{$label} = 1; } elsif ( $_[2] eq "mx" ) { $dns_mx_domain{$label} = 1; if ($wildcard_label) { $dns_mx_wildcard{$label} = 1; } $in_dns{$label} = 1; } elsif ( $_[2] eq "cname" ) { $dns_cname{$label} = 1; } elsif ( $_[2] eq "soa" ) { # nothing to do, ignore } elsif ( $_[2] eq "hinfo" ) { # nothing to do, ignore } elsif ( $_[2] eq "wks" ) { # nothing to do, ignore } else { printf stderr "spurious data: $_\n"; } } close(dig); if ($zoneok) { return 1; } else { &err("No matching SOA record found from $ns\n"); return undef; } } sub get_primary_ns { local($domain) = @_; local($ns, $digcmd); $digcmd = "dig $domain soa +nodefname +aa +pfset=0xa020"; $digcmd = $digcmd . " | tr '[A-Z]' '[a-z]' |"; open(dig, $digcmd) || return undef; while(<dig>) { chop; split; if ( $_[1] eq "soa" ) { close(dig); return $_[2]; } } close(dig); return undef; } # Pull in any cached data from the RIPE database previously saved to disk # by get_ripe_data sub get_ripe_cached_data { local($domain) = @_; local($tag); open(cache, $ripe_cache_name) || return undef; while (<cache>) { tr/A-Z/a-z/; chop; split; chop($_[0]); $tag = $_[0]; if ( $tag eq "nserver" ) { $ripe_ns{$domain} = $ripe_ns{$domain} . ":" . $_[1]; if ( $#_ > 1 ) { &err("RIPE: more than one nserver on a line for $domain\n"); } } if ( $tag eq "domain" ) { $domain = $_[1]; $in_ripe_db{$domain} = 1; } if ( $tag eq "sub-dom" ) { shift; while ($subdom = shift) { $fqdn = $subdom . "." . $domain; push(domains_to_check, $fqdn); if ( ! $has_subdom{$domain} ) { $has_subdom{$domain} = 1; push(needs_dns_xfer, $domain); } } } if ( $tag eq "remarks" ) { if ( /mx-only/ ) { $ripe_mx_only{$domain} = 1; } } } close(cache); return 1; } # Pull in data for a given domain from the RIPE database using whois # Put received data in "ripe-cache" (append it). The assumption is that # get_ripe_data will not be called unless data isn't found in the cache. sub get_ripe_data { local($domain) = @_; local($tag, $subdom, $fqdn); local($do_cache) = 1; local(@entry, $s); $whoiscmd = "whois -h whois.ripe.net -- '-r '$domain |"; open(whois, $whoiscmd) || return undef; open(cache, ">>$ripe_cache_name") || undef $do_cache; while(<whois>) { if ( /No entries found for the selected source/ ) { close(whois); return undef; } if ($do_cache) { push(@entry, $_); } tr/A-Z/a-z/; chop; split; chop($_[0]); $tag = $_[0]; if ( $tag eq "nserver" ) { $ripe_ns{$domain} = $ripe_ns{$domain} . ":" . $_[1]; if ( $#_ > 1 ) { &err("RIPE: more than one nserver on a line for $domain\n"); } } if ( $tag eq "domain" ) { $in_ripe_db{$domain} = 1; } if ( $tag eq "sub-dom" ) { if ($do_cache) { close(cache); } undef $do_cache; # Do not cache entries with sub-dom entries shift; while ($subdom = shift) { $fqdn = $subdom . "." . $domain; push(domains_to_check, $fqdn); if ( ! $has_subdom{$domain} ) { $has_subdom{$domain} = 1; push(needs_dns_xfer, $domain); } } } if ( $tag eq "remarks" ) { if ( /mx-only/ ) { $ripe_mx_only{$domain} = 1; } } } close(whois); if ($do_cache) { while($s = shift(@entry)) { print cache $s; } close(cache); } return 1; } # Check existence of data in RIPE database for a given domain # (independent of sub-dom tree). Might as well use code above # which pulls in data from RIPE database entry (if it exists). sub in_ripe_db { local($domain) = @_; return &get_ripe_data($domain); } # Get all RIPE data (decending recursively through sub-dom) # for a given domain, noting registered sub-doms that do not have # their own entry in the RIPE database sub get_all_ripe_data { local($domain) = @_; local(@domains_to_check) = @_; &notify("Getting cached RIPE data for domain $domain:"); $ripe_cache_name = $domain . "." . "ripe-cache"; &get_ripe_cached_data($domain); &notify("\nGetting all RIPE DB data: "); while ($domain = shift(domains_to_check)) { if (! $in_ripe_db{$domain} ) { # Not already seen in cache &notify_progress(); if ( ! &get_ripe_data($domain) ) { &err("RIPE database entry missing for $domain\n"); } } } } # Pull inn all relevant data for doing a check. Decend through sub-dom # entries in the RIPE database and pull in data for the relevant DNS zones # as well. sub pull_in_data { local($domain) = @_; &get_all_ripe_data($domain); &notify("Getting corresponding DNS data\n"); while ( $domain = shift(needs_dns_xfer) ) { &notify("Getting zone data for $domain\n"); if (! &get_dns_data($domain) ) { &err("Zone transfer of $domain failed\n"); } } } # Perform an extensive consistency check between the data fetched from DNS # and those fetched from the RIPE database. In particular, check: # # 1) Check that all entries in the RIPE database are in the DNS and # vice versa; report inconsistencies. # # 2) Where entries exist in both RIPE and the DNS, check: # # a) for delegated domains, the set of NS records in DNS and those # registered in the RIPE nserver entries match up # # b) for domains with both NS and MX records in the DNS, report # this as an inconsistency # # c) for MX-only domains (in the DNS), check that the corresponding # entry in the RIPE database contains the remark "MX-only". sub do_consistency_check { &report_missing_ripe(); &report_missing_dns(); &report_ns_inconsistencies(); &report_inconsistent_domains(); &report_mx_comments(); } # Report entries in the DNS which do not exist in the RIPE database sub report_missing_ripe { local($domain); foreach $domain (keys %in_dns) { if ( ! $in_ripe_db{$domain} ) { if ( &in_ripe_db($domain) ) { &err("Missing as sub-dom in parent object: $domain\n"); } else { &err("Missing in RIPE db: $domain\n"); } $ignore{$domain} = 1; } } } # Report entries in the RIPE database missing in the DNS sub report_missing_dns { local($domain); foreach $domain (keys %in_ripe_db) { if ( ! $in_dns{$domain} ) { if ( ! $dns_cname{$domain} ) { &err("Missing in DNS: $domain\n"); $ignore{$domain} = 1; } } } } sub split_ns_list { local($ns_str) = @_; local(%array, @tmp, $elt); $ns_str =~ s/^://; @tmp = split(/[:]+/, $ns_str); while ($elt = shift(@tmp)) { $array{$elt} = 1; } return %array; } # Report inconsistencies between registered name servers DNS/RIPE sub report_ns_inconsistencies { local(%dns_nses, %ripe_nses); local($heading_written) = 0; local($domain, $ns); foreach $domain (keys %in_dns) { if ( ! $ignore{$domain} ) { %dns_nses = &split_ns_list($dns_ns{$domain}); %ripe_nses = &split_ns_list($ripe_ns{$domain}); foreach $ns (keys %dns_nses) { if ( ! $ripe_nses{$ns} ) { &err("Missing NS in RIPE for $domain: $ns\n"); } } foreach $ns (keys %ripe_nses) { if ( ! $dns_nses{$ns} ) { &err("Missing NS in DNS for $domain: $ns\n"); } } } } } # Report domains with both NS and MX records in the DNS # and domains in RIPE database with both nserver and remark: MX-only. sub report_inconsistent_domains { local($domain); foreach $domain (keys %in_dns) { if (defined($dns_ns{$domain}) && defined($dns_mx_domain{$domain})) { &err("Both MX and NS records for $domain in DNS\n"); } } foreach $domain (keys %in_ripe_db) { if (defined($ripe_mx_only{$domain}) && defined($ripe_ns{$domain})) { &err("Both nserver and remark: MX-only in RIPE db for $domain\n"); } } } # Report MX-only domains where RIPE entry doesn't contain remark "MX-only" # and MX-only domains in RIPE database which are fully delegated in DNS sub report_mx_comments { local($domain); foreach $domain (keys %in_dns) { if ($in_ripe_db{$domain}) { if ($dns_mx_domain{$domain}) { if (! $ripe_mx_only{$domain}) { &err("MX-domain in DNS, RIPE db not marked for $domain\n"); } } } } foreach $domain (keys %in_dns) { if ($dns_delegated{$domain}) { if ($ripe_mx_only{$domain}) { &err("MX-domain in RIPE, DNS fully delegated for $domain\n"); } } } } sub err { local(@args) = @_; if ($dot_written) { $dot_written = 0; printf stderr "\n"; } printf stderr @args; } sub notify { local(@args) = @_; if ($dot_written) { $dot_written = 0; printf stderr "\n"; } printf stderr @args; } sub notify_progress { printf stderr "."; $dot_written = 1; } $arg = $ARGV[0]; if (defined($arg) && ($arg =~ /^..$/)) { &pull_in_data($arg); &do_consistency_check(); } else { &err("usage: domain-check.pl cc\n"); &err("\twhere cc is a two-letter country code\n"); }

1 0

DNS UDP checksums
by Benoit Grange 03 Feb '95

03 Feb '95

I ran a tcpdump during 15 minutes this morning to check how many servers were not doing UDP checksums on their DNS packets. The result is: 35% of our DNS traffic is NOT CHECKSUMMED. Even some important name servers do no checksum their traffic (browse the list and be surprised). The list of correct or incorrect name servers are available as: ftp://ftp.nic.fr/pub/autres/dns-wg/nocksum ftp://ftp.nic.fr/pub/autres/dns-wg/cksum --------------- Benoit Grange NIC France E-Mail: Benoit.Grange(a)inria.fr

1 0