Subject: [DNSOP] Split DNS problems for multi-interfaced hosts and a possible solution

From: <[email-masked]>
Date: Tue, 15 Jun 2010 14:22:52 +0200

Hi dnsop WG,

In relation to MIF WG I have been authoring an individual draft that talks about problems Split DNS causes for multi-homed hosts.

Peter asked me to solicit this group for opinions and thoughts.

I would like to hear what do you think about the problem, and especially what do you think about the solution that is currently based on DHCPv6 option informing hosts which DNS servers are able to answer forward queries related to specific names or reverse queries for certain prefixes.

https://datatracker.ietf.org/doc/draft-savolainen-mif-dns-server-selection/

Abstract:
--
   A multi-homed host may receive DNS server configuration information
   from multiple physical and/or virtual network interfaces.  In split
   DNS scenarios some DNS servers have information others do not have.
   When the multi-homed host needs to utilize DNS, it has to select
   which of the servers to contact to.  This document describes a policy
   based method for selecting DNS server for both forward and reverse
   DNS lookup procedures with help of DNS suffix and IPv6 prefix
   information received via DHCPv6.
--

Thank you,

                Teemu

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Jun 2010 09:11:26 -0400

>Peter asked me to solicit this group for opinions and thoughts.

A comment independent of your (Teemu's) effort.

The DNSOP group has considered but never adopted a draft (nor any 
documented promoted to RFC) that defined what split DNS is.  Without 
a definition of split DNS, commenting on its complications for 
multi-homed devices will probably cause rat holing.

The group has to define split DNS.

http://datatracker.ietf.org/doc/draft-krishnaswamy-dnsop-dnssec-split-view/
(Last update more than three years ago.)

>https://datatracker.ietf.org/doc/draft-savolainen-mif-dns-server-selection/

As I haven't read the above document and although I do have a sketchy 
appreciation of the issue, I'll withhold any comments on said (unread 
by me) document until I can get the time.  It looks interesting.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Discussing IPv4 address policy is like deciding what to eat on the Titanic.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Jun 2010 09:24:26 -0400

On Tue, Jun 15, 2010 at 09:11:26AM -0400, Edward Lewis wrote:
> documented promoted to RFC) that defined what split DNS is.  Without a 

If you were referring to draft-krishnaswamy-dnsop-dnssec-split-view
there, I'm not sure I agree.  My complaint at the time was that the
document was trying to do two things at once, and neither was really
fully there.  In particular, I thought (and still think) that a fairly
extensive discussion of split-view was needed, and that the different
approaches and so on needed to be enumerated in one document.  Then a
second document detailing when and how to do split-view with DNSSEC
(with that draft as the basis) would be good.  I was ready to work on
this, and in fact I did some work on it, but there didn't seem to be
much other enthusiasm.

I am still ready and willing to take this on.  I know that it's
fashionable to go "lalalala" every time split-brain^H^H^H^H^Hview
comes up, but it's a widely-used feature and I think we're remiss if
we don't document it.  If you and Suresh want to continue work on
this, so do I.

> The group has to define split DNS.

Completely agree.

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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Jun 2010 11:49:09 -0400

Comments on the draft.

In general, I think that architecturally a host has to treat each 
interface somewhat independently and then choose the interface to use 
for a network event.  That is, the host should not treat all the DNS 
servers equally regardless of the which interface they are serving.

You shouldn't choose to use an 802.11 connected DNS server to direct 
packets on your wired LAN if the latter also has a DNS server.  I am 
reacting to this section:

3.  DNS server selection procedure

The list of servers should be per interface.  Each interface can be 
contacted for it's best way to reach the remote end, and the 
interface that's best ought to be chosen and the DNS server that is 
selected has to be one on that interface.

>DISCUSS: Even more more known problem scenarios caused by split DNS
>for multi-homed hosts?

An indirect reaction.  Multihoming isn't a problem for the DNS, it's 
a problem for forwarding on the multihomed host.  There are good 
reasons to multihome, but that's a situation unique to those hosts - 
and the multihomed machine has better situational awareness of it's 
topology than any other device.

>   DISCUSS: What about those DNS servers that instead of
>   negative answer always return positive reply with an IP address of
>   some default HTTP server, which purpose is just to say 'authenticate'
>   or 'page not found'?  Maybe DNSSEC would help here, i.e. roll through
>   DNS servers until one provides a response that can be validated?

This issue is orthogonal to multihoming.

>   DISCUSS: When DNSSEC is used, in
>   split-DNS case it is probably possible to have authoritative answers
>   for both existence and non-existence of a record, depending on the
>   interface question is sent on?

Yep.  I think this is common.  I've seen machines that straddle the 
firewall boundary that will be getting the organization-internal zone 
on one interface and the organization-external zone on the other. 
The internal one usually has more hosts listed, hosts that are not 
visible externally.

This straddling is not the same as having multiple-media interfaces 
as mentioned elsewhere.  When straddling a boundary, names will be 
different by design.  When considering different media (wireless vs. 
wired) it could be both are supposed to be open to the internet and 
hence have the same names.

Finally I'd refer this problem to the issue of: once you have a pool 
of addresses for the desired endpoint, which do you choose?  The DNS 
can't help there, it doesn't know routing.  Similarly, the DNS can't 
distinguish a multi-homed host from two hosts at different IP 
addresses, so it's up to the host to deal with it.

---

From: <[email-masked]>
Date: Wed, 16 Jun 2010 16:21:47 +0200

Hi Edward, and thank you for comments.

The current state of multi-homed hosts do use interface specific DNS server lists, as described in https://datatracker.ietf.org/doc/draft-ietf-mif-current-practices/

If an interface is chosen before a DNS server there is no problem in selecting the DNS server... But if the DNS resolution is needed before interface selection can be made, there is a problem. Especially if the interface selection would be made based on destination's IP address.

The intent of this draft is to increase situational awareness of the MIF host in relation to which DNS server to contact to. There are other drafts that improve source/destination address selection logic (what happens after DNS resolution).

So from your point of view, it would be best for a host to contact DNS server's of all interfaces, and then use source/destination address selection to choose from the resulting list what address to actually use? Meaning you don't see this problematic:
--
   The resolver may optimize its behaviour by sending DNS requests in
   parallel to multiple DNS servers of different network interfaces, but
   this approach is not always practical:

   o  It may unnecessary trigger activation of a radio and thus increase
      battery consumption.

   o  It may unnecessarily reveal private names to third parties.

   o  It may be a privacy issue as it would reveal all names host is
      resolving to all DNS servers.
--

Best regards,

Teemu

From: ext Edward Lewis [mailto:[email-masked]]
Sent: 15. kesäkuuta 2010 18:49
To: [email-masked]; Savolainen Teemu (Nokia-D/Tampere)
Cc: [email-masked]
Subject: comments on draft-savolainen-mif-dns-server-selection

Comments on the draft.

In general, I think that architecturally a host has to treat each interface somewhat independently and then choose the interface to use for a network event.  That is, the host should not treat all the DNS servers equally regardless of the which interface they are serving.

You shouldn't choose to use an 802.11 connected DNS server to direct packets on your wired LAN if the latter also has a DNS server.  I am reacting to this section:

The list of servers should be per interface.  Each interface can be contacted for it's best way to reach the remote end, and the interface that's best ought to be chosen and the DNS server that is selected has to be one on that interface.

>DISCUSS: Even more more known problem scenarios caused by split DNS

An indirect reaction.  Multihoming isn't a problem for the DNS, it's a problem for forwarding on the multihomed host.  There are good reasons to multihome, but that's a situation unique to those hosts - and the multihomed machine has better situational awareness of it's topology than any other device.

>  interface question is sent on?

Yep.  I think this is common.  I've seen machines that straddle the firewall boundary that will be getting the organization-internal zone on one interface and the organization-external zone on the other.  The internal one usually has more hosts listed, hosts that are not visible externally.

This straddling is not the same as having multiple-media interfaces as mentioned elsewhere.  When straddling a boundary, names will be different by design.  When considering different media (wireless vs. wired) it could be both are supposed to be open to the internet and hence have the same names.

Finally I'd refer this problem to the issue of: once you have a pool of addresses for the desired endpoint, which do you choose?  The DNS can't help there, it doesn't know routing.  Similarly, the DNS can't distinguish a multi-homed host from two hosts at different IP addresses, so it's up to the host to deal with it.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 16 Jun 2010 14:13:21 -0400

I'm going to answer this in a general, architectural approach level, 
and not specific to particular issues.

At 16:21 +0200 6/16/10, <[email-masked]> wrote:

>So from your point of view, it would be best for a host to contact 
>DNS server's
>of all interfaces, and then use source/destination address selection to choose
>from the resulting list what address to actually use?

Not necessarily.  What I mean is that it is up to the multi-homed 
device to decide what interfaces are candidates (for the pending data 
transmission) and consult the DNS on each interface.  However, what 
one interface says is not necessarily valid for another, for example, 
if the address (I'll use v4 now just because it's quicker to type, 
however I know you are in the v6 mode) for a SMTP server is 127.1.2.3 
on wireless and 127.3.2.1 on wired, you can't then use 127.3.2.1 on 
the wireless.  No mixing and matching of the results.

>Meaning you don't see this problematic:

Yes, those are issues - for the multi-homed device.

The question (I believe) is whether split DNS is a problem for 
multihomed devices.  Yes, I think it is.  But that doesn't mean split 
DNS is the culprit.  Does that mean multi-homed devices are the 
problem then?  No.  Both split DNS and multi-homing are fine. 
However, there is a need for multi-homed devices to know how to deal 
with split DNS.  (And not vice versa.)

Why not vice versa?  My argument here isn't that coherent because I 
haven't spend enough time thinking it over.  Generally, multi-homing 
is a special case and the DNS serves a wide population that is mostly 
signal-homed. Yes, today my laptop qualifies as multihomed (the RJ-45 
port and the wireless card are active and at times I have a cable 
plugged in).  Still, the host behaves as single-homed (maybe the 
wireless hasn't found a SSID it can use).

In the future, as a device is multi-homed, it needs to deal with that 
fact locally.  It might decide not to use the 802.11 radio but use 
the GSM radio, or neither and use the Bluetooth.  But that choice 
will be made before worrying about what DNS server.  By the time it 
chooses what DNS server to use, the interface is picked.

An enlightened host might be very agile on the interface choice - as 
the 802.11 fades out the GSM is used with sessions flipping over to 
the new transport (that results from the new data link).  Again in 
this case, the flipping is done and then the DNS server is changed.

I guess I am saying, to a multi-homed device, what DNS server to use 
is the tail of the "what i/f to use" dog. 
[http://www.urbandictionary.com/define.php?term=the%20tail%20wagging%20the%20dog&defid=3285170]

Apologies if this isn't that clear.

---

From: <[email-masked]>
Date: Thu, 17 Jun 2010 14:51:33 +0200

Edward,

> transmission) and consult the DNS on each interface.  However, what

Yes, but how to decide that? Some information is required, and this draft proposes a way to cover DNS server selection component of the bigger problem.

> the wireless.  No mixing and matching of the results.

Right, host should use a learned address only on the interface it was learned on. That is part of source/destination address selection problematic covered by other drafts.

Here the problem is, which DNS server to talk to resolve "private.corporation.com".

> Yes, those are issues - for the multi-homed device.

That's the case we're looking at:)

> with split DNS.  (And not vice versa.)

Right, but how can they behave well in split DNS case if they are not told how to deal with the situation? E.g. told who knows what.

> wireless hasn't found a SSID it can use).

Yes, that behavior is very common current practice. However, at MIF WG we are looking to improve that in such a way host uses both WLAN, RJ-45, cellular, VPN tunnel, DSMIP tunnel, Teredo tunnel, and so on all at the same time.

A related scenario is multi-site, where a host has a single physical uplink network interface, but multiple routers on it. In such a case, DNS servers behind some routers may have information the DNS servers behind other routers do not have. 

> chooses what DNS server to use, the interface is picked.

This is the current practice, but it is changing. In the future, these devices use 802.11 and GSM at the same time. Use cases include MPTCP, offloading (e.g. browsing traffic over 802.11 and VoIP over GSM) and so on.

> this case, the flipping is done and then the DNS server is changed.

That is current practice. In the future the enlightened host keeps GSM open all the time and uses that for some traffic (e.g. for those that might benefit of address stability, or those that use cellular operator's services), while WLAN is used for "bulk" traffic when available. For faster download and browsing, the host may load content over both radios at the same time.

In addition, the host may have corporate VPN active, which should be used only for corporate traffic, not for bulk Internet access. (But this is of course policy dependent issue, split tunnel may not be allowed).

> [http://www.urbandictionary.com/define.php?term=the%20tail%20wagging%20the%20dog&defid=3285170]

I bet standards are being created for much smaller corners than this?-)

Anyhow, in Appendix A, if you checked, I describe also some behaviors hosts could apply even when  (and if) network is not explicitly supporting provisioning of this information. E.g. host can use search list options and prefixes as hints.

Teemu

---

From: <[email-masked]>
Date: Thu, 17 Jun 2010 14:55:33 +0200

Hi,

Obviously I'm interested in this work as well. 

If chairs approve, I would like to present the draft-savolainen-mif-dns-server-selection at dnsop's IETF#78 meeting. As a starting point for this discussion, or separately.

Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Andrew Sullivan
> Sent: 15. kesäkuuta 2010 16:24
> To: [email-masked]
> Subject: Re: [DNSOP] Split DNS problems for multi-interfaced hosts and
> a possible solution
> 
> a
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Jun 2010 13:44:56 -0400

At 14:51 +0200 6/17/10, <[email-masked]> wrote:

>Yes, but how to decide that?

That's a multi-homed device issue.  Not a DNS issue.  (This is a DNS 
mailing list.)  I am sure you are more on top of multi-homed device 
issues than I so I'll stick to the DNS implications.

I think the importance of "DNS server selection" is overstated.  The 
DNS server you use isn't that important - in fact DNS is supposed to 
hide what server is used.  DNS is a client-cache-server protocol. 
The cache is essentially a broker for getting the authoritative 
answer.  A client (stub) usually chooses a cache by policy and lets 
the "server" be selected via the broker's/cache's magic.

Perhaps the misunderstanding is that split DNS isn't designed to just 
give out different answers based on location but give out answers 
that are optimized based on location, with the optimization function 
being some subjective thing.
Optimized may mean better routing, network traffic engineering, or 
simply that the network is segmented and the host straddle what would 
be an air (or firewall) gap in it.  It isn't the case that subnet 1 
is told address A and subnet 2 is told address B arbitrarily.  It may 
be the case that address A cannot be reached via interface on subnet 
2.

Unfortunately, split DNS isn't defined, so you can't be told how to 
deal with it in a standard manner ("isn't defined" within the IETF 
that is). ;)

>In addition, the host may have corporate VPN active, which should be used
>only for corporate traffic, not for bulk Internet access. (But this is of
>course policy dependent issue, split tunnel may not be allowed).

This remark is one that reminded me not to dive into the multi-homed 
aspect of this.  You are certainly on top of the issue.  I can 
sympathize - what you are facing is very similar to the problem with 
scoped addresses in IPv6, that is, site-local and uniquely global 
addresses.   Knowing which to use is a hard thing, site-locals were 
removed from the IPv6 addressing plan.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Jun 2010 14:06:06 +1000

There are basically two reasons to have split DNS
1.  to prevent unreachable/ambigious addresses being used at the wrong time
2.  to hide "internal" names

#1 can be addresses by minor changes to A/AAAA records to include scope
   information and then make getaddrinfo scope aware().  This would allow
   link-locals to be added to the DNS.
#2 is basically security theatre.

I'd love to be able to have something like this

drugs.dv.isc.org.    SA	      192.168.191.236 dv.isc.org.
drugs.dv.isc.org.    SAAAA    fd92:7065:b8e:0:214:22ff:fed9:fbdc dv.isc.org.
drugs.dv.isc.org.    SAAAA    fe80::214:22ff:fed9:fbdc wired.dv.isc.org.
drugs.dv.isc.org.    SAAAA    2001:470:1f00:820:214:22ff:fed9:fbdc .

and only have hosts with scope wired.dv.isc.org see fe80::214:22ff:fed9:fbdc,
while host of scope dv.isc.org would see fd92:7065:b8e:0:214:22ff:fed9:fbdc and
192.168.191.236, and everyone would see 2001:470:1f00:820:214:22ff:fed9:fbd.

RA's (and a equivalent mechanism for IPv4) would advertise scope names
"wired.dv.isc.org", "dv.isc.org" and "." allowing getaddrinfo() to know
which addresses to return and fill in appropriate scope informatin in
sockaddr_in6.sin6_scope_id for fe80::214:22ff:fed9:fbdc..

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: <[email-masked]>
Date: Fri, 18 Jun 2010 10:15:29 +0200

I'm in this list to clarify if this technology proposal causes issues for DNS:) But if the problem is seen as a host issue, not DNS, then this probably does not cause harm?

So from DNS system point of view, do you see any issues if some networks would provide policies for some hosts to perform DNS server selection wisely, in deployments where split-DNS is causing problems or is desired? 

I guess split DNS means different things in different places.. sometimes it is just optimization, sometimes the IP address received from interface 1 is not reachable over interface 2, sometimes the service is different (depending whether a site is accessed from intranet/extranet).

Forbidding split-DNS probably is as possible as forbidding NATs:)

Best regards,

Teemu

> Sent: 17. kesäkuuta 2010 20:45
> To: Savolainen Teemu (Nokia-D/Tampere)
> Cc: [email-masked]; [email-masked]
> Subject: RE: comments on draft-savolainen-mif-dns-server-selection
>

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Jun 2010 07:42:13 -0400

At 10:15 +0200 6/18/10, <[email-masked]> wrote:
>I'm in this list to clarify if this technology proposal causes 
>issues for DNS:)
>But if the problem is seen as a host issue, not DNS, then this probably does
>not cause harm?

The problem in such discussions is "harm to whom?"  The harm is that 
is we incorrectly solve this, we harm the overall architecture of the 
Internet.  The issues I read pertained to the host, not the DNS, 
hence, to prevent harm to the architecture, the solution lies in the 
host.

>So from DNS system point of view, do you see any issues if some networks
>would provide policies for some hosts to perform DNS server selection
>wisely, in deployments where split-DNS is causing problems or is desired?

There are a number of problems with the question.  One, split-DNS 
isn't defined and that hinders talking about policies about its use. 
Two, I don't understand "DNS server selection" as something that one 
does.  Three, split-DNS is a thing that usually is only introduced 
where it is a solution to problems, if it was causing problems it 
would be removed.

>I guess split DNS means different things in different places.. sometimes it
>is just optimization, sometimes the IP address received from interface 1 is
>not reachable over interface 2, sometimes the service is different
>(depending whether a site is accessed from intranet/extranet).

And that is why there's no clear answer.  There's no agreed 
definition over split-DNS.

>Forbidding split-DNS probably is as possible as forbidding NATs:)

Yes, but I take it the other way.  In the field both are necessary 
even if according to the theoretical model of networking both are 
abhorrent.  (The model is wrong.)  I'd no more "forbid" either than 
forbid gravity.

The World Cup would be more fun if they didn't interrupt it with soccer games.

---

From: <[email-masked]>
Date: Tue, 22 Jun 2010 11:52:11 +0200

Hi,

> hence, to prevent harm to the architecture, the solution lies in the

I see this rather so that a network causing issues for the host ought to provide assistance for hosts to overcome those issues.

>From 10000 feet view some DNS servers have information others do not. Isn't that enough of high level definition of split-DNS? 

The DNS server selection is a mandatory feature for every host that receives more than 1 DNS server address from any sources. In simplest case it just means overwriting /etc/resolv.conf with the latest info received from anywhere.. 

There was a good email "two reasons to have split-DNS" by Mark Andrews last Friday. Won't those reasons remain valid reasons even in the presence of multihomed hosts, hence unlikely to disappear any time soon? Hence need to find a patch to the problem the solution caused. 

> definition over split-DNS.

Right, but doesn't split-DNS always mean some DNS servers have some information others do not?

What other criteria of selecting a DNS server could be in addition to FQDN and IP-addresses (ranges, subnets)?

Best regards,

Teemu

---

From: Edward Lewis <[email-masked]>
Date: Tue, 22 Jun 2010 08:15:51 -0400

At 11:52 +0200 6/22/10, <[email-masked]> wrote:
>I see this rather so that a network causing issues for the host ought
>to provide assistance for hosts to overcome those issues.

When I hear this, I think of the following analogy:

Because of foot surgery, I have to wear special inserts to my shoes. 
It would be good if all the shoes would have the insert so that I 
wouldn't have to remove and insert them each time I change shoes. 
But building in the support I need to the shoes means that others 
then can't use my shoes.

Infrastructure shouldn't try to cover up for host or application 
specific issues.

>From 10000 feet view some DNS servers have information others do not. Isn't
>that enough of high level definition of split-DNS?

I wouldn't buy that definition.  In some cases, it's different 
information - the address for some name may be in both splits but be 
different.

>The DNS server selection is a mandatory feature for every host that receives
>more than 1 DNS server address from any sources. In simplest case it just
>means overwriting /etc/resolv.conf with the latest info received from
>anywhere..

That's news to me.

It is a mistake for any application to know that there are multiple 
DNS servers available, leave it to the DNS protocol to handle that. 
The reason for multiple servers is resilience, based on the reliance 
on UDP, and not for "feature shopping."

Maybe there is an overly optimistic impression of what you can do 
knowing you have multiple DNS servers.

>There was a good email "two reasons to have split-DNS" by Mark Andrews
>last Friday. Won't those reasons remain valid reasons even in the presence
>of multihomed hosts, hence unlikely to disappear any time soon? Hence need
>to find a patch to the problem the solution caused.

There are more reasons than just the two, independent of multi-homed 
devices.  My theme is that this is a multi-homed device problem, not 
a DNS problem.

>and IP-addresses (ranges, subnets)?

Target server availability and load.  Routing traffic to the data 
center that is active.  Routing traffic to where people are staffed. 
General traffic engineering.  Dynamically creating answers to 
questions.  And so on.

Note - not all agree with the motives.  I'm just saying that they are in play.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: <[email-masked]>
Date: Tue, 22 Jun 2010 23:08:09 +0200

> But building in the support I need to the shoes means that others

The hospital that does surgery on my foot probably gives me those inserts as well.

The network that messes my DNS should also give me the assistance required to manage.

There is no intent to confuse those single-homed hosts walking by the surgery room in ignorance, they just ignore the inserts they see waiting on the desk.
 
> Infrastructure shouldn't try to cover up for host or application

Infrastructure shouldn't mess with host or applications either:)

> information - the address for some name may be in both splits but be

Different information as I said. Also in that case the host should be pointed to ask from correct name server. E.g. corporation deploying split-DNS might want to configure hosts running their VPN clients to send DNS questions relating to "*.corporate.com" to DNS servers running behind VPN. That way they would learn the internal names, and communicate with the servers over the VPN. Randomly picking a DNS server might lead host to learn the external address, and hence contact to wrong destination (provided split tunnel is allowed).

> on UDP, and not for "feature shopping."

Where does DNS protocol start? The application should remain clueless for sure, but once interface agnostic app calls gethostbyname() on multi-homed host, it would be good if the answer would be the desired one.

The core DNS protocol is unable to handle split-DNS..

> devices.  My theme is that this is a multi-homed device problem, not

It is not a DNS protocol problem I agree. But from host point of view it is "network" originated (configuration?) problem, the "network" ought to sort out.

Best regards,

Teemu

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Jun 2010 09:29:26 -0400

>The hospital that does surgery on my foot probably gives me those 

What was unclear in the analogy is that the inserts are custom made, 
from a prescription.  So, no, the hospital would not likely have the 
(same) inserts.

>Where does DNS protocol start? The application should remain clueless for
>sure, but once interface agnostic app calls gethostbyname() on multi-homed
>host, it would be good if the answer would be the desired one.

The "service API" for DNS is, when dumbed down, this - for a given 
name and type, here is the data that corresponds.   Internal to this 
is how the data is found or determined - query redirection via CNAME, 
DNAME, error handling due to UDP as a transport, referrals from one 
authority to another, synthesis of the response from either "rote 
memory" or rules for construction, and ultimately even the authority 
server's choice.

>The core DNS protocol is unable to handle split-DNS..

Well, we need to define split DNS.

Still, I have had 3 employers since 1996 (I think) and all have use 
of DNS configurations that handed out different information based on 
whether you were in the office or on the global public Internet. 
 From what I have observed, the core protocol is quite capable of 
supporting "split-DNS".

The "theoretical" observation that got me to accept split-DNS was 
that split-DNS appears to queries to be no different from rapidly 
updating a zone.  If you ask at t=0 for the address of a server and 
get 192.0.2.3 and then another person asks the same question at t=10 
and gets 192.0.2.125 - it is indistinguishable whether:

1) The zone was updated
1a) The zone wasn't fully propagated to all authoritative servers
2) The authority was instructed to hand out different answers to 
different people
3) Before DNSSEC: There was a forgery
and probably a few other possible reasons.

About 1a - when a master issues a new zone, prior to NOTIFY and less 
so with it, there is a chance that one slave would have an older 
serial number than another.  The protocol didn't not have a problem 
with this, there was no requirement to "lock" the authorities before 
answering queries again, and so on.

I realize that that situation is not what you mean by split-DNS but 
when looking at queries and responses, the situations are identical. 
The difference you probably have in mind is visible when looking at 
the intent and duration, etc., but that's invisible to the 
query-response exchange.  I know - I used to try to reverse engineer 
broken set ups and ultimately realized it can't be done without 
contacting the operator directly.