Subject: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A record available

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Dec 2009 11:27:09 -0500

Hello,

Today I attended the interim meeting on WebEx over NAT64. I had only one
problem: a AAAA query for ciscosales.webex.com returns SERVFAIL, but an
A query is successful.

Now, section 5.1.2 prevents the DNS64 from synthesizing a record in this
situations.

What to do? Try an A query even when the AAAA query fails?

In my case, I just edited /etc/hosts... ;)

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Dec 2009 11:30:49 -0500

> problem: a AAAA query for ciscosales.webex.com returns SERVFAIL, but an

Do we know why it returned SERVFAIL?  Do all the servers return
SERVFAIL?  I'm trying to understand whether there is a good reason
(well, a good operational reason) we'd want to address this, or
whether it's actual breakage we need not to fix.  (For it seems to me
this is already so broken that we maybe ought not to try to fix it.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Dec 2009 11:59:53 -0500

> SERVFAIL?  I'm trying to understand whether there is a good reason

Hmm, curiouser.  When I query those nameservers for AAAA for
ciscosales.webex.com, I don't get SERVFAIL.  I get REFUSED.  Is your
DSN64 returning SERVFAIL when it gets REFUSED?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Dec 2009 18:04:26 +0100

> DSN64 returning SERVFAIL when it gets REFUSED?

Not unreasonable. The server failed because it was refused the info it needs.

Note that google public dns does "refused" for RFC 1918 space which really slows down my traceroutes. But that's for another list.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Dec 2009 12:17:01 -0500

> Not unreasonable. The server failed because it was refused the info it needs.

Hrm.  I'd normally expect a recursive server (which is what step 1 of
the DNS64 processing is) just to pass on the REFUSED.  It strikes me
that we might want to think about the chances that many servers out
there are configured to REFUSE AAAA queries.  I have no idea what the
population of v4-only servers REFUSEing AAAA queries might be.  If
someone actually has numbers, it'd be good; otherwise I'll go see what
I can scare up.

> Note that google public dns does "refused" for RFC 1918 space which
> really slows down my traceroutes. But that's for another list.

In my not-a-little-bit-humble-on-this opinion, they're doing a totally
reasonable thing, and if more people had done that ages ago we
wouldn't have needed the AS112 project.  (But yes, this is the wrong
list.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Dec 2009 12:54:10 -0500

> DSN64 returning SERVFAIL when it gets REFUSED?

This seems to be normal Bind behaviour. Both normal Bind and my DNS64-Bind
return SERVFAIL when they get REFUSED.

But this is largely irrelevant from a DNS64 protocol point of view.

Why wouldn't we want to try an A query when the AAAA query fails?

The failure could be due to a multitude of valid reasons, not just
misconfiguration or misbehaving. For example, the AAAA record might be sitting
on a failed disk partition while the A record is OK. Yes this is far-fetched,
but it is just an example. The point is that you can't assume anything about the
availability of the A records when the AAAA query fails (or is refused, or
whatever else).

Simon

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Dec 2009 13:38:51 -0500

> return SERVFAIL when they get REFUSED.

Interesting.  Well, I can see the justification for either answer for
an iterative mode resolver, so it's not wrong.  It _feels_ wrong to
me, but intuition is a lousy guide to correctness in these tricky
cases, I'd say, and as someone already observed "SERVFAIL" is a
coherent response for the server part of the recursive server.

> availability of the A records when the AAAA query fails (or is refused, or

But we're trying to solve _just one_ problem: that you can't get to a
host that doesn't have AAAA, but that does have A at the same owner
name.  We're not trying to make IPv6 connectivity work whenever some
bozo's DNS servers are broken, misconfigured, hiding behind a
misconfigured and packet mangling firewall, or any of these other
things.  If we take on the scope, "Fix broken DNS when querying for
AAAA," we will spend until the heat death of the universe nailing down
all the ways this could be wrong.

In this particular case, REFUSED means "go away".  If the point of the
REFUSED response code was to say, "We don't do AAAA," then I submit
the server is broken.  We have a perfectly good response code for
that: RCODE 4, NOTIMP.  

I am, however, susceptible to the argument that we ought to try an A
query in the event of RCODE 4 on the AAAA query.  What do people
think?

By the way, despite my resistance to querying for A no matter what the
non-positive answer is (since I think that will just drive up
error-encumbered traffic), this is an incredibly valuable bit of
feedback, and I really appreciate it.  Thank you very much

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Dec 2009 19:51:46 +0100

> query in the event of RCODE 4 on the AAAA query.  What do people

Ok, let me take a crack at this.

Basically, the tradeoff is one between being pedantic and getting a working result out of as many broken configurations as possible. Both are admirable goals.  :-)

There is a reason to not be overly pedantic: we want people to adopt IPv6, and we want people to adopt NAT64. So we don't want to break stuff that works with IPv4, and we don't want to break stuff that works with regular IPv6.

With normal dual stack, the client has the option of asking for an A record if it can't get an AAAA record. One good way to avoid issues like this is ask for the A record first and then for the AAAA record. If the server then chokes on the AAAA query we have the A answer so everything works for dual stack hosts.

We could do that with DNS64, too.

I'm not sure we want to go that far.

Just being persistant and request an A record whenever we don't get an AAAA answer for any (?) reason (timeout, SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a reasonable tradeoff. However, that would be a slight departure from the current draft.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Dec 2009 14:29:13 -0500

On Wed, Dec 16, 2009 at 07:51:46PM +0100, Iljitsch van Beijnum wrote:

> With normal dual stack, the client has the option of asking for an A
> record if it can't get an AAAA record. One good way to avoid issues
> like this is ask for the A record first and then for the AAAA
> record. If the server then chokes on the AAAA query we have the A
> answer so everything works for dual stack hosts.
> 

Except that it's backwards to what we want.  The people behind a NAT64
should use the NAT64 as a last resort, preferring v6 connectivity as
much as possible.  So we want them to ask AAAA first, I think?

> 
> Just being persistant and request an A record whenever we don't get
> an AAAA answer for any (?) reason (timeout, SERVFAIL, NOTIMP,
> REFUSED) other than NXDOMAIN seems like a reasonable
> tradeoff. However, that would be a slight departure from the current
> draft. 

The worry I have there is that this more or less mandates an increase
in traffic which, for most of those cases, ought to produce exactly
the same result.  REFUSED is very commonly encountered when you query
a recursor for which you're not authorized, for instance.  SERVFAIL is
a good indication that the server is encountering an error, and it's
not plain to me we want to encourage implementations to pound away on
a server that's already indicated it has a problem.  &c.  RCODE=4 I
get, but the rest of them just seem to me like the server telling you
that there's an error.  Why shouldn't that get returned to the client?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Dec 2009 14:44:58 -0500

Andrew Sullivan wrote:
> the same result.

You already get that with dual-stack. Why should NAT64 be any gentler?

Simon

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Dec 2009 15:46:20 -0500

> You already get that with dual-stack. Why should NAT64 be any gentler?

Hrm.  Well, ok, I get that point.  OTOH, this has been the way we've
been promoting it, so we'll have to call this change out to the DNS
community too (it's their servers that will take the load.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Dec 2009 08:28:26 +1100

In message <[email-masked]>, Andrew Sullivan writes:
> the DNS64 processing is) just to pass on the REFUSED.

It's not worth the effort to track to see if you get REFUSED from all the
server.

> It strikes me
> there are configured to REFUSE AAAA queries.

> I have no idea what the

Very small, about the same number that return NXDOMAIN or A records or
other garbage.

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Dec 2009 21:30:52 -0800

Iljitsch van Beijnum wrote:

> Just being persistant and request an A record whenever we 
> don't get an AAAA answer for any (?) reason (timeout, 
> SERVFAIL, NOTIMP, REFUSED) other than NXDOMAIN seems like a 
> reasonable tradeoff. However, that would be a slight 
> departure from the current draft.

Optimizing for NXDOMAIN is tempting, but it means DNS64
would be ineffective for many websites, including popular
ones.  I checked the top 5000 websites (according to Alexa, 
see http://www.alexa.com/topsites) to see how they handle 
AAAA queries.

Of those 5000, their nameservers returned:

  NOERROR, 4766 (95.3%) 
  NXDOMAIN, 37 (0.74%)
  REFUSED, 18 (0.36%)
  SERVFAIL, 23 (0.46%)

There is some inconsistency because my script is simplistic
(the results don't add up to 5000), but I was mostly intending
to get a feel for real numbers that would affect DNS64 if
DNS64 did not provide effective service to an NXDOMAIN 
response.

Below, I summarized the domains that returned errors when 
queried for AAAA.

The command I used for the test was:
  dig +short DOMAINNAME ns | xargs -t -n 1 -I J 
             dig @J aaaa www.DOMAINNAME | grep status
and the log file is at 
ftp://ftpeng.cisco.com/dwing/behave/aaaa-responses-top-5000.txt

-d

-----

NXDOMAIN:
www.1e100.net
www.uimserv.net
www.yimg.com
www.rmxads.com
www.ggpht.com
www.edgesuite.net
www.webry.info
www.images-amazon.com
www.pgmediaserve.com
www.livefilestore.com
www.googlesyndication.com
www.ytimg.com
www.myfiles-express.com
www.myspacecdn.com
www.fbgdc.com
www.say-move.org
www.www.ne.jp
www.ucom.ne.jp
www.xtshare.com
www.nocookie.net
www.bingj.com
www.k12.ca.us
www.wateen.net
www.2mdn.net
www.kvors.com
www.yahoofs.jp
www.ecshop.com
www.xii.jp
www.ebayrtm.com
www.atwola.com
www.twimg.com
www.www.gov.cn
www.movie-japan.com
www.mofile.com
www.donetsk.ua
www.gnspf.com
www.bannch.jp

REFUSED:
www.ehow.com
www.sanspo.com
www.cracked.com
www.nbc.com
www.answerbag.com
www.mozilla-europe.org
www.hindustantimes.com
www.treehugger.com
www.blogsome.com
www.gamershell.com
www.rotoworld.com
www.books.com.tw
www.nbcsports.com
www.livestrong.com
www.longporntube.com
www.airliners.net
www.essortment.com
www.greenpeace.org

SERVFAIL:
www.livejasmin.com
www.ynet.com
www.awempire.com
www.ikea.com
www.hc360.com
www.vnet.cn
www.bramjnet.com
www.miibeian.gov.cn
www.startpagina.nl
www.sznews.com
www.yingjiesheng.com
www.rueducommerce.fr
www.shortnews.de
www.heavy.com
www.penny-arcade.com
www.nouvelobs.com
www.eventim.de
www.cdcovers.cc
www.soccerway.com
www.pathfinder.gr
www.gazetaesportiva.net
www.5giay.vn
www.ratp.info

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Dec 2009 17:01:48 +1100

> Of those 5000, their nameservers returned:

Which is correct according to RRF 1034.

>   SERVFAIL, 23 (0.46%)

Which are usually the result of crappy/misconfigured load balancers.

If you look at things other than www.* you get much higher success
rates because general purpose nameservers know how to answer AAAA
queries.

> DNS64 did not provide effective service to an NXDOMAIN 

http://www.alexa.com/topsites is a very biased sample.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Dec 2009 22:15:51 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, December 16, 2009 10:02 PM
> To: Dan Wing
> Cc: 'Iljitsch van Beijnum'; 'Andrew Sullivan'; [email-masked]
> Subject: Re: [BEHAVE] DNS64: SERVFAIL on AAAA query, but A 
> record available 
> 
> 

The world is long trained to type "www".

> http://www.alexa.com/topsites is a very biased sample.

I expect a similar list of different top-NNN sites would 
yield similar results.  Is my expectation unfounded?

-d

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Dec 2009 18:11:19 +1100

> yield similar results.  Is my expectation unfounded?

http://www.alexa.com/topsites has a very high percentage of load
balancers.  Much higher that www.* sites in general and much higher
than non www.* sites.  There are a lot of load balancers vendors
that paid no attention to how to answer non A queries correctly.
There at lots of sites that don't bother to correct the problem
even after it is reported to them.

Note the numbers of bad load balancers are going down.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Dec 2009 21:17:30 +1100

Also most of the servfails arn't.

> > > www.livejasmin.com

works

> > > www.ynet.com

works

> > > www.awempire.com

works

> > > www.ikea.com

works

> > > www.hc360.com

broken, referral to self.

gslb.hc360.com.         3600    IN      NS      shdns.hc360.com.cn.
gslb.hc360.com.         3600    IN      NS      bjdns.hc360.com.cn.
;; Received 88 bytes from 203.134.246.111#53(ns1.hc360.com) in 421 ms

gslb.hc360.com.         669     IN      NS      bjdns.hc360.com.cn.
gslb.hc360.com.         669     IN      NS      shdns.hc360.com.cn.
;; Received 120 bytes from 203.134.246.9#53(bjdns.hc360.com.cn) in 429 ms

> > > www.vnet.cn

works

> > > www.bramjnet.com

works 

> > > www.miibeian.gov.cn

works

> > > www.startpagina.nl

works

> > > www.sznews.com

broken, root referral.

> > > www.yingjiesheng.com

works

> > > www.rueducommerce.fr

works

> > > www.shortnews.de

works

> > > www.heavy.com

works

> > > www.penny-arcade.com

works

> > > www.nouvelobs.com

works 

> > > www.eventim.de

works

> > > www.cdcovers.cc

works 

> > > www.soccerway.com

works

> > > www.pathfinder.gr

broken, misconfigured load balance, wrong backing zone.

www.pathfinder.gr.      10800   IN      NS      lpsb.phaistosnetworks.gr.
www.pathfinder.gr.      10800   IN      NS      lptb.phaistosnetworks.gr.
www.pathfinder.gr.      10800   IN      NS      lp.phaistosnetworks.gr.
;; Received 155 bytes from 94.136.45.31#53(dnsuk.phaistosnetworks.gr) in 1008 ms

pathfinder.gr.          86400   IN      SOA     pathfinder.gr. administrator.pathfinder.gr. 998545544 28800 7200 604800 86400

;; Received 124 bytes from 194.0.185.253#53(lptb.phaistosnetworks.gr) in 410 ms

> > > www.gazetaesportiva.net

works

> > > www.5giay.vn

works

> > > www.ratp.info

works

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 17 Dec 2009 12:39:27 +0100

> would be ineffective for many websites,

Well, AFAIK with things like REFUSED and SERVFAIL you can argue that this result is particular to the AAAA query and the A query may give a different result. With NXDOMAIN the answer authoritatively states that the domain doesn't exist, so the only way the A query can produce a different answer is if someone is completely breaking the specifications.

If the DNS64 is doing recursive queries itself it SHOULD never encounter REFUSED, because then there would be a break in the delegation chain, so I'm not worried about generating a few more queries in that case. If there is a resolver in the middle it could be that the resolver doesn't want to resolve for the DNS64, but in that case the whole setup doesn't work so the users will give up and again, a few extra packets is not an issue.

Not sure where SERVFAIL would come from in the authoritative case, but in the resolver case it can obviously result from a REFUSED authoritative response so again no problem querying for an A record.

However, the NXDOMAIN case will normally be the result of a query for a non-existant domain. If there is a large amount of such queries doubling it is not a good idea.

People configuring their DNS server to send out REFUSED for AAAA queries is something that I can kinda-sorta-but-not-really follow, but NXDOMAIN when there is in fact an A record is just plain wrong on every level so generating lots of extra queries when there is NXDOMAIN for AAAA or by always doing A first even when we don't need the A record is probably a bridge too far for the IETF to mandate.

>  SERVFAIL, 23 (0.46%)

What about the remaining 156? Timeout? (For instance, one on Mark's list that I tried replied in 4800 ms for me...)

Would be interesting to see the results for A. As we saw in the FTP case, there is always a percent or two that just don't do anything reasonable. (Although with top 5000 popular sites this is probably better than an old list of FTP sites.)

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 Dec 2009 09:17:32 -0500

On Thu, Dec 17, 2009 at 12:39:27PM +0100, Iljitsch van Beijnum wrote:
> 
> Well, AFAIK with things like REFUSED and SERVFAIL you can argue that
> this result is particular to the AAAA query and the A query may give
> a different result. With NXDOMAIN the answer authoritatively states
> that the domain doesn't exist, so the only way the A query can
> produce a different answer is if someone is completely breaking the
> specifications.

Completely agree.  So the real question is how dual-stack handles
this.  We're trying to do something not quite as good as dual stack,
but with a minimum of user surprise.  

I confess that what clients really do is above the layer where I
really know what I'm talking about (ok, ok, many will say there _is_
no such layer.  But let's pretend).  Here's my naive belief about what
dual-stack hosts do.  They query AAAA first.  If they get NXDOMAIN,
they treat that as a failure at the name and give up.  If they get
another error then [ . . . ].  If they get noerror with an empty
answer they query for A.

The above has been my model so far, where the ellipsis was "they
return the error".  People seem to be suggesting I'm wrong about
that.  So what happens?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Dec 2009 09:32:20 -0800

> Sent: Thursday, December 17, 2009 2:18 AM
> To: Dan Wing
> Cc: 'Andrew Sullivan'; [email-masked]

Not for me.  Pray tell, what I am doing wrong.

> dig +short livejasmin.com ns
ns1.lalibco.com.
ns2.lalibco.com.
> dig @ns1.lalibco.com aaaa www.livejasmin.com

; <<>> DiG 9.6.1-P1 <<>> @ns1.lalibco.com aaaa www.livejasmin.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15506
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.livejasmin.com.            IN      AAAA

;; AUTHORITY SECTION:
livejasmin.com.         14400   IN      SOA     ns1.lalibco.com.
hostmaster.lalibco.com. 2009111003 28800 7200 604800 14400

;; Query time: 8 msec
;; SERVER: 93.93.50.1#53(93.93.50.1)
;; WHEN: Thu Dec 17 09:31:16 2009
;; MSG SIZE  rcvd: 95

> dig @ns2.lalibco.com aaaa www.livejasmin.com

; <<>> DiG 9.6.1-P1 <<>> @ns2.lalibco.com aaaa www.livejasmin.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30271
<<<<<<<<<<<<<<<<<<<<<<<<
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.livejasmin.com.            IN      AAAA

;; Query time: 8 msec
;; SERVER: 93.93.51.1#53(93.93.51.1)
;; WHEN: Thu Dec 17 09:31:20 2009
;; MSG SIZE  rcvd: 36

-d

> ;; Received 120 bytes from 
> 203.134.246.9#53(bjdns.hc360.com.cn) in 429 ms
> 
> > > > www.vnet.cn
> 
> works
> 
> > > > www.bramjnet.com
> 
> works 
> 
> > > > www.miibeian.gov.cn
> 
> works
> 
> > > > www.startpagina.nl
> 
> works
> 
> > > > www.sznews.com
> 
> broken, root referral.
> 
> > > > www.yingjiesheng.com
> 
> works
> 
> > > > www.rueducommerce.fr
> 
> works
> 
> > > > www.shortnews.de
> 
> works
> 
> > > > www.heavy.com
> 
> works
> 
> > > > www.penny-arcade.com
> 
> works
> 
> > > > www.nouvelobs.com
> 
> works 
> 
> > > > www.eventim.de
> 
> works
> 
> > > > www.cdcovers.cc
> 
> works 
> 
> > > > www.soccerway.com
> 
> works
> 
> > > > www.pathfinder.gr
> 
> ;; Received 155 bytes from 
> 94.136.45.31#53(dnsuk.phaistosnetworks.gr) in 1008 ms
> 
> pathfinder.gr.          86400   IN      SOA     
> pathfinder.gr. administrator.pathfinder.gr. 998545544 28800 
> 7200 604800 86400
> 
> ;; Received 124 bytes from 
> 194.0.185.253#53(lptb.phaistosnetworks.gr) in 410 ms
> 
> > > > www.gazetaesportiva.net
> 
> works
> 
> > > > www.5giay.vn
> 
> works
> 
> > > > www.ratp.info
> 
> works
> -- 
> Mark Andrews, ISC

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Dec 2009 09:39:34 -0800

> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Thursday, December 17, 2009 3:39 AM
> To: Dan Wing
> Well, AFAIK with things like REFUSED and SERVFAIL you can 
> argue that this result is particular to the AAAA query and 
> the A query may give a different result. With NXDOMAIN the 
> answer authoritatively states that the domain doesn't exist, 
> so the only way the A query can produce a different answer is 
> if someone is completely breaking the specifications.
>
> If the DNS64 is doing recursive queries itself it SHOULD 
> never encounter REFUSED, because then there would be a break 
> in the delegation chain, so I'm not worried about generating 
> a few more queries in that case. If there is a resolver in 
> the middle it could be that the resolver doesn't want to 
> resolve for the DNS64, but in that case the whole setup 
> doesn't work so the users will give up and again, a few extra 
> packets is not an issue.
> 
> Not sure where SERVFAIL would come from in the authoritative 
> case, but in the resolver case it can obviously result from a 
> REFUSED authoritative response so again no problem querying 
> for an A record.
> 
> However, the NXDOMAIN case will normally be the result of a 
> query for a non-existant domain. If there is a large amount 
> of such queries doubling it is not a good idea.
> 
> People configuring their DNS server to send out REFUSED for 
> AAAA queries is something that I can 
> kinda-sorta-but-not-really follow, but NXDOMAIN when there is 
> in fact an A record is just plain wrong on every level so 
> generating lots of extra queries when there is NXDOMAIN for 
> AAAA or by always doing A first even when we don't need the A 
> record is probably a bridge too far for the IETF to mandate.

How do dual-stacked Windows and OSX, with their built-in telnet 
and with various common web browsers (Firefox, IE, Safari, Opera,
Chrome) behave when they get a SERVFAIL in response to an AAAA
query?  I bet a beer they try an A.

Does anyone know?

> What about the remaining 156? Timeout? (For instance, one on 
> Mark's list that I tried replied in 4800 ms for me...)
> 
> Would be interesting to see the results for A. As we saw in 
> the FTP case, there is always a percent or two that just 
> don't do anything reasonable. (Although with top 5000 popular 
> sites this is probably better than an old list of FTP sites.)

Yes, A records fail, too.  When I run my weekly test of the
top 25000 web hosts (using Alexa's list), I get a 0.9% failure
rate to get an A record.  For that test, my program calls
getaddrinfo() and times out or gets an error.

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 17 Dec 2009 18:56:28 +0100

> Does anyone know?

I did some quick tests with strange results. It seems that one ingredient here is whether there is a CNAME involved. Haven't had time to figure it out conclusively. (Doesn't help that the new MacOS has a bug with AAAA records and CNAMEs.)

Two points:

1. Applications very rarely do their own DNS lookups, this is all piped through the system APIs which use all kinds of black magic to resolve stuff from hosts.txt, WINS, yellow pages, you name it. And oh yes, the DNS.

2. I think we mostly agree that doing an A query after a SERVFAIL for AAAA is reasonable, the problem is NXDOMAIN.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Dec 2009 10:21:09 -0800

> Sent: Thursday, December 17, 2009 9:56 AM
> To: Dan Wing
> I did some quick tests with strange results. It seems that 
> one ingredient here is whether there is a CNAME involved. 
> Haven't had time to figure it out conclusively. (Doesn't help 
> that the new MacOS has a bug with AAAA records and CNAMEs.)
> 
> Two points:
> 
> 1. Applications very rarely do their own DNS lookups, this is 
> all piped through the system APIs which use all kinds of 
> black magic to resolve stuff from hosts.txt, WINS, yellow 
> pages, you name it. And oh yes, the DNS.

And some applications call getaddrinfo() and trust the right
thing will occur, and others call it twice (once asking for
IPv4 addresses, again for IPv6) and apply their own 
preference/priority logic to the results.

> 2. I think we mostly agree that doing an A query after a 
> SERVFAIL for AAAA is reasonable, the problem is NXDOMAIN.

Yes, the problem is deciding if we want to optimize 
NXDOMAIN versus risk some domains being inaccessible
to IPv6-only hosts using a DNS64.

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 17 Dec 2009 13:32:26 -0500

> www.googlesyndication.com

All these also return NXDOMAIN for the A query.

> www.ecshop.com

This one doesn't return NXDOMAIN for either A or AAAA, at least for me.

Therefore, I think we should not try an A query when the AAAA query returns
NXDOMAIN. But we should on any other error.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 17 Dec 2009 13:37:07 -0500

> to IPv6-only hosts using a DNS64.

I think this is backwards.

NXDOMAIN means that the domain doesn't exist. So the "right" thing to do is to
infer that the A query would also return NXDOMAIN, and not try it.

The optimization would be to accommodate broken servers by also trying an A
query. From my other post, I think this is not necessary since no domain in the
Alexa top 5000 for which the AAAA query returns NXDOMAIN doesn't also return
NXDOMAIN for the A query.

Simon

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Dec 2009 08:08:32 +1100

> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30271

The server is just lame.  www.livejasmin.com is up however as the
other server is answering correctly for both A and AAAA.

Mark

; <<>> DiG 9.3.6-P1 <<>> @ns2.lalibco.com a www.livejasmin.com +norec
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24128
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.livejasmin.com.		IN	A

;; Query time: 171 msec
;; SERVER: 93.93.51.1#53(93.93.51.1)
;; WHEN: Fri Dec 18 08:06:57 2009
;; MSG SIZE  rcvd: 36

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Dec 2009 19:28:19 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Thursday, December 17, 2009 10:32 AM
> To: [email-masked]

You're right.  Thanks for checking that!

-d

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 Dec 2009 22:33:48 -0500

> 2. I think we mostly agree that doing an A query after a SERVFAIL for AAAA is reasonable, the problem is NXDOMAIN.

Yes.  I am currently editing (at this very moment) the -04 draft and
it is going to say this.  It is a replacement for §5.1.2:

5.1.2.  The answer when there is an error

   If the query results in a response with RCODE other than 0, then
   there are two possibilities.  A result with RCODE=3 is handled
   according to normal DNS operation (which is normally to return the
   error to the client).  This stage is still prior to any synthesis
   having happened, so a response to be returned to the client does
   not need any special assembly than would usually happen in DNS
   operation.

   Any other RCODE is treated as though the RCODE were 0 and the
   answer section were empty.  This is because of the large number of
   different responses from deployed name servers when they receive
   AAAA queries without a AAAA record being available.

   It is important to note that, as of this writing, some servers
   respond with RCODE=3 to a AAAA query even if there is an A record
   available for that owner name.  Those servers are in clear
   violation of the meaning of RCODE 3, and it is expected that they
   will decline in use as IPv6 deployment increases.

If you don't like this or have some suggested alternative text, it
would be welcome; but please hurry.

A
 
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: liu dapeng <[email-masked]>
Date: Sun, 20 Dec 2009 12:50:30 +0800

Hi Simon,

SERVFAIL means "The name server was unable to process this query due
to a problem with the name server (RFC1035)" . I tried to query
type=AAAA for ciscosales.webex.com using my laptop and using Wireshark
to capture the packet then verify that it indeed returns a response
which has the RCODE set to 2 (server failure). That excludes that this
is caused by your DNS64 implementation. Regarding to how to fix this,
I do not know if the DNS64 simply also to query A record when querying
AAAA fails will cause any other potential problems?

Best wishes,
Dapeng Liu

---

From: liu dapeng <[email-masked]>
Date: Sun, 20 Dec 2009 12:53:16 +0800

Hi Andrew:

I get Server failure when try to query AAAA for ciscosales.webex.com.
Do you set the query type to AAAA to your resolver?

Best wishes,
Dapeng Liu

---

From: liu dapeng <[email-masked]>
Date: Sun, 20 Dec 2009 13:01:16 +0800

Hi Andrew,

> query in the event of RCODE 4 on the AAAA query.  What do people

Only when the DNS server which does not has AAAA record and when
response to AAAA query it will sets RCODE=4 to the response packet
will make this approach more suitable, right? but is that the common
practice?

Best wishes,
Dapeng Liu

---

From: liu dapeng <[email-masked]>
Date: Sun, 20 Dec 2009 13:26:53 +0800

Hi Dan,

I query AAAA for www.ecshop.com could success, the RCODE is 0 (no
error). And the response is a CNAME. I am wondering why your
experiment result is NXDOMAIN, what caused this unconsistency (other
results are the same)? I use nslookup for query and set the query type
to AAAA.

Best wishes,
Dapeng Liu

---

From: liu dapeng <[email-masked]>
Date: Sun, 20 Dec 2009 13:59:05 +0800

2009/12/17, Iljitsch van Beijnum <[email-masked]>:
> Well, AFAIK with things like REFUSED and SERVFAIL you can argue that this
> result is particular to the AAAA query and the A query may give a different
> result. With NXDOMAIN the answer authoritatively states that the domain
> doesn't exist, so the only way the A query can produce a different answer is
> If the DNS64 is doing recursive queries itself it SHOULD never encounter
> REFUSED, because then there would be a break in the delegation chain, so I'm
> not worried about generating a few more queries in that case. If there is a
> resolver in the middle it could be that the resolver doesn't want to resolve
> for the DNS64, but in that case the whole setup doesn't work so the users
> will give up and again, a few extra packets is not an issue.
>
> Not sure where SERVFAIL would come from in the authoritative case, but in
> the resolver case it can obviously result from a REFUSED authoritative
> response so again no problem querying for an A record.
>
> However, the NXDOMAIN case will normally be the result of a query for a
> non-existant domain. If there is a large amount of such queries doubling it
> is not a good idea.
>
> People configuring their DNS server to send out REFUSED for AAAA queries is
> something that I can kinda-sorta-but-not-really follow, but NXDOMAIN when
> there is in fact an A record is just plain wrong on every level so
> generating lots of extra queries when there is NXDOMAIN for AAAA or by
> always doing A first even when we don't need the A record is probably a
> bridge too far for the IETF to mandate.
Agree in some degree. Besides, dose sending A query if AAAA query
responses a  NXDOMAIN will cause security issue? Hackers could send
lots AAAA queries for non-exist domain and the DNS64 continue to
convert them to A queries will  use up all the resources of DNS64?

Best wishes,
Dapeng Liu
> What about the remaining 156? Timeout? (For instance, one on Mark's list
> that I tried replied in 4800 ms for me...)
>
> Would be interesting to see the results for A. As we saw in the FTP case,
> there is always a percent or two that just don't do anything reasonable.
> (Although with top 5000 popular sites this is probably better than an old
> list of FTP sites.)
>

---

From: liu dapeng <[email-masked]>
Date: Sun, 20 Dec 2009 14:56:29 +0800

Hi Andrew,

>    will decline in use as IPv6 deployment increases.
this means in the early stage of IPv6 depleoyment, many site can not
access using DNS64+NAT64, I am not sure whether it is a good
approach...

Best wishes,
Dapeng Liu

---

From: liu dapeng <[email-masked]>
Date: Sun, 20 Dec 2009 16:28:56 +0800

Hi Dan,

I find that www.blogsome.com could response correctly for AAAA query.
The response message have no answer record for AAAA RR but with a
RCODE=0. But most of the remaining servers listed in "REFUSED" section
could indeed have a response with RCODE=0;

For the "SERVFAIL" section: www.pathfinder.gr/
www.sznews.com/www.bramjnet.com indeed response Server failure ;
www.hc360.com time out.   But all others could have a response with
RCODE=0;

Best wishes,
Dapeng Liu

---

From: liu dapeng <[email-masked]>
Date: Sun, 20 Dec 2009 16:34:27 +0800

www.ratp.info listed in "SERVFAIL" section could also response with
RCODE=0 when queried with tye=AAAA. The response message does not have
any RRes.

Dapeng Liu

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 20 Dec 2009 11:03:19 -0500

> Do you set the query type to AAAA to your resolver?

I bet you're querying through a recursive resolver.  That's not the
right way to test this.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Dec 2009 17:50:19 +0100

> I bet you're querying through a recursive resolver.  That's not the

Do we assume a DNS64 will perform its own recursion?

Iljitsch

---

From: Simon Perreault <[email-masked]>
Date: Sun, 20 Dec 2009 12:11:35 -0500

On 12/19/2009 11:50 PM, liu dapeng wrote:
>  I tried to query
> which has the RCODE set to 2 (server failure).

I'm pretty sure the authoritative name server returns REFUSED:

$ dig @ns104-b.webex.com ciscosales.webex.com aaaa

; <<>> DiG 9.6.1-P2-RedHat-9.6.1-13.P2.fc12 <<>> @ns104-b.webex.com 
ciscosales.webex.com aaaa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17297
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ciscosales.webex.com.		IN	AAAA

;; Query time: 42 msec
;; SERVER: 64.68.104.8#53(64.68.104.8)
;; WHEN: Sun Dec 20 12:10:08 2009
;; MSG SIZE  rcvd: 38

Simon

---

From: Simon Perreault <[email-masked]>
Date: Sun, 20 Dec 2009 12:14:44 -0500

> Do we assume a DNS64 will perform its own recursion?

I hope not. It should be able to forward to another recursor.

Simon

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 20 Dec 2009 14:21:20 -0500

No, it definitely will break if it's behind a plain resolver. We had  
that discussion in Stockholm. If this isn't clear in the draft, please  
let me know.

-- 
Andrew Sullivan
<[email-masked]>

---

From: Simon Perreault <[email-masked]>
Date: Sun, 20 Dec 2009 16:40:48 -0500

> that discussion in Stockholm. If this isn't clear in the draft, please

Are you referring to section 6.1?

I understand from that section that a mixed-mode iterative and 
forwarding DNS resolver cannot work as intended when using a DNS64 as a 
forwarder. I fail to see how this is relevant to the case where a DNS64 
is forwarding to a plain resolver.

(Side remark: I do find the section confusing because it is clear to me 
that *any* direct querying of authoritative name servers by IPv6-only 
hosts, thus bypassing the DNS64, cannot work, and am left wondering why 
this section is only talking about the special case of "(mis)configured 
[...] mixed-mode iterative and forwarding resolvers".)

Are you also referring to the discussion in this thread?
http://www.ietf.org/mail-archive/web/behave/current/msg06384.html

Simon

---

From: Simon Perreault <[email-masked]>
Date: Sun, 20 Dec 2009 16:54:41 -0500

> http://www.ietf.org/mail-archive/web/behave/current/msg06384.html

Copy-pasting error. I meant this one:
http://www.ietf.org/mail-archive/web/behave/current/msg06386.html

Simon

---

From: liu dapeng <[email-masked]>
Date: Mon, 21 Dec 2009 10:03:18 +0800

> $ dig @ns104-b.webex.com ciscosales.webex.com aaaa

Hi Simon, Why ns104-b.webex.com return REFUSED but default server
return SERVFAIL?

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Dec 2009 13:56:22 +1100

In message <[email-masked]>, liu d
> Hi Simon, Why ns104-b.webex.com return REFUSED but default server

Firstly why is anyone asking ns104-b.webex.com about ciscosales.webex.com?
ns104-b.webex.com DOES NOT SERVE ciscosales.webex.com.  It serves
galaxyac.webex.com.

ciscosales.webex.com is served by {ns01,ns03,ns05,ns06,ns07,ns08}.webex.com
and is a CNAME to galaxyac.webex.com.

ciscosales.webex.com.   600     IN      CNAME   galaxyac.webex.com.
galaxyac.webex.com.     600     IN      NS      ns104-b.webex.com.
galaxyac.webex.com.     600     IN      NS      sjc2-ns-gh-mip1.webex.com.

"dig galaxyac.webex.com @ns104-b.webex.com aaaa" returns REFUSED
which results in the local recursive server returning SERVFAIL after
it has exhausted all the possible servers.

---

From: Simon Perreault <[email-masked]>
Date: Sun, 20 Dec 2009 22:05:23 -0500

> it has exhausted all the possible servers.

Yes, you're right of course. Sorry for the confusion, and thanks for the 
correction.

Simon

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Dec 2009 10:20:32 -0500

> Are you referring to section 6.1?

Yes, sorry for being both inaccurate and too brief.  (This'll teach me
to answer mailing lists from an iphone while stuck by a snowstorm and
even more addle-brained than usual.  One hopes this is not a lesson
one needs again :-)

> is forwarding to a plain resolver.

To be more clear, I believe that a forwarding, not-iterative mode
resolver could do DNS64 for a stub resolver; that is, it must be a
pure forwarded and never cache anything.

> [...] mixed-mode iterative and forwarding resolvers".)

The reason we're calling it out explicitly is because we know there
are deployed today mixed-mode forwarders.  (I know this, for instance,
because there's one sitting on my desk.)  Many of the little wireless
routers people use have a forwarder in them that, to "help", do some
caching.  Often this can be defeated, but that's how they ship.

> Are you also referring to the discussion in this thread?

The thread you corrected it to, yes.

Sorry for being unclear about this.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Dec 2009 10:25:48 -0500

> access using DNS64+NAT64, I am not sure whether it is a good

Two things:

    1.  Because I was in a hurry last week, I didn't double-check the
    results that Dan posted.  Simon since has, and it appears that
    there were few, if any, actual RCODE=3 responses for AAAA when the
    RNAME had an A record.  So I think the text you quoted should be
    removed from the draft.  I'm quite sure I've seen cases of Name
    Error for a AAAA that was outside the RFCs (because I will
    confidently predict that, if it is possible to mess up the
    implementation of DNS in any way, someone has in fact done it).
    But I don't think this is a widely deployed problem, and I was
    mildly surprised by the extent of Dan's report.

    2.  If there are in fact such deployed servers today, they are
    frankly already so broken that it's a wonder they work at all.  I
    have no hesitation in saying that they're irredeemable and need to
    be fixed, even if that causes DNS64 to work slightly less well
    than we'd prefer.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 21 Dec 2009 10:57:43 -0500

> pure forwarded and never cache anything.

What does caching have to do with it? The records given by a DNS64 (synthetic or
not) are cacheable. If they were not, we would be in big trouble.

> caching.  Often this can be defeated, but that's how they ship.

I understand. Might I suggest some improvements to make this section clearer?
Here's an attempt. I added normative text to make clear what the operational
recommendation is.

"Any DNS query originated from the network serviced by the DNS64 and destined to
a server upstream of the DNS64 is problematic. This can happen when a DNS
resolver including iterative functionality, whether it be fully iterative or
mixed-mode iterative/forwarding, tries to contact authoritative name servers
directly, without forwarding to the DNS64. This will create a discrepancy
between the answers given by that server and those given by the DNS64. As a
result, all queries originated from the network serviced by the DNS64 SHOULD be
forwarded to the DNS64."

But the initial use case we were talking about, and which you affirmed doesn't
work, was that of a DNS64 operating strictly in forwarding mode, synthesizing
records when the upstream resolver doesn't return data for AAAA. I would really
like to read your expanded thoughts on this, as this is exactly how one of my
implementations operates.

Thanks,
Simon

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Dec 2009 11:09:24 -0500

> not) are cacheable. If they were not, we would be in big trouble.

Well, strictly you're right in that the records from the answer
section ought to be cachable.  The problem is that the records in the
additional section also get cached, and they're the thing that'll
cause us pain if they get promoted or anything like that.  People
shouldn't do that, but they do.  

> result, all queries originated from the network serviced by the DNS64 SHOULD be

Very helpful.  Thanks.

> implementations operates.

No, no, that was what I was trying to correct in my last message.  I
was simply wrong in what I said (though not what I meant, but you
couldn't tell that from what I wrote!).  A DNS64 in the mode you
describe above _better_ work, or the entire program is doomed.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 21 Dec 2009 11:37:36 -0500

Andrew Sullivan wrote, on 2009-12-21 11:09:
> The problem is that the records in the

Can you expand on this? Is this specific to DNS64 or applies to DNS in general?
Is it already in the text?

Thanks,
Simon

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Dec 2009 10:09:16 -0800

> From: liu dapeng [mailto:[email-masked]] 
> Sent: Saturday, December 19, 2009 9:27 PM
> To: Dan Wing
> Cc: Iljitsch van Beijnum; Andrew Sullivan; [email-masked]

I am seeing NXDOMAIN, when querying the remote nameservers directly, for both
A and AAAA queries.  Both A and AAAA responses give me a CNAME.

Summary, AAAA query showing NXDOMAIN responses (detail is below):

  > dig +short ecshop.com ns | xargs -t -n 1 -I J dig @J aaaa www.ecshop.com |
grep status
  dig @ns.xinnetdns.com. aaaa www.ecshop.com
  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45448
  dig @ns.xinnet.cn. aaaa www.ecshop.com
  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62146

Summary, A query showing NXDOMAIN responses (detail is below):

  > dig +short ecshop.com ns | xargs -t -n 1 -I J dig @J a www.ecshop.com |
grep status
  dig @ns.xinnet.cn. a www.ecshop.com
  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27991
  dig @ns.xinnetdns.com. a www.ecshop.com
  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53739

-d

-----

> dig +short ecshop.com ns | xargs -t -n 1 -I J dig @J aaaa www.ecshop.com 
dig @ns.xinnet.cn. aaaa www.ecshop.com

; <<>> DiG 9.6.1-P1 <<>> @ns.xinnet.cn. aaaa www.ecshop.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11752
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.ecshop.com.                        IN      AAAA

;; ANSWER SECTION:
www.ecshop.com.         120     IN      CNAME   n100.shopex.cn.

;; AUTHORITY SECTION:
shopex.cn.              3600    IN      SOA     ns.xinnetdns.com.
hostmaster.xinnetdns.com. 1071681715 7200 900 604800 3600

;; Query time: 231 msec
;; SERVER: 202.10.73.9#53(202.10.73.9)
;; WHEN: Mon Dec 21 10:06:55 2009
;; MSG SIZE  rcvd: 133

dig @ns.xinnetdns.com. aaaa www.ecshop.com

; <<>> DiG 9.6.1-P1 <<>> @ns.xinnetdns.com. aaaa www.ecshop.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26800
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.ecshop.com.                        IN      AAAA

;; ANSWER SECTION:
www.ecshop.com.         120     IN      CNAME   n100.shopex.cn.

;; AUTHORITY SECTION:
shopex.cn.              3600    IN      SOA     ns.xinnetdns.com.
hostmaster.xinnetdns.com. 1071681715 7200 900 604800 3600

;; Query time: 234 msec
;; SERVER: 202.10.73.8#53(202.10.73.8)
;; WHEN: Mon Dec 21 10:06:55 2009
;; MSG SIZE  rcvd: 133

> dig +short ecshop.com ns | xargs -t -n 1 -I J dig @J a www.ecshop.com
dig @ns.xinnetdns.com. a www.ecshop.com

; <<>> DiG 9.6.1-P1 <<>> @ns.xinnetdns.com. a www.ecshop.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30721
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.ecshop.com.                        IN      A

;; ANSWER SECTION:
www.ecshop.com.         120     IN      CNAME   n100.shopex.cn.

;; AUTHORITY SECTION:
shopex.cn.              3600    IN      SOA     ns.xinnetdns.com.
hostmaster.xinnetdns.com. 1071681715 7200 900 604800 3600

;; Query time: 231 msec
;; SERVER: 202.10.73.8#53(202.10.73.8)
;; WHEN: Mon Dec 21 10:07:09 2009
;; MSG SIZE  rcvd: 133

dig @ns.xinnet.cn. a www.ecshop.com

; <<>> DiG 9.6.1-P1 <<>> @ns.xinnet.cn. a www.ecshop.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4793
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.ecshop.com.                        IN      A

;; ANSWER SECTION:
www.ecshop.com.         120     IN      CNAME   n100.shopex.cn.

;; AUTHORITY SECTION:
shopex.cn.              3600    IN      SOA     ns.xinnetdns.com.
hostmaster.xinnetdns.com. 1071681715 7200 900 604800 3600

;; Query time: 232 msec
;; SERVER: 202.10.73.9#53(202.10.73.9)
;; WHEN: Mon Dec 21 10:07:09 2009
;; MSG SIZE  rcvd: 133

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Dec 2009 10:09:57 -0800

> Sent: Saturday, December 19, 2009 9:59 PM
> To: Iljitsch van Beijnum
> Cc: Dan Wing; Andrew Sullivan; [email-masked]
> argue that this
> never encounter
> query for a
> AAAA queries is
> AAAA or by

(Unlike NAT-PT,) there aren't any resources in the DNS64 to consume.

-d

> the FTP case,

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Dec 2009 10:21:03 -0800

> [mailto:[email-masked]] On Behalf Of liu dapeng
> Sent: Sunday, December 20, 2009 12:29 AM
> To: Dan Wing
> Cc: Andrew Sullivan; [email-masked]

You're using nslookup, so here is the output of my command:

  > nslookup -q=ns blogsome.com
  Server:         127.0.0.1
  Address:        127.0.0.1#53

  Non-authoritative answer:
  blogsome.com    nameserver = ns2.browseireland.com.
  blogsome.com    nameserver = ns3.browseireland.com.
  blogsome.com    nameserver = ns1.browseireland.com.

  Authoritative answers can be found from:
  ns1.browseireland.com   internet address = 212.147.136.30
  ns2.browseireland.com   internet address = 216.55.166.148
  ns3.browseireland.com   internet address = 212.147.136.3

querying ns2, I get REFUSED:

  > nslookup -query=aaaa www.blogsome.com. ns2.browseireland.com.
  Server:         ns2.browseireland.com.
  Address:        216.55.166.148#53

  ** server can't find www.blogsome.com: REFUSED

Showing similar output using Dig:

  > dig +short blogsome.com ns | xargs -t -n 1 -I J dig @J aaaa
www.blogsome.com | grep status
  dig @ns2.browseireland.com. aaaa www.blogsome.com
  ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 45888
  dig @ns1.browseireland.com. aaaa www.blogsome.com
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42073
  dig @ns3.browseireland.com. aaaa www.blogsome.com
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55319

> www.hc360.com time out.   But all others could have a response with

*shrug*.  I don't know why the results are different.

-d

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Dec 2009 07:42:43 +1100

> A and AAAA queries.  Both A and AAAA responses give me a CNAME.

You are seeing cache poisioning attempts.  ns.xinnetdns.com and
ns.xinnet.cn are only authoritative for www.ecshop.com not
n100.shopex.cn.  named only sees the CNAME record and ignores the
rest of the answer, named then goes out and resolves n100.shopex.cn/AAAA
which is why people don't see anything wrong with www.ecshop.com.

Mark
 
> |

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Dec 2009 08:01:55 +1100

> *shrug*.  I don't know why the results are different.

www.pathfinder.gr/AAAA lookups fail because the nameservers for
www.pathfinder.gr appear to be configured to serve pathfinder.gr
rather than www.pathfinder.gr and you only see this in cachable
negative answers.  If you ask for www.pathfinder.gr/SOA or
www.pathfinder.gr/TXT or www.pathfinder.gr/NS you get a non-cachable
negative answer.  I supect the vendor has tried to make AAAA negative
answers cachable and the operator has put the wrong zone name into
the configuration.

www.pathfinder.gr.      10800   IN      NS      lp.phaistosnetworks.gr.
www.pathfinder.gr.      10800   IN      NS      lpsb.phaistosnetworks.gr.
www.pathfinder.gr.      10800   IN      NS      lptb.phaistosnetworks.gr.
;; Received 155 bytes from 62.103.124.3#53(phaistos.phaistosnetworks.gr) in 392 ms

pathfinder.gr.          86400   IN      SOA     pathfinder.gr. administrator.pathfinder.gr. 998545544 28800 7200 604800 86400
;; Received 124 bytes from 194.0.185.253#53(lptb.phaistosnetworks.gr) in 445 ms

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Dec 2009 16:41:41 -0500

> Is it already in the text?

We have this:

5.3.2.  Handling the additional section

   DNS64 synthesis MUST NOT be performed on any records in the
   additional section of synthesized answers.  The DNS64 MUST pass the
   additional section unchanged.

Here's the problem.  Suppose you have a resolver that does some
caching, but it's not really an iterative mode resolver.  This is the
way at least some home units work today: they cache, and they work on
the basis of what they have cached, but they rely entirely on whatever
upstream resolver they get from DHCP.  So, no root.hints, and so on.

In such an arrangement, if (logically speaking) the cache happens
after the DNS64 (as would make sense, or else the cache is worthless),
_and_ the resolver uses its own cache to resolve names, _and_ the
cache stores what's in the additional as well as the answer section,
then a querying client could get the DNS64's cache of the additional
section.  Since it's not got any synthesized records in it, the chain
could break down.  This is especially true if the cache isn't
rigorous, and promotes cached additional section data to answers.

All that would be a sloppy and ill-thought-out
configuration/implementation.  I've certainly seen such
implementations, however.  The fact is that many implementations of
various DNS bits don't really understand how the cache can affect
them.

Whether this is all plain from the draft (or even worth worrying
about) is something the reviewers will have to tell me.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 21 Dec 2009 17:04:26 -0500

Andrew Sullivan wrote, on 2009-12-21 16:41:
> section.

I'm following you up to here.

> Since it's not got any synthesized records in it, the chain
> could break down.

I don't see why. If the cache doesn't contain a given AAAA synthetic record, the
server will try to get it from upstream. That is, unless negative caching is
involved, but it shouldn't be when you just put stuff from the additional
section into the cache.

Maybe a concrete example with records and IP addresses would help...

Thanks,
Simon

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Dec 2009 09:09:59 +1100

> about) is something the reviewers will have to tell me.

Just don't populate the additional section.  It's optional except when
performing a referral.

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Dec 2009 17:24:45 -0500

> involved, but it shouldn't be when you just put stuff from the additional

Only if your DNS64 is sane.  I agree it shouldn't normally be a
problem, but I would not be at all surprised to see someone get this
detail wrong.  (Remember that some caches are going to assume that the
cached additional is all that is available, and if the data is there
it must have been useful.  Or something.  Honestly, I don't fully
understand how some of the stranger implementations one sees get that
way.)

The alternative, which is what Mark suggested before, (and has just
done again in this thread) is to truncate the additional.  We didn't
get anyone else supporting that option when it was proposed last time.
But unaltered additional on the "inside" of the DNS64 is, frankly,
useless anyway, so the more I think about it the more attractive that
option is to me.  Does anything need it?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Dec 2009 14:48:27 -0800

> [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Monday, December 21, 2009 7:26 AM
> To: [email-masked]

Concur - please remove that text.  (I was going to say that in
my WGLC review.)  Thanks for your consideration of the problem,
though.  Once Simon pointed out that querying those same nameservers
for A gave the same result as querying for AAAA, I see the problem
is not with AAAA but rather with the nameservers themselves.

-d

---

From: Simon Perreault <[email-masked]>
Date: Mon, 21 Dec 2009 19:21:29 -0500

> understand how some of the stranger implementations one sees get that

I understand now. Thank you very much for taking the time to explain 
this to me.

> option is to me.  Does anything need it?

I think this is an operational issue and the spec doesn't need to 
address it. The environmental conditions that give rise to these 
concerns may very well change over the lifetime of DNS64. So at most 
leave it configurable (e.g. minimal-responses with Bind). I'd prefer for 
the spec to be silent on this.

Thanks again,
Simon

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 22 Dec 2009 18:35:11 +0100

> understand how some of the stranger implementations one sees get that

Don't forget that we're talking about new deployments here: we don't have a decade long history of craptastic boxes to work around. There are probably only one or two boxes out there that actually do all this over IPv6 today. So we have an opportunity to tell the home gateway etc vendors to get it right. (See also the homegate bof.)

About truncating the additional section: aren't we setting ourselves up for some nasty bugs come the time people start running hybrid authoritative/DNS64 servers?

And are there any performance / cache hit issues with truncating the additional section?

Iljitsch

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Dec 2009 12:43:49 -0500

On Tue, Dec 22, 2009 at 06:35:11PM +0100, Iljitsch van Beijnum wrote:

> Don't forget that we're talking about new deployments here: we don't
> have a decade long history of craptastic boxes to work around. There
> are probably only one or two boxes out there that actually do all
> this over IPv6 today. So we have an opportunity to tell the home
> gateway etc vendors to get it right. (See also the homegate bof.)

If you have a look at the work that Ray Bellis and his colleagues did
about gateways, you will discover that there's a lot of home gear
available from stores today (well, last year, but whatever) that get
this all horribly wrong.  DNS is not hard, but it is tricky, and a
poor familiarity with the history and the RFCs will make one prone to
simple foolish  mistakes.  I doubt this case is any different: the
dns64 draft requires the reader to understand DNS already.  

> About truncating the additional section: aren't we setting ourselves
> up for some nasty bugs come the time people start running hybrid
> authoritative/DNS64 servers?

Well, first, Don't Do That (tm).  There's a long history of
recommendations that one not run iterative and authoritative in the
same server.  The reason for this is simply that it has been the
source of numerous bugs and configuration errors, most of which are
all but impossible to comprehend for someone who doesn't already
understand DNS.  But secondly, the whole point here is that we don't
want anyone relying on the additional data that might have filtered
through a DNS64.  So if there's an authority server that is somehow
getting data out of cache that might have been fiddled with by DNS64,
we can be pretty sure it's never going to work right.  That seems
like a poor implementation to me.

> And are there any performance / cache hit issues with truncating the

I'm not worried about the cache hit, but any rewriting of the message
is automatically going to cause performance hits by definition.  And
of course, if glue's not available from a cache, you have to fetch
it.  But that was always going to be a disadvantage of this work
unless we rewrote the additional section, and that (as Mark argued
correctly at Stockholm) will break in a much more puzzling way.  

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 22 Dec 2009 18:47:55 +0100

> this all horribly wrong.

Yes, but I don't think any of that stuff is running IPv6. We get to leave those boxes behind and make a fresh start with IPv6, where we have the chance to get most of this right (of course in a few years we'll discover what new stuff we got wrong).

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 22 Dec 2009 13:14:52 -0800

> Yes, but I don't think any of that stuff is running IPv6. We get to leave those boxes behind and make a fresh start with IPv6, where we have the chance to get most of this right (of course in a few…

This isn't really a safe assumption  anymore... cpe (from cisco/linkys
d-link apple etc) that I see down at the local offciemax/bestbuy has
ipv6 ready and windows vista logos applied. This stuff has whatever
dodgy v4 implmentation it had plus whatever it chooses to do for v6 to
meet that vista logo compliance requirement you can bet it does 6to4,
given time to market (the firmware on my d-link was from april) that
ship has sailed and we'll be living with it for quite some time.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 22 Dec 2009 22:22:42 +0100

> ship has sailed and we'll be living with it for quite some time.

I'm pretty sure the worst IPv6 CPEs are still much better than the worst IPv4 CPEs with regard to DNS issues.