- dns-wg - mailman.ripe.net

RE: [dns-wg] Matching forward and reverse DNS for DSL pool addresses
by brian.wilkinson＠bt.com 01 Dec '04

01 Dec '04

ok - Thanks to all that replied. We already provide matching forward and reverse - I just wanted to verify that it was definitly required as I am currently reviewing our DNS management processes. Regards Brian -----Original Message----- From: Jim Reid [mailto:jim@rfc1035.com] Sent: Wednesday, December 01, 2004 12:48 PM To: Wilkinson,BJ,Brian,XJG11 R Cc: dns-wg(a)ripe.net Subject: Re: [dns-wg] Matching forward and reverse DNS for DSL pool addresses >>>>> "brian" == <brian.wilkinson(a)bt.com> writes: brian> Can anyone confirm whether DSL (and dial) providers are brian> required to provide matching forward and reverse DNS for brian> the address pools or is a wildcard in the reverse zones brian> sufficient? There's no requirement. Though your customers might appreciate it if reverse lookups worked for the IP addresses. Sometimes applications will make life difficult for hosts that don't have working reverse DNS. For instance a client that initiates an SMTP connection may be considered a spam source if there's no sensible answer to a reverse lookup of the client's address. And as Peter has said, wildcards are probably not a good idea for this sort of thing. It could also break when the application does a forwward lookup of the name returned by a reverse lookup. The BSD r- protocols -- which I hope nobody uses any more -- do this to decide if the client is who they claim to be and therefore determin if the client is trusted or not.

1 0

Re: [dns-wg] Matching forward and reverse DNS for DSL pool addresses
by Jim Reid 01 Dec '04

01 Dec '04

>>>>> "brian" == <brian.wilkinson(a)bt.com> writes: brian> Can anyone confirm whether DSL (and dial) providers are brian> required to provide matching forward and reverse DNS for brian> the address pools or is a wildcard in the reverse zones brian> sufficient? There's no requirement. Though your customers might appreciate it if reverse lookups worked for the IP addresses. Sometimes applications will make life difficult for hosts that don't have working reverse DNS. For instance a client that initiates an SMTP connection may be considered a spam source if there's no sensible answer to a reverse lookup of the client's address. And as Peter has said, wildcards are probably not a good idea for this sort of thing. It could also break when the application does a forwward lookup of the name returned by a reverse lookup. The BSD r- protocols -- which I hope nobody uses any more -- do this to decide if the client is who they claim to be and therefore determin if the client is trusted or not.

1 0

Matching forward and reverse DNS for DSL pool addresses
by brian.wilkinson＠bt.com 01 Dec '04

01 Dec '04

Can anyone confirm whether DSL (and dial) providers are required to provide matching forward and reverse DNS for the address pools or is a wildcard in the reverse zones sufficient? Regards Brian Wilkinson

3 2

Query on Resolver w.r.t DNSSEC
by Natarajan,Ganesh 23 Nov '04

23 Nov '04

Hi , I am Ganesh and I work for wipro. We are currently working on porting DNS BIND 4.8 to DNS BIND 9.2.3. My platform is HP-Nonstop servers. I have a specific query regarding the role of resolver library in DNSSEC. Query: Does DNS BIND 9.2.3 support caching and verification of RRs (resourse records) on the resolver library part by default? We are trying to port 4.8 resolver code to 9.2.3 resolver code. Since Our platfrom doesn't support OPenssl, we are trying to lookout for this option. we wanted to know, whether by default any authentication is enabled at the resolver part in BIND 9.2.3. We understand that RFC2535 states CD and AD bit. If CD bit is set, then resolver doesn't do auth and integrity tests. Is this CD bit disabled or enabled in BIND 9.2.3? To reiterate the whole question again, we wanted to know the role of resolver with respect to DNSSEC in BIND 9.2.3! Since, we are pretty new to DNSSEC, we need your valuable inputs on the above query. regards, Ganesh. Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin(a)wipro.com immediately and destroy all copies of this message and any attachments.

3 2

ripe policy about reverse dns?
by Peter Gervai 01 Nov '04

01 Nov '04

Hello, I tend to remember that RIPE had a strict policy about delegated address space reverse DNS: adresses must have a valid reverse and delegated (sub) blocks must be registered in RIPE db. I wanted to refer to the document mentioning these requirements but I was not able to find them. Navigating on www.ripe.net helped nothing: reverse dns part shows the procedure, refers to a page "about ripe policies" which contains only links to RFC and other RIPE documents, which in turn are about the procedure and not any policy. Maybe there are any hidden one mentioning that "you should have reverse on your addresses" but I kindly ask your help where to look for it. If this requirement would have been dropped then I'd be extremely happy to know about it. Thank you, Peter ps: Reason is a(nother) big provider with many /19 and with no reverse or RIPE entry (other than the /19) whatsoever, and occasional spam from these reverseless and nameless blocks.

2 1

Re: [dns-wg] Re: ORSN-SERVERS.NET
by Jim Reid 28 Oct '04

28 Oct '04

>>>>> "Jon" == Jon Lawrence <jon(a)lawrence.org.uk> writes: Jon> Maybe I'm thick, but I still don't get it. What is the Jon> advantage of ORSN over the ICANN root ? I have no idea. However this list is not the place to discuss this topic further. It's essentially a local policy matter and is therefore inappropriate for the DNS WG. If someone wants to set up a mailing list to debate this, please go ahead and do so. Tell us where it is and how to subscribe and unsubscribe. Other than that, I would appreciate it if the discussion of alternate roots stopped in this list. Thanks.

2 1

Jumping the gun on SIDN!
by Pim van Pelt 28 Oct '04

28 Oct '04

Hi, With some relief and pride, I'd like to show you that the dutch registry SIDN has enabled their registrars to offer IPv6 glue. One can send in a request using a freeform ticket. I happen to have been the first, so since todays serial of 200410280, there are new records in the nl. zone. Yaay! ; <<>> DiG 9.3.0 <<>> @ns.domain-registry.nl NS bit.nl. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1989 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 6 ;; QUESTION SECTION: ;bit.nl. IN NS ;; AUTHORITY SECTION: bit.nl. 86400 IN NS nsauth1.bit.nl. bit.nl. 86400 IN NS nsauth2.bit.nl. bit.nl. 86400 IN NS nsauth3.bit.nl. ;; ADDITIONAL SECTION: nsauth1.bit.nl. 86400 IN A 213.136.12.51 nsauth2.bit.nl. 86400 IN A 213.136.12.59 nsauth3.bit.nl. 86400 IN A 212.204.192.11 nsauth1.bit.nl. 86400 IN AAAA 2001:7b8:3:2c::53 nsauth2.bit.nl. 86400 IN AAAA 2001:7b8:3:2d::53 nsauth3.bit.nl. 86400 IN AAAA 2001:898:1001:1003::53 ;; Query time: 46 msec ;; SERVER: 193.176.144.2#53(ns.domain-registry.nl) ;; WHEN: Thu Oct 28 13:04:59 2004 ;; MSG SIZE rcvd: 222 The dutch registry will implement and enable IPv6 in their infrastructure also, so I'm told by SIDN. -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)

2 1

Re: [dns-wg] Re: ORSN-SERVERS.NET
by JFC (Jefsey) Morfin 28 Oct '04

28 Oct '04

At 21:57 24/10/2004, Jay Daley wrote: >Markus >Markus wrote on 22/10/2004 12:26:13 pm: > > > We are only the > > european (independent) copy of the stable ICANN root server system :-)) > >I really do not understand this. How are you in anyway more independent >than k-root or i-root? Jay, I will try to review this key point for the internet development. what ORSN does is risk containment. Suppose the ICANN/NTIA root is hacked. The ORSN file is not affected. This provides a protection. Now, obviously, if the delay in updating the ORSN file is too long it is going to pollute the namespace with old data. This is why trouble shouting calls for a report on possible differences. Such report must be taken both ways: - a way to know that ORSN is outdated - an alarm that the ICANN/NTIA root may be hacked. This kind of issue has been identified by the dot-root project of a DNS test bed we carried last years. This has lead us to work on local roots concepts and eventually on the authoritative root matrix (which is not documented, but implemented in reality through the additional name servers entered in the top level through ccTLD db.files for example). This also lead to the AFRAC project (http://afrac.org) to unlock root files (like the ICANN/NTIA root file) as this is true for any other application root file, through contextual root files for what we named "externets" (ie an external global view of the internet). For example, a Japanese externet can be all the users and hosts which freely chose to belong to it. End to end relations may then be limited to these externet members (only people able to read Japanese). You can belong to many externets. In the case of a nation, we identified that a national externet is a regalian duty. What does that mean? It means that many things may happen which affect your sure national use of the DNS. In 99.99% of the case that you use an US, a French, an European or a East-Timor root server is the same. But in critical occasions you will want to use a nameserver which will follow the rules which protect your skin. We developed this kind of thinking in parallel to the White House - we proposed ICANN to work on an "ICP-4" document on netsecurity in December 2001 at the DNSO/BC with a few large operators and corporations,. We then introduced the dot-root project to work on this along the lines of the ICP-3 document which investigates the possible end of an authoritative file and defines the conditions for test bedding we stick to [we added a few]). The White House (Dick Clarke) worked along the same lines after 9/11 and came with a very powerful evaluation showing that the internet represented a nuclear equivalent risk to the USA through the vulnerability of critical infrastructures and the impact on the US economy and way of life of a major dysfunction. We could measure it through the impact of the East Coast Black Out - should it have happened in Feb blizzard, the impact would have been devastating. This eventually lead to the http://whitehouse.gov/pcipb national strategy, the first visible impact we all know is the DoD IPv6 commitment. Let imagine that a terrorist atomic bomb blows Washington-West (the top worldwide target and an US working hypothesis). The propagation through the internet would be times devastating than the bomb itself on the USA. Regalian US duty will be to reserve most of the remaining internet bandwidth to civil security information and economy protection. P2P, adult, etc. traffic will not be a priority. The DNS is the control tool. We do not want to suffer from that in Europe or in the rest of the world, because there is no reason and because it would propagate the terror (and make the attempt more attractive and therefore more likely). So an European regalian duty is DNS risk containment, to protect us from the results of an attack of the US and to protect the US from being attacked. This is a very common strategy in network security. This means that every Gov has a regalian duty, not to load the ICANN/NTIA file, but to copy it like ORSN does. This copying must be carried with a take-over procedure to cope with a special national situation. A critical problem may be local. Or there may be an external attack. Let for example consider the Iraq invasion and the ".iq" management. The USA attacked ".iq" through spam DoS and lead Iraq to stop all their servers. An Iraqi externet would have made the Iraqi machine to switch to the Iraqi root they could have build the way they wanted (this same externet reasoning applies to IPv6 addresses and national numbering zones we support and document for years and the ITU now openly investigates - please remember that ITU is not an "internet opponent" but the Rep of regalian concerns). A very common hypothesis is a "Tchernobyl" like incident. TV waves pollution will make ADSL screens the best way to inform and calm the people through stable screams, with a major user demand peak. The control of the DNS would be vital. Another interesting point is that published reports are that only 2.5% of the root calls are legitimate, addressing based externets are a way to protect users at peak critical times. Their support in IPv6 numbering plan is a regalian demand that we should see develop in the coming months. It is also a network security issue to avoid pollution of the DNS in such cases. Obviously this is not the only resulting user architectural changes implied by the ICANN ICP-3 and WSIS real world consequences, as some mails documented it about DNS database usages. jfc morfin

6 5

Re: [dns-wg] Re: ORSN-SERVERS.NET
by Jim Reid 28 Oct '04

28 Oct '04

>>>>> "JFC" == JFC (Jefsey) Morfin <jefsey(a)jefsey.com> writes: JFC> what ORSN does is risk containment. Suppose the ICANN/NTIA JFC> root is hacked. The ORSN file is not affected. This provides JFC> a protection. Could I please have some of whatever drugs you're taking? :-) IIUC this ORSN nonsense uses the root zone file as a starting point. So presumably any errors that get introduced there will be passed on to ORSN and its fellow travellers, no? JFC> Let imagine that a terrorist atomic bomb blows JFC> Washington-West (the top worldwide target and an US working JFC> hypothesis). The propagation through the internet would be JFC> times devastating than the bomb itself on the USA. First of all, I think most people would accept that any loss of life is far, far more devastating than the ability to route packets and make DNS lookups. Secondly, the root zone doesn't change much: TLDs renumber one of their servers now and again. Even if a major catastrophe destroyed the ability to change the root zone for a while -- I very much doubt that -- this would at worst be a minor inconvenience for TLD operators and the DNS in general. Good TLD managements will keep the old name servers running for at least a month or two after a renumbering. In fact a strong case can be made for NOT changing the root zone after such an event for stability reasons. Finally, suppose Something Bad has happened and the root can't be changed. Why would a TLD then choose to update their info in this bogus ORSN root while the info in the real root was unchanged? Wouldn't that lead to precisely the sort of inconsistency and network partitioning that the ORSN people claim they want to avoid?

2 1

Analysis of NSD
by Jim Reid 28 Oct '04

28 Oct '04

>>>>> "Stephane" == Stephane Bortzmeyer <bortzmeyer(a)nic.fr> writes: >> Well, for NSD, using large zones will cause it to eat memory >> exponentially. Stephane> Here is the NSD maintainer's analysis: Stephane> http://open.nlnetlabs.nl/pipermail/nsd-users/2004-October/000276.html While there is no reason to dispute the analysis from NSD's authors, I do think it would be nice if there was an independent analysis of NSD. And other DNS implementations for that matter. The work Brad did a couple of years ago was a step in that direction. I would also encourage operators to share their experiences of different name server implementations here: performance, protocol compliance, features, management & support issues, SLAs with hosting providers, etc, etc. Capturing and documenting this anecdotal information would be very useful.

5 9