I want to like IPv6. I do. But I'm seriously considering turning off IPv6 support from our servers.
First off, I'm using djbdns internally and it doesn't support AAAA records. So we really aren't using it internally.
But today I noticed that we have a lot of traffic to our DNS cache, and started to investigate. Turns out that every DNS request would start with one for the AAAA record. Ah, no luck. Maybe you forgot the search domain? Let's retry that DNS request with that tacked on. Failed again? Meanwhile, lets simultaneously try for the AA record then. Repeat.
I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me off this ledge?
You're describing normal behaviour. Why do you feel the behaviour you're seeing is a problem? Because you're not running IPv6, you're seeing twice the DNS traffic in some cases.
Doing multiple lookups for everything in search domain is done for IPv4 as well.
I want to like IPv6. I do. But I'm seriously considering turning off IPv6 support from our servers.
First off, I'm using djbdns internally and it doesn't support AAAA records. So we really aren't using it internally.
It sounds like this is a djbdns problem, not an IPv6 problem.
FWIW, DJB's public take on IPv6 can be found here: http://cr.yp.to/djbdns/ipv6mess.html . Judging by the lack of updates in the past 10 years (OK, 10 years next month), I'm not certain whether his position has changed. (Granted, some of the ten-year-old facts have, so who knows.) Personally, I didn't agree with his perspective at the time, and I feel it's only gotten less valid over time.
But today I noticed that we have a lot of traffic to our DNS cache, and started to investigate. Turns out that every DNS request would start with one for the AAAA record. Ah, no luck. Maybe you forgot the search domain? Let's retry that DNS request with that tacked on. Failed again? Meanwhile, lets simultaneously try for the AA record then. Repeat.
Are 2x the queries -- in exchange for future-proofing the network -- coming that close to overloading your DNS cache? You may want to re-evaluate the scalability of your cache.
Or replace your DNS cache with something maintained in the last decade (I thought I was exaggerating, but the last changelog in 1.05 is 20010211), and deploy all your internal assets on IPv6 -- thus reducing the query load AND getting your systems ready for the future.
I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me off this ledge?
Go right ahead. But first, what company is this, so the rest of us can know to avoid doing business?
I want to like IPv6. I do. But I'm seriously considering turning off
IPv6 support from our servers.
First off, I'm using djbdns internally and it doesn't support AAAA
records. So we really aren't using it internally.
djbdns doesn't support lots of things.
But today I noticed that we have a lot of traffic to our DNS cache, and
started to investigate. Turns out that every DNS request would start
with one for the AAAA record. Ah, no luck. Maybe you forgot the search
domain? Let's retry that DNS request with that tacked on. Failed again?
Meanwhile, lets simultaneously try for the AA record then. Repeat.
It looks like your getaddrinfo implementation is a searching for
AAAA records and then searching for A records. With a A record for
name2 you get a query path like this.
e.g. name1 AAAA -> NXDOMAIN
name2 AAAA -> NODATA
name3 AAAA -> NXDOMAIN
name1 A -> NXDOMAIN
name2 A -> DATA
You could ask you vendor to implement a alternating search strategy.
e.g. name1 AAAA -> NXDOMAIN
name1 A -> NXDOMAIN
name2 AAAA -> NODATA
name2 A -> DATA
Additionally you could get your vendor skip the A lookup on NXDOMAIN
from AAAA.
e.g. name1 AAAA -> NXDOMAIN
name2 AAAA -> NODATA
name2 A -> DATA
You will eventually have to turn it on again, so you may run away from
the problem that will catch you up anyway or, better, start tackling
the problems, like fixing djbdns or replacing it with something that
works.
++ on what everyone else has said about this being a problem with the way you run your DNS infrastructure, instead of an actual IPv6 problem.
Without reasons listed for why you use djbdns, I can't really adequately comment, but: on our net we're using unbound as caching DNS servers with pretty good success, and pdns with dynamic backends (the backends are custom in-house stuff) as our authoritative DNS. Short of issues now and then with the backends, it works pretty well.
In article <2801F5F8-B8E2-4A9F-9A89-02D7783CCDA7@josephholsten.com> you write:
I want to like IPv6. I do. But I'm seriously considering turning off
IPv6 support from our servers.
First off, I'm using djbdns internally and it doesn't support AAAA
records. So we really aren't using it internally.
I'm a long time djbdns user. But about a year ago, I switched from
using dnscache to unbound for my cache, because it does useful stuff
that dnscache doesn't do. I had a bunch of wacky local stuff
configured into dnscache, like querying local servers for local-only
domains, and substituting a local reject-all for some nasty outside
domains, and it took about an hour to figure out how to do it all with
unbound. I run it under daemontools.
My authoritative servers are still tinydns, even though I do support
IPv6. Since tinydns-data compiles stuff from a text source file, I
have a perl script that translates lines with AAAA records in a normal
format into the escape codes that tinydns uses for arbitrary record
types. It's gross, but it works.
So anyway, use unbound for your cache, no need to change away from
tinydns unless you want to use DNSSEC, which it'll never support.
I assume you mean stock djbdns doesn't support ip6, because it does
indeed support AAAA records. I use both dnscache and tinydns from
djbdns and AAAA records work fine for me. Note: I'm not using Felix von
Leitner's ip6 patch.
First off, I'm using djbdns internally and it doesn't support AAAA
records. So we really aren't using it internally.
if the clutch in my car is broken, should i stop using vehicles?
dump djbdns or get some diehard to tell you how to fix it.
Ah, but the clutch is not actually broken; it works perfectly, and
it is a very robust clutch, not likely to break, it's just that the
car was designed, so you need a wrench with you while at all times
while driving, to actuate the clutch, and you need a screwdriver
onhand as well to adjust gears. They have a raw record format,
that allows you to enter a raw record into your tinydns data file,
containing anything, including AAAA data.
However, djbdns also lacks support for DNSSEC validation. the stock
package 1.05, when installed on a 64-bit OS, contained an unpatched
security vulnerability.
The car was also designed with no electric ignition switch, and no
headlights. You want to start your car, you need a manual crank.
It's "good enough"; but probably the time comes soon to retire it.
Electronic ignitions and headlights became the 'standard' a long time
ago, but the car design was never improved to include the features
(not necessarily an easy feat) -- meanwhile, the person in
charge of maintaining the design; spent many hours writing essays
about the problem of light pollution caused by headlights,
insisting that road lights instead would be better, and calling up
issues about the extra weight and space required for batteries,
danger of batteries leaking, or failing, leaving motorists
stranded, etc,
thus spending time not updating the design to incorporate beneficial,
new standards.
>> First off, I'm using djbdns internally and it doesn't support AAAA
>> records. So we really aren't using it internally.
> if the clutch in my car is broken, should i stop using vehicles?
> dump djbdns or get some diehard to tell you how to fix it.
Ah, but the clutch is not actually broken; it works perfectly, and
it is a very robust clutch, not likely to break, it's just that the
car was designed, so you need a wrench with you while at all times
while driving, to actuate the clutch, and you need a screwdriver
onhand as well to adjust gears. They have a raw record format,
that allows you to enter a raw record into your tinydns data file,
containing anything, including AAAA data.
However, djbdns also lacks support for DNSSEC validation. the stock
package 1.05, when installed on a 64-bit OS, contained an unpatched
security vulnerability.
If Joseph really likes to use the TinyDNS database so much there is an experimental
PowerDNS backend of supposedly there is even an even more DNSSEC-patch somewhere.
I can't find the patch right now, but it was mentioned in a presentation by the
head developer at ICANN44:
I don't expect anyone is using patch in production right now.
The car was also designed with no electric ignition switch, and no
headlights. You want to start your car, you need a manual crank.
It's "good enough"; but probably the time comes soon to retire it.
Electronic ignitions and headlights became the 'standard' a long time
ago, but the car design was never improved to include the features
(not necessarily an easy feat) -- meanwhile, the person in
charge of maintaining the design; spent many hours writing essays
about the problem of light pollution caused by headlights,
insisting that road lights instead would be better, and calling up
issues about the extra weight and space required for batteries,
danger of batteries leaking, or failing, leaving motorists
stranded, etc,
thus spending time not updating the design to incorporate beneficial,
new standards.
No. djbdns 1.05 supports AAAA records as anyone can verify. To make
sure myself I just downloaded stock djbdns from the cr.yp.to website,
installed, and ran some aaaa queries. Works as it always has.
That's an unpatched, stock dnscache. John Levine already described in
this thread how tinydns supports AAAA records, so there's no point going
over it again.
I only responded to this thread to correct misinformation. sigh
As an aside, you may want to fix your DNS, as some mail receivers don't
like this:
What is really meant to be said is that MTA's which require RFC compliance won't talk to you. Running an MTA which requires minimal RFC compliance (particularly in respect of DNS configuration) eliminates 98% of spam.
Standards track RFC compliance REQUIRES that you ACCEPT email from that box.
There is no standards track RFC that requires that PTR records exist.
There is no standards track RFC that requires that PTR and address
records are consistent. It is however good practice that these exist and
are consistent.
