[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'Jordyn A. Buchanan'" <jordyn@register.com>, Elmar Knipp <Elmar.Knipp@knipp.de>
Cc: Kent Crispin <kent@songbird.com>, ietf-provreg@cafax.se
From: "Larson, Matt" <mlarson@verisign.com>
Date: Fri, 6 Apr 2001 13:52:34 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Nameserver MUST HAVE IP

> However, if someone specifies the name server "ns3.knipp.de", and the 
> name server "ns3.knipp.de" does not exist within the .DE registry, 
> that's a problem.  You should be handing out glue records for name 
> servers within your TLD.

I don't think there's universal agreement on that.  As others have already
pointed out, storing and distributing A records that aren't required as glue
records can be confusing.  If I own foo.tld, and bar.tld (and only bar.tld)
uses name server ns3.foo.tld, I don't want that A record in the tld zone.
That record belongs to my zone and I want to be able to change it in only
one place.

If you're intent on providing a non-empty Additional section in referrals,
configure the TLD's name servers to fetch such A records from the
appropriate subzone and hand them out.  (That being said, it's a bad idea to
run in such a "glue fetching" configuration: it opens you up to a
cache-poisoning attack, since it causes the TLD name server that would not
otherwise initiate any queries to do so.)

> Taking your argument to an extreme, it's 
> possible to have a situation in which xxx.de has the name servers 
> ns1.yyy.de and ns2.yyy.de, with no IP address information.  yyy.de 
> could have the name servers ns1.xxx.de and ns2.xxx.de, with no IP 
> address information.  In that scenario, both xxx.de and yyy.de are 
> broken.

You're absolutely right, and you point out that this is not an easy problem
to solve.  I think you have to check for such circular references either at
registration time or zone generation/publication time.  You also have to
decide how big a circle you're willing to accommodate.

Before anyone points it out, I'm aware that what I'm preaching is different
from VGRS's current practice wrt com, net and org.  But we're certainly
aware of the issue and working to fix it.

Matt
--
Matt Larson <mlarson@verisign.com>
VeriSign Global Registry Services / www.verisign-grs.com

Home | Date list | Subject list