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

[6bone] Fwd: BCP 80, RFC 3681 on Delegation of E.F.F.3.IP6.ARPA


| > For people moving over in the next couple of weeks, one
| > can employ a DNAME, eg:
| That's a nice one indeed, yes.  But only if you have BIND9, correct?

Please note that RFC2672, introducing DNAME , is a proposed standard,
and not a draft standard; (quoting a mail from a customer of mine)

This discussion between him and I started when I introduced the ISC 
DNAME trick for ip6.int to ip6.arpa space. Here's a wrap-up:

1. This customer has an NS child delegation for their /48 from BIT, 
   his RRset consists of one of his bind boxes (open) and two of ours 
   (nsauth1 and nsauth3).

2. In my slave configuration for nsauth[13], I have put the /48 zone for
   both arpa and int. Thus I can answer authoritatively for the /48 in
   both arpa and int tree, from nsauth1 and nsauth3.

3. The /32 is delegated to nsauth[123] by my parent. 
4. I DNAME the whole /32 int to the /32 arpa and only carry the zone 
   information for arpa.

$Clueless-OS (RedHat) queries a PTR in the /48. It eventually gets to
the point where the /32 is served by nsauth[123]. If it then persues
nsauth1 or nsauth3, the nameservers respond authoritatively for the
ip6.int PTR. That's fine.

If the resolver happens to ask nsauth2, it answers DNAME and CNAME info
for the ip6.int to the ip6.arpa thing. The resolver does not understand
DNAME and (bug!) skips the whole query alltogether returning error to
the requesting program.

* If you use DNAME, you are creating a potentially harmful situation for 
  any children you have that you are also slaving for. This is not the
  fault of DNAME, nor bind. Blame the broken DNS implementation (of which
  there's bound to be plenty around!)
* I would seriously consider using an alternative if this is possible. 
  For example, bind also can load the same file in two zone definitions,
  as long as there is no ORIGIN to mess things up.

For my customer, I solved it by making nsauth2 a slave for his /48 also, 
this way it doesn't matter which nsauth* server is queried, they all
answer authoritatively for the zone.

I will continue running DNAME due to other (sitelocal) constraints.

---------- - -    - - -+- - -    - - ----------
Pim van Pelt                 Email: [email protected]
http://www.ipng.nl/             IPv6 Deployment