Subject: Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00

From: Alfred Hönes <[email-masked]>
Date: Fri, 29 Jan 2010 03:16:37 +0100 (MEZ)

On 29 Jan 2010 00:16:21 +0000, Alex Bligh wrote:
> On 28 Jan 2010 17:06:43 -0500 Olafur Gudmundsson <[email-masked]> wrote:
>
>    "Is it one of DNS roles to provide information on where the query
>     originated from?"
>
> Define "where".

That's the _primary_ question to be elaborated upon in a proper
problem statement that indeed SHOULD precede a proposed solution.

> --
> Alex Bligh

BTW #1:
  Has anybody of the draft authors considered interaction with
  IP Mobility?   Please study MIP4, MIP6, PMIP6, Network Mobility,
  and all the flavors and optimization techniques already specified
  and/or currently being revised and advanced on the Standards Track!

BTW #2:
  It's one of the annoyances I repeatedly suffer from:
  Wanting purposely an answer specifically from www.google.com or
  say, www.google.fr, and then being redirected to www.google.de .

  IMO, increasing lack of transparency in the middle is the real
  problem we have.  Ever increasing "intelligence" in the middle
  (and the core) limits the future evolution of IP networking,
  and causes an ever increasing mess of hacks necessary to overcome
  the limitations enforced by these so-called "helpers".
  All this increases fragility.

BTW #3
  For content distribution, I observe that knowledge of
  straightforward techniques seems to have eroded substantially.
  HTML has BASE refs, which obviously mostly aren't used any more
  as intended, and HTTP has redirects.
  It is this application layer where user preferences and properties
  should be used (under strict policy control by the end user) to
  influence the content being served.
  Let the user decide, on a per-service or per-resource base,
  when and where he would like to get assistance by "helpers",
  and co-locate these with the service, not the core or the middle!

BTW #4:
  Did you consider the consequences for error diagnostic, help desk
  functions, etc., of adding even more 'cheating' to the DNS?
  When a user does not get what he wants and the help desk located
  in, say, India, wants to reproduce the problem the user in, say,
  Ireland, has -- how many time and effort will it cost to figure
  out what's going wrong when both do not obtain the same responses
  for DNS queries sent to the public Internet?
  Does that outweigh the "commodity" of a few "global players" ?

  The primary objective of the DNS is consistency.

RFC 1034, Section 2.2, "DNS Design Goals" starts with:

   - The primary goal is a consistent name space which will be used
     for referring to resources.

... and later containss:

   - We want name server transactions to be independent of the
     communications system that carries them.  [...]

Independence of "the communications system" implies independence of
addresses used in the network layer carrying the transactions.

>From this it should be clear that the answer to Olafur's initial
question is: "no".

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 29 Jan 2010 09:32:04 +0000

>  The primary objective of the DNS is consistency.

That really doesn't seem like a reasonable position. Consistency is
the part of Brewer's CAP theorem that DNS sacrifices (in favour of
availability and partition tolerance). If consistency was the primary
objective then all TTLs would be 0 and there would be synchronous
atomic updates only. DNS is intentionally inconsistent by design.

The primary objective of the DNS is a naming service for the internet.
The market has decided that it is useful to be able to transport users
and clients to independent network nodes based on network proximity,
and IP anycast does not seem to do an acceptable job. It does seem
like a useful property of the network that this functionality be
available. My problem statement would be :

    "In-use methods for transparently directing internet clients to
their their most proximate internet servers are not interoperable or
published, causing suboptimal internet performance".

Even critics of the I-D are suggesting that more widely-distributed
resolvers would be a better solution. I don't understand this - a more
broadly distributed base would necessarily have poorer caching
efficiency, and so likely degrade the DNS performance, and it would
still imply that auth servers are generating incoherent answers based
on source.

-- 
Colm

---

From: Alex Bligh <[email-masked]>
Date: Fri, 29 Jan 2010 09:57:46 +0000

> still imply that auth servers are generating incoherent answers based

I don't understand the model for that. If you have DNS Servers centrally,
serving multiple /16s or whatever, you do not have a single server or group
of servers sharing a coherent cache. You have several in a rack, probably
on anycast. If you push them out towards the edge, the number of separate
instances of a DNS cache does not necessarily increase much, assuming you
keep server load about the same. Even if there is an increase (from more
servers, each more lightly loaded), unless you increase the number of
servers such that there is one per /24, you are unlikely to have the same
effect as the draft.

We are both handwaving a bit here though, as this argument (on both
sides) has not had any numbers attached to it.

-- 
Alex Bligh

---

From: Jim Reid <[email-masked]>
Date: Fri, 29 Jan 2010 09:56:36 +0000

On 29 Jan 2010, at 09:32, Colm MacCárthaigh wrote:

> If consistency was the primary objective then all TTLs would be 0  
> and there would be synchronous atomic updates only. DNS is  
> intentionally inconsistent by design.

That depends on the definition of consistency. Sure, DNS is loosely  
consistent because of cacheing and zone propagation latency. However  
there is a higher level consistency that is unwritten (and probably  
needs to be formally documented). This is the principle of uniformity.  
ie No matter where you are or what software you use or which server(s)  
you query, the DNS always returns the same answer for the same lookup.

IMO facilitating "stupid DNS tricks" as Paul put it undermines the  
cornerstone of what the DNS is all about.

---

From: Jim Reid <[email-masked]>
Date: Fri, 29 Jan 2010 10:02:24 +0000

On 29 Jan 2010, at 09:32, Colm MacCárthaigh wrote:

> The market has decided

No! A small segment of the people using the DNS have decided, not "the  
market". Besides, markets are not infallible. And this list is about  
engineering, not marketing.

---

From: Jim Reid <[email-masked]>
Date: Fri, 29 Jan 2010 10:12:01 +0000

On 29 Jan 2010, at 09:32, Colm MacCárthaigh wrote:

> My problem statement would be :
>

Define "most proximate". It is hop count? RTT? Fastest/least congested  
pipe(s)? Quickest or least loaded routers? Most stable/reliable route?  
Best/cheapest path via the corporate firewalls?

Even if a DNS server could be made to figure this out -- I doubt that  
-- it doesn't follow that the decision it makes will always be the  
right one for the end client. The server can't possibly have a clue  
about local policy at the client.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 29 Jan 2010 10:14:53 +0000

On Fri, Jan 29, 2010 at 9:57 AM, Alex Bligh <[email-masked]> wrote:
> of servers sharing a coherent cache.

In many real-world cases, you do. Tiered hierarchies of caches and
shared caches are not uncommon. (I believe Comcast had this setup for
a while). Some vendors even retail shared caches as a feature. From
the outside looking in, it appears that Google Public DNS uses shared
caches internally to some extent too.  This is relatively easy to
confirm by observing incoming queries to an auth server Vs incoming
queries to Public DNS from many sources.

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 29 Jan 2010 10:23:41 +0000

On Fri, Jan 29, 2010 at 9:56 AM, Jim Reid <[email-masked]> wrote:
>> If consistency was the primary objective then all TTLs would be 0 and
>> there would be synchronous atomic updates only. DNS is intentionally
>> inconsistent by design.
>
> consistent because of cacheing and zone propagation latency. However there
> is a higher level consistency that is unwritten (and probably needs to be
> formally documented). This is the principle of uniformity. ie No matter
> where you are or what software you use or which server(s) you query, the DNS
> always returns the same answer for the same lookup.

That paragraph is self-contradictory. Even ignoring the tricks, DNS
does not always return the same answer for the same lookup; by design.
TTLs of two days and higher are not uncommon, meaning this kind of
inconsistency (and if returning different answers cannot be called
inconsistency then I don't know what can) can last for days. Evidently
this property is not a real problem. The principal of strict
uniformity does not appear to matter very much. Real-world operators
are used to having to deal with this.

Taking the tricks into account, they've been use for over a decade
now, also evidently without any real problem. Again, the principal of
strict uniformity does not appear to matter.

> cornerstone of what the DNS is all about.

How does it actually lessen DNS's efficacy? What are the actual
engineering problems? I've read Paul's paper and other writings, and
can find no cogent argument. The objections seem dogmatic rather than
based on the real-world use-cases and properties of the protocol.

-- 
Colm

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 29 Jan 2010 11:28:52 +0100

Your subject is completely inappopriate: since this is the
authoritative name server which decides the answer (depending on some
input from the client), it cannot be called "mangling" (and that's why
this proposal is compatible with DNSSEC). By definition, the
authoritative name server decides what it wants to respond.

On Fri, Jan 29, 2010 at 10:12:01AM +0000,
 Jim Reid <[email-masked]> wrote 
 a message of 19 lines which said:

> Define "most proximate".

No, do not define it. The purpose of this WG is *not* to define
load-balancing or optimization algorithm. It is to standardize DNS
extensions. The draft under discussion do not (and rightly so) specify
*how* the authoritative name server will generate its answer, just how
the client can send it more information.

> It is hop count? RTT? Fastest/least congested pipe(s)? Quickest or
> least loaded routers? Most stable/reliable route?  Best/cheapest
> path via the corporate firewalls?

My mom told me never to follow the troll in the wood :-)

> Even if a DNS server could be made to figure this out -- I doubt
> that -- it doesn't follow that the decision it makes will always be
> the right one for the end client. The server can't possibly have a
> clue about local policy at the client.

That's an entirely new goal for the DNS: send data which is right for
the client. It never was intended to be used that way. The goal of the
DNS is to send to the client the answer that pleases the authoritative
name server. 

(For instance, it would be better for the client that a request for
www.microsoft.com sends back 198.182.196.56, the IP address of
www.linux.org, but this is not something the DNS should do.)

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 29 Jan 2010 10:32:53 +0000

On Fri, Jan 29, 2010 at 10:12 AM, Jim Reid <[email-masked]> wrote:
> Even if a DNS server could be made to figure this out -- I doubt that -- it
> doesn't follow that the decision it makes will always be the right one for
> the end client. The server can't possibly have a clue about local policy at
> the client.

Figuring all of that out does not seem intractable, for one example of
such analysis;

http://research.google.com/archive/imc191/imc191.pdf

But the authoritative nameserver is free to use any criteria it
chooses, I guess it's simply in the operators interest to align the
criteria with what makes the most sense for users. Servers can measure
RTTs and Transfer times and so on ... so it seems like "having a clue"
is doable.

-- 
Colm

---

From: Alex Bligh <[email-masked]>
Date: Fri, 29 Jan 2010 10:53:46 +0000

--On 29 January 2010 10:14:53 +0000 Colm MacCárthaigh <[email-masked]> 
wrote:

>> serving multiple /16s or whatever, you do not have a single server or
>> group of servers sharing a coherent cache.
>

Right, but tiered hierarchies of caching are going to broken by
the draft too, as they well have to key on more than the q-tuple.

-- 
Alex Bligh

---

From: Jim Reid <[email-masked]>
Date: Fri, 29 Jan 2010 11:43:38 +0000

On 29 Jan 2010, at 10:23, Colm MacCárthaigh wrote:

>>> and
> That paragraph is self-contradictory.

Not really Colm. The higher level concept of uniformity expressed  
above isn't actually undermined by the above examples of loose  
coherency. For instance, the TTL for some resource record is (or  
should be) a commitment by the zone owner that that RR won't change  
inside the TTL. The window where authoritative servers may be out of  
sync is small these days and getting smaller. It's more of a  
theoretical concern than one that people worry about. And in  
environments where this is considered a significant risk, folk use  
databases to get immediate replication.

Yes, if someone looks *really* hard they *might* come across examples  
of loose consistency. However those transient anomalies will return to  
the usual steady state and converge on a consistent name space: think  
regression to the mean. That's not the same as violating the principle  
of uniformity by handing out different data *by design* to different  
clients who make the same query.

> now, also evidently without any real problem.

Well in another thread, I've given a couple of examples where stupid  
DNS tricks cause very real problems. These problems are of course  
externalities to the people doing those DNS tricks, so they might not  
care about those problems or acknowledge their existence.

> Again, the principal of strict uniformity does not appear to matter.

In your opinion. I think the people who are proposing these sorts of  
DNS changes have the responsibility to prove that the changes cause no  
harm and make the engineering trade-offs clear. [ie Is the cost of  
changing the world's DNS software worth the benefits of the new  
feature? Are there any second- or third- order effects?] So far there  
isn't even a problem statement or any hard data.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 29 Jan 2010 12:47:25 +0100

On Fri, Jan 29, 2010 at 09:56:36AM +0000,
 Jim Reid <[email-masked]> wrote 
 a message of 17 lines which said:

> However there is a higher level consistency that is unwritten (and
> probably needs to be formally documented).

If you try this, I'm afraid you will run into problems similar to the
"reverse DNS" draft-ietf-dnsop-reverse-mapping-considerations:
everyone thought it was simple and it turned out that the so-called
"shared unwritten assumptions" are not shared at all (there was a
reason why they were unwritten...)

> This is the principle of uniformity.  ie No matter where you are or
> what software you use or which server(s) you query, the DNS always
> returns the same answer for the same lookup.

Your definition is incomplete. The real one (RFC 1034, section 2.3) is
more like "No matter where you are or what software you use or which
server(s) you query, the DNS always returns the same answer for the
same lookup, FOR THE DURATION OF $TTL".

So, load-balancers which use a TTL of 0 (something I do not like,
because it defeats caching) are right, protocol-wise. More right than
the good citizens which use a proper TTL (but violate the definition
of consistency).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 29 Jan 2010 12:52:36 +0100

On Fri, Jan 29, 2010 at 10:12:01AM +0000,
 Jim Reid <[email-masked]> wrote 
 a message of 19 lines which said:

> Define "most proximate". It is hop count? RTT? Fastest/least
> congested pipe(s)? Quickest or least loaded routers? Most
> stable/reliable route?  Best/cheapest path via the corporate
> firewalls?

There is an IETF Working Group which deals with these questions, ALTO
<http://tools.ietf.org/wg/alto/>. Enrico Marocco already forwarded
them this discussion.

But I do not think this issue is relevant: the IETF does not care
*how* the name server decided to reply 203.0.113.1 or
198.51.100.198. In the same way that RFC 2616 does not say *how* the
Web server decides to 301 redirect and to whom. We should stick with
protocol issues: how to carry information from one machine to another,
not how what the servers decide to reply.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 29 Jan 2010 12:58:45 +0100

On Fri, Jan 29, 2010 at 11:43:38AM +0000,
 Jim Reid <[email-masked]> wrote 
 a message of 65 lines which said:

> I think the people who are proposing these sorts of DNS changes have
> the responsibility to prove that the changes cause no harm

But you are off-topic here: the draft under discussion does not
suggest to change the DNS protocol or to standardize auth. servers
behavior or to mandate an algorithm to load-balancing, it is mostly
about a way to indicate something about the client. There is no reason
for the authors to prove that it affects Security & Stability (except
if the use of unknown EDNS option codes prove to break many
firewalls, which is still a possibility).

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 29 Jan 2010 12:05:07 +0000

2010/1/29 Jim Reid <[email-masked]>:>
> Not really Colm. The higher level concept of uniformity expressed above
> isn't actually undermined by the above examples of loose coherency. For
> instance, the TTL for some resource record is (or should be) a commitment by
> the zone owner that that RR won't change inside the TTL.

If this were the case; then all DNS record changes would have to be
scheduled in advance and authoritative TTLs would decrement in
anticipation of that time. But this is evidently not the case.

>The window where authoritative servers may be out of sync is small these days and getting
> smaller.

Even the root-zone and TLD TTLs are typically two days. But this
raises an interesting question; are DNS tricks ok if the TTL is always
0?

> Yes, if someone looks *really* hard they *might* come across examples of
> loose consistency. However those transient anomalies will return to the
> usual steady state and converge on a consistent name space: think regression
> to the mean. That's not the same as violating the principle of uniformity by
> handing out different data *by design* to different clients who make the
> same query.

My point is that the internet, clients, and all of us have to tolerate
such inconsistency - it's simply a fact of life, even if DNS tricks
did not exist. Holding up strong-consistency as a must-have property
of the DNS is simply at-odds with reality. We don't have it now, and
the internet still works :)

> Well in another thread, I've given a couple of examples where stupid DNS
> tricks cause very real problems. These problems are of course externalities
> to the people doing those DNS tricks, so they might not care about those
> problems or acknowledge their existence.

I saw your complaints about language choice and redirection, but I'm
not sure how this is related to DNS tricks. It seems more like a
consequence of generally poor operations and user-interface design
than related to directional naming. The engineering aim here is to
direct clients to the "best"/"closest"/"whatever" node - the
capabilities of that node are an orthogonal concern.

Interestingly, as the I-D specifies that where the option is set on
incoming queries it should be forwarded, it actually gives users
/more/ power over the problem you cite. A browser/OS could be
configured to specify any IP address it liked, it get the desired
behavior. To me it seems to do more to address the problem than to
cause it anew.

As for operational issues and debugging, yes this a problem - though I
think a marginal one. Practices have evolved for this; many auth DNS
providers provide records that reflect back the resolver IP, for
example, to aid debugging. (e.g. whoami.akamai.net,
whoami.ultradns.net).

> In your opinion. I think the people who are proposing these sorts of DNS
> changes have the responsibility to prove that the changes cause no harm and
> make the engineering trade-offs clear. [ie Is the cost of changing the
> world's DNS software worth the benefits of the new feature? Are there any
> second- or third- order effects?] So far there isn't even a problem
> statement or any hard data.

There are problem statements, and some data. More data would be great.
But it still seems like an odd approach. The fact remains that
regardless of the draft, the technique (including ad-hoc client-ip
forwarding arrangements) are already in-use and are not going away.
The question is really "is having an interoperable standard for this
better than the de-facto behaviour of inter-provider arrangements and
exceptions". It is not being proposed in a vacuum as if it this will
be new never-seen-before behaviour. I think that makes our job easier.

-- 
Colm

---

From: Jim Reid <[email-masked]>
Date: Fri, 29 Jan 2010 12:39:54 +0000

> not how what the servers decide to reply.

Indeed Stephane. However this discussion began with a draft that  
suggested clients send IP addressing info with their queries. If the  
draft is to go further -- I hope it doesn't -- it will very likely  
attract other cruft. For example hooks for additional data such as hop  
count to help the authoritative server do its trickery. This sort of  
cruft would mean more protocol issues.

Earlier comments about the draft suggested adding other data for  
client identification. So it's not unreasonable to mention other  
metrics for proximity now because of the protocol issues that would be  
needed to accommodate them. ie What sorts of proximity are meant and  
how would they be represented in some sort of EDNS query. What those  
metrics are (or could be) doesn't matter in that context.

---

From: "George Barwood" <[email-masked]>
Date: Fri, 29 Jan 2010 12:53:17 -0000

----- Original Message ----- 
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Jim Reid" <[email-masked]>
Cc: "Colm MacCárthaigh" <[email-masked]>; <[email-masked]>
Sent: Friday, January 29, 2010 11:58 AM
Subject: [dnsext] Re: a definition of consistency

> There is no reason

There was a longstanding problem where Facebook authoritative servers were issuing bad
responses when sent an EDNS option code, but after I notified them (last August)
this was fixed.

It seems that new EDNS option codes are now useable in practice. I have been testing
this for many months and have not found any further problems.

I think it would actually be a good thing for the EDNS option feature to be exercised,
as this current good situation may not last. If you don't exercise something, it is likely to
have problems when you need it.

George

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 29 Jan 2010 14:10:45 +0100

On Fri, Jan 29, 2010 at 12:05:07PM +0000,
 Colm MacCárthaigh <[email-masked]> wrote 
 a message of 78 lines which said:

> many auth DNS providers provide records that reflect back the
> resolver IP, for example, to aid debugging. (e.g. whoami.akamai.net,
> whoami.ultradns.net).

Is there one which works with IPv6 or at least does not crash? These
two are awfully broken.

% dig AAAA whoami.ultradns.net

; <<>> DiG 9.5.1-P3 <<>> AAAA whoami.ultradns.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16990
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;whoami.ultradns.net.		IN	AAAA

;; AUTHORITY SECTION:
ultradns.net.		60	IN	SOA	udns1.ultradns.net. domadmin.ultradns.net. 2010012801 900 600 604800 60

;; Query time: 22 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Jan 29 14:10:17 2010
;; MSG SIZE  rcvd: 99

% dig A whoami.ultradns.net

; <<>> DiG 9.5.1-P3 <<>> A whoami.ultradns.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58509
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;whoami.ultradns.net.		IN	A

;; ANSWER SECTION:
whoami.ultradns.net.	0	IN	A	192.134.4.69

;; Query time: 17 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Jan 29 14:10:29 2010
;; MSG SIZE  rcvd: 64

---

From: [email-masked]
Date: Fri, 29 Jan 2010 13:20:05 +0000

> firewalls, which is still a possibility).

It will certainly cause some home gateway proxies to reject the packets.

In SAC035 we found at least one that FORMERR'ed any EDNS0 option, and 
another that dropped the packets on the floor.

Ray

---

From: [email-masked]
Date: Fri, 29 Jan 2010 13:25:12 +0000

> But I agree with George Barwood: we should exercice our freedom to use
> EDNS.

Oh absolutely!  We shouldn't declare EDNS0 a no-go area just because a few 
boxes choose not to support it.

Ray

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 29 Jan 2010 14:23:33 +0100

On Fri, Jan 29, 2010 at 01:20:05PM +0000,
 [email-masked] <[email-masked]> wrote 

> It will certainly cause some home gateway proxies to reject the packets.

Then, this deserves a mention in the draft, with a reference to 5625.

---

From: Jim Reid <[email-masked]>
Date: Fri, 29 Jan 2010 14:34:15 +0000

On 29 Jan 2010, at 12:05, Colm MacCárthaigh wrote:

> are DNS tricks ok if the TTL is always 0?

Apart from that Mrs. Lincoln, how did you enjoy the play? :-)

DNS tricks are the wrong way to solve CDN problems IMO. Amongst other  
things, it's a layering violation. Zero length TTLs might be a less  
intrusive way of using such trickery. But it still doesn't mean DNS  
trickery is a good thing.

> We don't have it [consistency] now, and the internet still works :)

Er, no. DNS tricks can take people's browsers to places they shouldn't  
go and provide content they didn't want or ask for and sometimes don't  
understand. You might say that's not breaking the Internet. I  
disagree. This sort of broken browser behaviour shouldn't result from  
things that happen in the DNS.

> not sure how this is related to DNS tricks.

Because it's stupid DNS tricks that are responsible for taking my  
browser to pages in languages I don't understand and didn't ask for.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 29 Jan 2010 15:21:11 +0000

2010/1/29 Jim Reid <[email-masked]>:
> Because it's stupid DNS tricks that are responsible for taking my browser to
> pages in languages I don't understand and didn't ask for.

I really doubt that it is. Do you think it's likely that those page
providers have distinct network end-node destinations on a
per-language basis? For a concrete example; When I query
google.com/nl/ie/co.uk/be/ch and so on, I actually get the same IPv4
result. I'm being directed to my closest node (probably a data-centre
in Dublin, where I also live). I presume the IP is the front-end of
some kind of load-balancer, or the Google web-server. But the language
negotiation is orthogonal, and likely based a combination of
Accept-Lang and Host headers, or possibly a GeoIP lookup on the HTTP
client-ip.

Can you provide one concrete example where incoherent DNS responses
result in being directed to sites that respond in different languages
purely based on the ultimate destination IP address?

-- 
Colm

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 29 Jan 2010 08:43:41 -0800

On Jan 29, 2010, at 5:20 AM, [email-masked] wrote:

> In SAC035 we found at least one that FORMERR'ed any EDNS0 option, and another that dropped the packets on the floor. 

This I think is why its clear that only requests containing an EDNS0 option should be replied to with the EDNS0 option, so such gateways etc either shouldn't be a problem, or should be manageabre by the requestor.

This should be universal for ANY EDNS0 extension.