Need update on non-OSL-delegated DNS

We need whoever has access to the DNS at the registrar to do a few things. The domains drupalcon.org and drupal.be either should be delegated to the OSL nameservers or should have their A records pointed to 140.211.166.6 (the VIP for the load balancers). Also, while the domains are frozen, please add the name-server ns3.auth.osuosl.org for all the domains that are delegated.

Here was the mail thread, I thought turning it to an issue would be better.

On Jul 5, 2007, at 7:52 AM, Eric Searcy via RT wrote:

> On Jul 5, 2007, at 2:19 AM, Gerhard Killesreiter via RT wrote:
>
>> Hi there,
>>
>> there seemes to be a problem with the DNS for ftp.drupal.org.
>>
>> These problems seem to occur on occassion.
>>
>> It would be helpful to have a third DNS outside OSUOSL, I've been
>> told.
>> I will mail a contact address for somebody who is willign to host
>> this
>> in Europe to Eric.
>>
>> Cheers,
>> Gerhard
>
> Gerhard, Dries-
>
> We're welcome for the offer, but I've got a few things first ...
>
> We actually have a tertiary DNS server on the US east coast, which
> looks like it isn't being used for drupal.org/com. If you go to
>
> http://www.dnsstuff.com/tools/dnsreport.ch?domain=drupal.org
>
> There's some errors reported because our authoritative nameserver
> reported three nameservers, but one of them (ns3.auth.osuosl.org.) is
> not listed at the parent server. I believe Dries has access to
> change that at the registrar, could you add ns3 (216.165.191.53)?
>
> The second point is that we currently aren't serving up zone
> transfers at all yet, and to do so would require installing and
> setting up a new daemon on our DNS servers, afxrdns (we use tinydns,
> not BIND). We'd need to do a bit of work to make sure it interfaces
> right with our existing (rather complicated) DNS setup, so I'd rather
> not set that up if we can avoid it.
>
> The above stuff just referred to drupal.org. A zone transfer of the
> resource record for ftp.drupal.org would not solve the DNS issue
> (which, by the way, I did not realize was persisting, and which I
> have an easy fix for). This record is just a CNAME for
> ftp.osuosl.org, which is where the actually DNS problem must exist.
> This record has a rather complex setup, which is a CNAME that
> resolves to the alias ftp-i2.osuosl.org if the DNS request comes from
> a computer on the Abilene network, but resolves to ftp-ext.o.o if the
> addresses does not match a list of known I2 subnet masks. ftp-
> ext.o.o is a round-robin pointer to ftp-chi.osuosl.org and ftp-
> atl.osuosl.org, and this segment of the lookup is definitely
> working. So, my simple solution mentioned above is just to point
> ftp.drupal.org to ftp-ext.osuosl.org. After all, anyone downloading
> Drupal will not need the fast I2 speeds that are useful for
> downloading ISOs and the like. We'll look into why the ftp.o.o CNAME
> is having problems, I remember that the FTP admin recently expanded
> the I2 subnet mask list considerably, which may be the problem.
>
> A few more points about our zone while the subject is up:
>
> We're authoritative for these domains (all of which should have
> ns3.auth.o.o added):
>
> drupal.org
> drupal.com
> drupalcon.com
>
> Others are authoritative for these domains, even though they point at
> our servers:
>
> drupalcon.org. 6264 IN NS NS8.WORLDNIC.COM.
> drupal.be. 6459 IN NS NS77.WORLDNIC.COM.
>
> Actually, all of the RRs for these domains *are* set up on our
> authoritative servers (you can `dig @ns1.auth.osuosl.org drupal.be
> A', to test), so if these were delegated to ns[123].auth.o.o these
> domains would work without any more work needed.
>
> Lastly, Dries, if you choose to not redirect these domains to our
> auth. servers, we need some RRs updated to point at the VIP for the
> load balancer, instead of drupal2:
>
> Should be:
> drupal.be. 86400 IN A 140.211.166.6
> drupalcon.com. 86400 IN A 140.211.166.6
>
> --
> Eric Searcy
> OSU Open Source Lab