Subject: it appears that this whole "ask for AAAA before A" will be painful

From: Paul Vixie <[email-masked]>
Date: Sun, 08 Dec 2002 22:27:37 +0000

warning: this is another installment of my long running series of diatribe
against "stupid dns tricks" used by almost every form of load balancing
product or service i've ever seen.

-------- first let me show you who the nameservers are for "united.com"

;; ANSWER SECTION:
united.com.             2D IN NS        DC1LBS1.ULS-PROD.com.
united.com.             2D IN NS        DC2LBS1.ULS-PROD.com.

;; ADDITIONAL SECTION:
DC1LBS1.ULS-PROD.com.   2D IN A         64.95.89.4
DC2LBS1.ULS-PROD.com.   2D IN A         64.95.88.4

;; Total query time: 40 msec
;; FROM: ww.vix.com to SERVER: f.gtld-servers.com  192.35.51.30

-------- now let's ask it for the AAAA RR for www.united.com

;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;;      www.united.com, type = AAAA, class = IN

;; Total query time: 78 msec
;; FROM: ww.vix.com to SERVER: 64.95.89.4

-------- to show you that it's not AAAA prejudice, let's look for an RT RR:

;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;;      www.united.com, type = RT, class = IN

;; Total query time: 73 msec
;; FROM: ww.vix.com to SERVER: 64.95.89.4

-------- now let's let the load balancer do what it thinks its job is:

;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;;      www.united.com, type = A, class = IN

;; ANSWER SECTION:
www.united.com.         5S IN A         64.95.89.8

;; Total query time: 66 msec
;; FROM: ww.vix.com to SERVER: 64.95.89.4

--------

SERVFAIL is the wrong answer.  SERVFAIL is an indication, not that the type
isn't known, but that the zone is invalid at that server.  recursive servers
are within their rights to cache SERVFAIL at <ZONE,CLASS>, rather than at
<NAME,CLASS,TYPE>.  the proper answer to a AAAA or RT question, if there are
no RR's of that type at that name, is NOERROR/ANCOUNT=0.

do we need a BCP draft recommending that SERVFAIL be ignored, in case it came
from a load balancer?  or shall we call the load balancers faulty, and let
web sites like united.com be stranded in the new IPv6 era?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Peter Koch <[email-masked]>
Date: Mon, 09 Dec 2002 00:00:26 +0100

> -------- to show you that it's not AAAA prejudice, let's look for an RT RR:

Funny enough, try asking for "ANY" ...

> <NAME,CLASS,TYPE>.  the proper answer to a AAAA or RT question, if there are

And how do they know which zone it is that fails? www.United.COM may be in
a seperate zone below United.COM, so if you receive a SERVFAIL for queries
for www.United.COM you probably can't be sure what to cache anyway. In
addition, not even RFC 2308 defines this type of caching.

> no RR's of that type at that name, is NOERROR/ANCOUNT=0.

One might argue that NOTIMP would also be fine, at least until the "unknown
types" draft goes live. The "ANY" result would remain strange, though.

-Peter

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Dec 2002 23:30:43 -0000

Paul Vixie writes:
> let web sites like united.com be stranded in the new IPv6 era?

Wow. Do you think that IPv6 is some sort of unstoppable force that will
beat united.com into submission? Has it ever occurred to you that users
care a hell of a lot more about united.com than about IPv6? For further
comments, see http://cr.yp.to/djbdns/ipv6mess.html.

> SERVFAIL is an indication, not that the type isn't known, but that the
> zone is invalid at that server.

That's a wild oversimplification. SERVFAIL can indicate all sorts of
other problems.

> recursive servers are within their rights to cache SERVFAIL at <ZONE,CLASS>

That's absurd.

Similarly, it's silly for a client to abandon A records merely because
the AAAA-IPv6 connection attempt has failed. The A records are valid
whether or not AAAA records exist.

Obviously trying A first is better right now, although one can imagine a
future world where trying AAAA first is better.

None of this would ever have been an issue if people had used 16-byte A
records instead of inventing a completely unnecessary AAAA type.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Dec 2002 20:58:58 -0500

>>>>> "Paul" == Paul Vixie <[email-masked]> writes:
    Paul> SERVFAIL is the wrong answer.  SERVFAIL is an indication, not that the type
    Paul> isn't known, but that the zone is invalid at that server.  recursive servers
    Paul> are within their rights to cache SERVFAIL at <ZONE,CLASS>, rather than at
    Paul> <NAME,CLASS,TYPE>.  the proper answer to a AAAA or RT question, if there are
    Paul> no RR's of that type at that name, is NOERROR/ANCOUNT=0.

  Indeed.

    Paul> do we need a BCP draft recommending that SERVFAIL be ignored, in case it came
    Paul> from a load balancer?  or shall we call the load balancers faulty, and let
    Paul> web sites like united.com be stranded in the new IPv6 era?

  I expect that the first part was rhetorical? How could we tell if it was a
load balancer?

  This is something that places like rfc-ignorant.org should document.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Bill Manning <[email-masked]>
Date: Sun, 8 Dec 2002 20:25:36 -0800 (PST)

% do we need a BCP draft recommending that SERVFAIL be ignored, in case it came
% from a load balancer?  or shall we call the load balancers faulty, and let
% web sites like united.com be stranded in the new IPv6 era?
% 

	the distinction here is that IPv4 and IPv6 are different protocols,
	much like SNA and DECnet are different.  local optimizations
	e.g. load balancers designed for a subset of DNS capability under
	IPv4, should be recongnised as such when considering larger, 
	global usefulness.   
	
	while united.com may be a poor example, most sites (that will still
	be around) will adjust to adopt new techniques/technologies that 
	are able to bring value, be that IPv6, DNSSEC, IDN or any other 
	new feature that the DNS is asked to accomodate.

	my 0.02, don't accomodate such cruft. no bcp recommending SERVFAIL
	better would be a bcp pointing out the problems with minimialist,
	local optimizations.

--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 09 Dec 2002 14:12:23 +0900

>% web sites like united.com be stranded in the new IPv6 era?

	draft-itojun-jinmei-ipv6-issues-00.txt section 4.4 talks about the
	problem.  i'm not too sure how to make this document progress, but
	anyways, it's a start.  time for rfc1912bis?

itojun

---

From: Paul Vixie <[email-masked]>
Date: Mon, 09 Dec 2002 05:47:26 +0000

> 	... my 0.02, don't accomodate such cruft. ...

too late.

bind9's caching resolver already handled this condition by using lame servers
as a last resort once all non-lame servers had been tried.  this is bad for
the network, since it means more queries will be spewed into the ether during
actual lame-zone situations.  it also insulates the fools who wrote whatever
load balancer united.com uses from their deserved fate which is to go out of
business (quicker) and not inflict their sloppy implementations on the rest
of us.

however, as of tonight, bind8 does the same thing, following the robustness
principle.  what this looks like is that SERVFAIL is now a nonfunctional
encoding and that EDNS needs to enumerate the error conditions it was intended
to signal, and then we can all live in peace until the load balancer fools
learn about EDNS and decide to "implement" it.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 9 Dec 2002 09:49:57 -0500

>learn about EDNS and decide to "implement" it.

I agree with this.  SERVFAIL has popped up in DNSSEC workshops to 
indicate two different errors - one is when validation has failed and 
one when the authoritative server(s) is down.  What I've told 
students is:

When you do, say, "dig www.tld1.example a" and you get SERVFAIL, issue:
   "dig www.tld1.example a +norec" and then "dig www.tld1.example +cd".

If the answer to the first succeeds and the latter fails, the 
authority is not available.  If the answer to both succeed, then it's 
a DNSSEC validation failure.  If neither succeed, the problem is 
higher up the tree (like using the real root hints and not the 
workshop root hints).

 From an architectural viewpoint, a SERVFAIL may be generated because 
of an unsuccessful operation by the resolver element or the verifier 
element, if not from other elements too.  (I started looking at 
architectural elements over the weekend, and haven't finished yet. 
But this popped up quickly.)

...The problem isn't AAAA vs. A, or what will be driving folks to 
upgrade in the future, the problem is that we've over-overloaded DNS 
failure notices.  Another example is the referral "upward" which is 
interpreted as a lame server indication.  This "assumption" is 
causing a problem for the DS RR.

#define RANT
#ifdef RANT
One of the most overlooked elements of a system is error reporting. 
The main problem with BSD sockets lies here.  In the effort to make 
network access look like file system access (remember "file/device 
independence" - all the rage in the 80's?) sockets didn't account for 
reporting errors beyond what was done for the file system.  With 
little or no feedback, applications to this day suffer.  (Besides the 
bad code, there have been a lot of bad coding habits from this.)

I was going to give thoughts behind this, but after about a page of 
ranting about the old days and BSD sockets on VMS, I figured I was 
getting a bit off topic.
#endif

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer