[ale] Running an IPv6 network: DNS

[Michael B. Trausch]

On Fri, 2011-01-21 at 17:30 -0500, Michael H. Warfield wrote:
> On Fri, 2011-01-21 at 11:25 -0500, Michael B. Trausch wrote: 
> > 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 is _quite_ a bit of an obnoxious ass.  The major reason that I setup
djbdns (this was quite some time back) was because of the fact that it
uses a single configuration file that is very, very easily generated by
very simple macros.  I use M4 macros to do things like generate all my
IPv6 records as generic records in djbdns, and they work well.

djbdns has had no official support for quite a long time.  It was placed
in the public domain, and I think it was abandoned by the author.
Debian has a project-local fork of djbdns that incorporates some of the
patches that can be found in the wild, but I don't think that there is
anyone truly maintaining the source code to it anymore.  I more or less
"set it and forget it", and when I need to change records for any one of
my domains, I modify the appropriate m4 file, run make, and then it's
out and up on the four DNS servers that I manage.

I _do_ like the POV of using rsync for replication as opposed to things
like AXFR, since then you don't need to worry about the DNS servers
talking to each other over the net with their own security mechanism.  I
have (perhaps too much) trust in OpenSSH and tend to prefer it for as
many things as possible.  The one advantage to that model is that you
never have the chance for three nameservers to go dark if the master is
taken out for a longer than expected period of time.  One such example
of that, which occurred recently:  We had several power outages that
wound up knocking my network offline entirely while we were out of town.
Had I been in town, everything would have been up and running and all
would have been well.  But since I was out of town, things just sat the
way they were.  The other two nameservers that are _not_ on my home
network were able to continue operations for the nearly two weeks that
my home network was down.

That reminds me, I need to find someone that is willing to bring my
network up if that ever happens again.  Normally it comes up on its own,
but apparently the pattern of outages combined with a woefully worn
battery on my UPS made sure that the system never fully came back up
after its crash, and some of the filesystems were slightly unhappy when
I got back...

> 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.

djbdns does not support IPv6 AAAA records natively, but it has a special
"generic record" format that is easily used to create any type of record
that the source code does not support directly.  I think that's a pretty
nifty feature, since DNS is far from a static standard that never moves
anywhere.  I seem to recall that back when I started using djbdns, there
were some issues with the then-current BIND release not supporting
something or another that I was able to implement with generic records
in djbdns (though to be fair, ISC said that the next release of BIND
would have the very thing I was looking for).

> His position on DNSSEC is pretty well known and his views are fairly
> controversial.

There is a lot about the man that I do not like.  His pages more-or-less
read like a suite of pages devoted to conspiracy theory.  :-|

> 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.

TSIG and DDNS are things that I have been looking back to ISC BIND for,
specifically in concert with Samba 4 and its Active Directory
implementation.

IPsec isn't terribly difficult to setup, either.  Currently, I'm relying
on it for interconnecting three physical RFC1918 IPv4 networks together
using routing over the tunnels in order to carry traffic back and forth,
and it works pretty well.  There is one odd issue with it that I haven't
sorted out, though in practice that issue does not hamper anything, it
just annoys me.  (If you're interested, I'll post about that in another
email.)

> > 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.

My usage of BIND was long enough ago, and it caused me so many
headaches, that I don't even remember what versions of it I had been
running at the time.

But, if you'll use BIND 9 without hesitation, then that's enough for me
to use it.

> > 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.

I very rarely find networks where reverse DNS lookup fails to function
correctly.  I know that there are about a million different ideas on
_how_ names should be populated in DNS for different types of networks,
and where the responsibility for them is (IIRC, most of them that I have
read are focused at providers identifying whether unnamed addresses are
static, dynamic, etc.).

That said, even on large intranets, reverse DNS works and usually
contains enough information to figure out where the address is located
on the network (e.g., for IP a.b.c.d you might get
d-c-b-a.atl.internal.company.com or something).

The thing with IPv6 is that there is no real way to figure out addresses
are _actually_ in use vs. those that _might_ be in use.  At least, not
if you use stateless autoconfiguration, which is precisely what I would
expect 99% of networks to be running.  I see no reason not to do things
that way.

> > 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.

I would only expect reverse looks to take place in response to network
activity, so it would be given that the address exists.  But also as you
mentioned last night, it's possible for a system to use randomly
generated addresses (the "security enhanced" IPv6 model) and this is
exactly what Windows systems do by default.  Some systems and networks
will fail to provide service if reverse DNS does not work.  I don't have
knowledge of systems that do this currently, but I have run into it in
the past both when transmitting email to a destination MX as well as
connecting to certain IRC networks (none of which I have frequented in
many years).

But some sort of a rule like, "If address X isn't in my explicit list,
just return {ADDR}.auto.example.com" or something like that would be
enough to satisfy (what I think is) reasonable expectations.

> > * 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.

I'm not sure how to do it with IPv4 either, other than perhaps
generating all your addresses, and feeding it to a script that generates
records for those and adds those records to the DNS system.  By your
repeated reference to wildcarding, I'm assuming that wildcarding must be
something different than what I am familiar with.  I am only familiar
with its usage in normal resolution requests, and only when the wildcard
is the only thing (e.g., is a "host" in a dedicated subdomain, which
would not work with reverse resolution on an IPv6 network unless I
decided to use one network number for stateless autoconfiguration and
the other for explicit configuration).

I do not want to do that, though, because I don't want to use two
network numbers when one will work just fine.  I want to use network
numbers to number networks, not identify administrative bounds on a
single network.

> > * 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?

A template for on-the-fly record generation.  Perhaps something more
concrete will demonstrate:

Let's say that I have the following hosts:

  2001:db8:0:1::1 - router.example.org
  2001:db8:0:1::2 - www.example.org
  2001:db8:0:1::3 - shell.example.org
  2001:db8:0:1::4 - files.example.org

Let's also say that there are numerous clients on that network, all
using stateless autoconfiguration.

I only want to put those four records in DNS and rDNS.  But all client
systems on the network will do things like SSH, or send email, or
whatever.  I want _those_ systems to, if they should be looked up in
rDNS, resolve to "<something>.autoconf.example.org" or
"<something>.client.example.org" or "<something>.dynamic.example.org".
Make sense?

> 
> > 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.

No, but I expect you probably know the well-known server addresses on
that /16... or maybe I am just insane because I essentially number hosts
to remember them so that I don't have to rely on something
like /etc/hosts or whatever.  Then again, I don't really use DNS on my
small intranets.

I don't know, nor do I care, about addresses for client systems unless I
have some need to know them, and when I do have a need to know them,
it's because I've seen them in a server log file.  Usually.

>   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.

I haven't yet played with DHCP on IPv6 yet, mostly because there is no
out-of-the-box support for it yet.  Hell, I'm not even sure if network
manager has finally been taught how to manage on an IPv6 network yet.
Haven't tried it.

What I do is I disable stateless autoconfiguration on server systems.
It's left enabled on all my client systems, but for servers I just setup
a static address and on the edge router I run radvd.

> > 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

Will check that out.

> > 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.

The only complete failures I've experienced have been my own fault.
Once I blew away my DNS server without remembering to backup its
directory, and I was severed from the Internet so I could not reach the
other DNS servers to look up the addresses of the other VMs on my
network.  Oops.  That's the one that I remember the best.

There was one other time that I forgot to tell the (at the time only)
backup DNS server on my second network to start when the system was
rebooted.  A power outage caused a reboot, and I did not have DNS
running on my own network.  So I was in a situation where the only two
systems running a DNS server were both not answering requests.  Again,
my fault.  Oops.

> 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).

I do recall what you said about HE's DNS hosting.  I didn't realize they
offered that, even though I've been using a tunnel from them for years
now.  I'm going to take a look at that this weekend as well, because I
would love to have my DNS mirrored that way.  I only manage 7 domains...

	--- Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110121/36d8160e/attachment-0001.bin