[ale] Running an IPv6 network: DNS

Michael H. Warfield mhw at WittsEnd.com
Fri Jan 21 17:30:14 EST 2011


On Fri, 2011-01-21 at 11:25 -0500, Michael B. Trausch wrote: 
> One thing that I did not think to ask about last night:  DNS on IPv6
> networks.  I expect that this is a topic that by itself could be a
> presentation, because there are many, many issues involved with it.

> For starters:  What is the preferred dæmon for use with IPv6?  I know
> that my personal favorite (djbdns) does not support anything having to
> do with IPv6 unless you fetch some patches from the Internet, and those
> patches are less than stellar in terms of their usability and
> robustness, so really the solution for djbdns is to either continue
> patching it up, or scrap it entirely.  Because I have less than no time
> on my hands, that's not really an option for me.

Quite frankly, I have several reasons I would avoid djbdns.  There have
been complaints about non-standard behavior in djbdns not conforming to
the RFCs over the years to which djb has taken his usual attitude that
he knows more about it than the IETF and the standards and ignored the
complaints.  He's also been bounced from the namedroppers mailing list
at times in the past for some of his behavior and postings.  In fact, I
haven't seen him posting up there in years.  From what I read up at
SixXs, djbdns will serve and handle queries for AAAA records but will
not transport over IPv6.  The fact that you have to patch it for IPv6
after all these years and at this late stage in the game, gives me
serious concerns for its support.  His position on DNSSEC is pretty well
known and his views are fairly controversial.  There are some pages up
by some of his supporters trying to "bebunk myths" about him and djbdns
and end up spend significant amount of space not debunking (all) the
myths but just defending his position that he's right and the IETF is
wrong.  Yes, they do legitimately debunk some of the myths for some
value of debunk.  But others just point to his statements about why he
won't and why he thinks his way is better.  He was pushing DNScurve
instead of DNSSEC (which OpenDNS has adopted but even they admit that
DNScurve will require adoption by the top level domains, which is not
happening).

There are other things which he just never implemented (and I have no
idea if there are patches for it or not) such as TSIG and Dynamic DNS.
He claims that IPsec is more secure than TSIG and that may well be true
but it doesn't change the fact that it is part of the approved standards
and I certainly wouldn't want to be setting up IPsec between all my name
servers and dhcp servers.

> I know that ISC BIND
> supports IPv6 (both records and connections), but it has such an awful
> past when it comes to security that I am hesitant to allow it on my
> network.

I think you're thinking of Bind 4.x which was a disaster and security
nightmare.  Bind 8.x was much better but of the same source providence.
It had some problems which were quickly addressed.  Bind 9 was a
complete rewrite under ISC and has had far fewer problems.  Paul and
company react to any problems in Bind very rapidly and don't try and
argue with you that their code is perfect and you're full of shit.  I
use it without hesitation and haven't had any problems.

> However, it supports other features that are useful (DNSSEC,
> various forms of dynamic updates, and so forth), so... should I start
> using that again?

I would.

> There are a few other issues that I can think of:

> * For an IPv4 network, it is conventional (and expected) to provide
>    reverse lookups for all addresses.

"Conventional and expected"?  Not in my experience.  You got a pointer
to a BCP that recommends it?  I wouldn't expect it.  I would expect it
for all addresses used.  The cases where I've seen it done that way is
in environments where they don't want to use dynamic zones with dynamic
addresses so they either provide dummy reverse lookups for all the
possible addresses or they provide a dummy wildcard for anything that's
not defined elsewhere in the zone.  The $GENERATE directive in Bind is
perfect for that sort of stuff if you want individual records.

> But in order to do this in an
>    IPv6 network would be impractical: the definitions for a single /64
>    alone would require 1,180,591,620,717,411,303,424 bits
>    (147,573,952,589,676,412,928 _bytes_, or exactly 128 EiB) of storage
>    (and that's before even considering the storage for the names).  So,
>    it seems that reverse lookups would have to be provided only for
>    known systems, and for the rest, the DNS server should be able to
>    apply a template of some sort.  Does BIND (or any other freely
>    available DNS software, for that matter) support this ability?

Wildcard or forget it.  Personally, I would just forget it.  I see no
reason for having a reverse lookup for an address that's not in use.
Even wildcards get sticky in there with v6 and I serious doubt it's
worth any effort.  If someone did actually query a lot of records from
your reverse lookup, each of those takes up a cache entry (it doesn't
know it's a wildcard) so you're back to your same problem, only on the
client side.  If you're concerned about covering all the active machines
with reverse lookups then you might want to go with stateful autconf
(dhcp6) and have that update the dns on the fly.

> * Likewise, generic names are expected for addresses that aren't used
>    for static things.  So some sort of template-driven, fallback name
>    should be available for hosts that aren't explicitly defined in the
>    zone, just like with reverse lookups.

Again.  Wildcard?  I'm not quite sure I understand your point here.
Where?  In the forward zones?  I don't see a problem or, at least, I'm
not sure what you are asking here where IPv6 is any different from IPv4.

> * How in the world would such a thing be replicated to slave DNS
>    servers?  I do not believe that there is any sort of method to
>    replicate anything but actual records in zone transfers and the like.

Again...  You've lost me on that question.  I don't understand what it
is you're asking.  What else is there but records that you are trying to
transfer?

> Another, related issue that has to do with something that was brought up
> last night: sequential numbering of IP addresses within an IPv6 network.
> I can understand precisely why sequential number is a bad thing from a
> network scanning perspective, but one of the major reasons to number
> sequentially (other than operating in the mindset of conservation and
> lack of significant address space available) is the ability for a human
> user to quickly remember addresses and conveniently manage them.

I don't remember all the IPv4 addresses on my /16.  AFA Dynamic
addresses go (which I understand djbdns doesn't even support), I let
dhcpd update dns with an update for both forward and reverse zones (I
keep my dynamic address in different zones for management purposes).  I
remember my /64 v6 prefixes just as easily as my /16 IPv4 network
address.  Individual machines?  No.  That's what cut-n-paste and files
are for.  The whole difficulty in remembering numbers is a red herring
and even occurred during the original development of IPv4 way back in
the early days.

> Should
> one just keep a list of MAC addresses and rely on stateless
> autoconfiguration for servers other than the network edge router?

I would.  Or use nsupdate to update your DNS on demand.  You might also
check out this package that manages MAC address to IPv6 DNS (forward and
reverse) mappings for EUI-64.

http://freshmeat.net/projects/ether2dns

> I
> suppose that would be one way of ensuring that the addresses for systems
> and the services running on them are well-known in the event of a
> complete failure of DNS...

If you get a complete failure of DNS (which is generally the complete
failure of the machine it's on or you screwed up the zone file and
didn't verify it first) then the first objective is to fix the DNS,
you've got bigger problems.  If you need that address to get to the DNS
to fix it, then you can always have some well known addresses in your
good old /etc/hosts file if you can't get to ANY of your name servers.
Maybe you've experienced more "complete failures of DNS" with djbdns
than I have with Bind.

On the rare occasion that it's happened, it's generally a self inflicted
injury where I typed something wrong (using a "#" for a comment in a
Bind zone file is classic) so I have to go fix it.  Generally if I'm on
the machine where I made the screwup, I can unscrew it up.  And that
only affects the master and not the slaves.  My v6 zones are all managed
by perl scripts anyways and I've never had this problem.

If you have enough authoritative name servers, this should never be a
problem.  You'll have the expiration in the slaves to cover you until
you fix a master and one or more slaves out are not going to kill you.
Remember what I said about Hurricane Electric?  Sign up and you can sign
up for their free DNS hosting for up to 50 domains.  That gives you 5
diverse name servers in addition to your own.  You can set them to slave
off of your master (or another one of your slaves).

whois wittsend.com
...
   NS1.HE.NET                   216.218.130.2
   NS2.HE.NET                   216.218.131.2
   NS3.HE.NET                   216.218.132.2
   NS4.HE.NET                   216.66.1.2
   NS5.HE.NET                   216.66.80.18
   NS2.WITTSEND.COM             130.205.32.4
   NS1.WITTSEND.COM             130.205.32.84

> 	--- Mike

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110121/c6546294/attachment-0001.bin 


More information about the Ale mailing list