2. Why Web services don't have entries like MX hosts do. Why not be able to
set preferences and fall over hosts?
That is exactly RFC 2052, but why don't you try convincing everyone to
deploy that right now? 
-Phil
2. Why Web services don't have entries like MX hosts do. Why not be able to
set preferences and fall over hosts?
Err, they do. Here's how to set it up: These balance the load, and if one
machine is down, any browser which handles multiple A records properly will
still fail over to the other machine.
www IN CNAME www1.av8.com.
IN CNAME www2.av8.com.
www1 IN A 198.3.136.144
IN A 208.156.100.250
www2 IN A 208.156.100.250
IN A 198.3.136.144
That is exactly RFC 2052, but why don't you try convincing everyone to
deploy that right now?
Because its not necessary. Just put in multiple A records, for multiple
hosts which service the same web pages.
(What? Your browser won't use multiple A records? Well, in that case, it
probably will be a much longer time before it supports a new DNS record
type.)
--Dean
Multiple CNAMEs are not supported by all DNS servers and are in fact "turned
off" by default in BIND 8. Multiple CNAMEs violates DNS protocol-
) At 2:51 PM -0400 6/3/98, Phillip Vandry wrote:
) >> 2. Why Web services don't have entries like MX hosts do. Why not be able to
) >> set preferences and fall over hosts?
) Err, they do. Here's how to set it up: These balance the load, and if one
) machine is down, any browser which handles multiple A records properly will
) still fail over to the other machine.
)
) www IN CNAME www1.av8.com.
) IN CNAME www2.av8.com.
That's a Very Bad Idea(tMS). CNAMEs are used as aliases, direct mappings.
For the same reason you can't CNAME a zone's root to something else
(meaning, if I am setting up the zone map for n.ml.org, I can CNAME
web.n.ml.org to narnia.n.ml.org, but I can't CNAME n.ml.org to
narnia.n.ml.org, nor can I CNAME n.ml.org to ftp.microsoft.com, or any
other host), you cannot use multiple CNAMEs. You can *physically* CNAME
multiple times, but you're likely to break things, as it's against the
rules. What you're in fact doing is aliasing one host to two different
ones, which doesn't make sense (because a CNAME says that ThisHost is
actually just a pointer to ThatHost).
) www1 IN A 198.3.136.144
) IN A 208.156.100.250
) www2 IN A 208.156.100.250
) IN A 198.3.136.144
That seems rather redundant. Just stick www1's IN A's into www, and forget
about www1 and www2 and funky multiple CNAMEing. There's no need to handle
rotations of the IN A's yourself--BIND, at least, does it all for you.
Do an nslookup on irc.dal.net a couple times, or us.undernet.org. Each
time you do it, the IP's are shifted over to the left by one. Hence, a
user doing /server us.undernet.org might get connected to
LasVegas.NV.US.Undernet.org, while the next person who does /server
us.undernet.org will get connected to Arlington.VA.US.Undernet.Org.
) (What? Your browser won't use multiple A records? Well, in that case, it
) probably will be a much longer time before it supports a new DNS record
) type.)
"Supporting" multiple IN A's shouldn't be necessary for a client to take
advantage of multiple IN A's. Since the IN A's are rotated, load balancing
is implemented at the nameserver level. The client should just always
connect to the first IN A given to it.
Phillip Vandry wrote:
> 2. Why Web services don't have entries like MX hosts do. Why not be able to
> set preferences and fall over hosts?That is exactly RFC 2052, but why don't you try convincing everyone to
deploy that right now?
To start, RFC 2052 (the SRV RR idea) is extremely ill-conceived. It's
smallest flaw is that it requires you to specify RR's by service and
makes some (I think) invalid assumptions about services being requested
on the same port consistently. However those problems are eclipsed by
the fact that it requires client authors to adapt to the new format. As
someone else commented, client authors have yet to adequately deal with
multiple A records, so the hopes of them working in the capability to
deal with a completely new RR are small.
Dean Anderson wrote:
www IN CNAME www1.av8.com.
IN CNAME www2.av8.com.www1 IN A 198.3.136.144
IN A 208.156.100.250
www2 IN A 208.156.100.250
IN A 198.3.136.144
This works, however it is functionally equivalent to:
www IN A 198.3.136.144
IN A 208.156.100.250
which is fine if you want to balance the load equally between these two
servers (although obviously the CNAME's should be avoided in the simple
case).
Chris Cappuccio wrote:
Multiple CNAMEs are not supported by all DNS servers and are in fact "turned
off" by default in BIND 8. Multiple CNAMEs violates DNS protocol-
The config option in BIND 8 refers to names in the zone files served by
that server having more than one CNAME. BIND 8 has no problems resolving
names with multiple CNAME's from remote servers with or without that
option. Also, multiple CNAME's are not a violation of the letter of the
law, although they are possibly a violation of its spirit. What the
RFC's DO say is that you cannot have a CNAME plus another type of RR.
This is to avoid the possibility of having conflicting records of the
same type (like MX or A records).
Daniel Reed wrote:
) At 2:51 PM -0400 6/3/98, Phillip Vandry wrote:
) >> 2. Why Web services don't have entries like MX hosts do. Why not be able to
) >> set preferences and fall over hosts?
) Err, they do. Here's how to set it up: These balance the load, and if one
) machine is down, any browser which handles multiple A records properly will
) still fail over to the other machine.
)
) www IN CNAME www1.av8.com.
) IN CNAME www2.av8.com.
That's a Very Bad Idea(tMS). CNAMEs are used as aliases, direct mappings.
Most of the time, yes.
For the same reason you can't CNAME a zone's root to something else
(meaning, if I am setting up the zone map for n.ml.org, I can CNAME
web.n.ml.org to narnia.n.ml.org,
Right.
but I can't CNAME n.ml.org to
narnia.n.ml.org, nor can I CNAME n.ml.org to ftp.microsoft.com, or any
other host),
Why not?
n.ml.org. IN CNAME ftp.microsoft.com.
would be perfectly valid. Of course uncle bill might not like it much.
you cannot use multiple CNAMEs. You can *physically* CNAME
multiple times,
I'm not sure I understand the distinction you're trying to make here.
but you're likely to break things, as it's against the rules.
See above.
What you're in fact doing is aliasing one host to two different
ones, which doesn't make sense (because a CNAME says that ThisHost is
actually just a pointer to ThatHost).
Under usual situations, no it wouldn't make sense. However in the load
balancing situation it's the only way to go for more complex setups.
Do an nslookup on irc.dal.net a couple times, or us.undernet.org. Each
time you do it, the IP's are shifted over to the left by one.
Well I'll take that as a compliment, since I am DALnet's hostmaster.
However I regret to inform you that I did use the CNAME hack to fine
tune our load balancing. I'd also like to point out that the IP's in a
true round-robin setup (as manifest with BIND, et al) will be returned
randomly, not in a rotate once cycle. The exception to this is if you
are on the same subnet as one of the IP's, in which case that IP (or
IP's) will be favored.
"Supporting" multiple IN A's shouldn't be necessary for a client to take
advantage of multiple IN A's. Since the IN A's are rotated, load balancing
is implemented at the nameserver level. The client should just always
connect to the first IN A given to it.
This depends on whose resolver you're using. With BIND you should be in
good shape. With, say, windows 95 you're in deep tapioca because
although it caches all the IP's it receives it always returns them in
the same order. (And no, I don't need anyone to tell me that this is
braindead behaviour. The safest way to get the desired behaviour out
of the client is to code specifically the behaviour you want.
Now, why would you want to use multiple CNAME's? Simple, it gives you
much greater flexibility in how you control the load assigned to various
machines. Say you want one machine to get 3 times as much load as
others. Because BIND compacts A addresses you couldn't simply do:
www IN A 111.111.111.111
IN A 111.111.111.111
IN A 111.111.111.111
IN A 222.222.222.222
IN A 333.333.333.333
BIND would return just the 3 discreet addresses. What would work is:
www IN CNAME www1
IN CNAME www2
IN CNAME www3
www1 IN A 111.111.111.111
IN A 222.222.222.222
IN A 333.333.333.333
www2 IN A 111.111.111.111
www3 IN A 111.111.111.111
The astute student will notice that the 111.111.111.111 address won't
get exactly 3 times as much traffic. In fact, calculating exact
percentages is a fascinating mathematical problem, especially when you
are dealing with lots of addresses. You can find more info on this
technique in the BIND FAQ.2of2, question 5.11. The FAQ is included in
BIND 8's -doc package in the misc section amongst other places.
I wanted to respond to this thread for several reasons. First, DNS is
an operational issue, and as has often been mentioned here is difficult
to do right and very hard to do well. Also, there was a lot of
misinformation contained in this thread, and I wanted to set some of the
old and glorious bits to rest. And, frankly I thought it was a good
opportunity to demonstrate my brilliance to potential customers. If
you need load balancing or other DNS help I'm available for a reasonable
rate.
Finally, if you plan to disagree with anything in this post, please
quote chapter and verse from the relevant RFC. I've spent a lot of time
studying this topic and am quite sure of my facts.
Enjoy,
Doug
In article <35788244.55A2D71@san.rr.com>,
> For the same reason you can't CNAME a zone's root to something else
> (meaning, if I am setting up the zone map for n.ml.org, I can CNAME
> web.n.ml.org to narnia.n.ml.org,Right.
> but I can't CNAME n.ml.org to
> narnia.n.ml.org, nor can I CNAME n.ml.org to ftp.microsoft.com, or any
> other host),Why not?
Because you cannot have CNAME RRs along with any other RR, including
NS and SOA. DNSSEC RRs are excepted.
Finally, if you plan to disagree with anything in this post, please
quote chapter and verse from the relevant RFC. I've spent a lot of time
studying this topic and am quite sure of my facts.
RFC 2181 section 10.1.
the fact that it requires client authors to adapt to the new format. As
someone else commented, client authors have yet to adequately deal with
multiple A records, so the hopes of them working in the capability to
deal with a completely new RR are small.
Actually I'm not so sure - I can well imagine that a reasonably well
publicised change in how DNS works in order to make "the web better" would
probably get adopted more readily in browsers than mere conformance to well
documented, already existent RFCs that are currently flouted.
Manar
) Daniel Reed wrote:
) > but I can't CNAME n.ml.org to
) > narnia.n.ml.org, nor can I CNAME n.ml.org to ftp.microsoft.com, or any
) > other host),
) Why not?
) n.ml.org. IN CNAME ftp.microsoft.com.
) would be perfectly valid. Of course uncle bill might not like it much.
First of all, I would have a CNAME along with extra information (at the
very bare minimum, my SOA and NS list).
I just modified my zone map for random.ml.org. and removed the IN A and IN
MX records, then CNAME'd it to n.ml.org.:
[SOA record snipped]
IN NS ns.n.ml.org.
IN NS urtho.shorecrest.org.
; IN A 209.49.57.5
; IN MX 0 mail.n.ml.org.
; IN MX 5 mx5.mhv.net.
; IN MX 10 mx10.mhv.net.
IN CNAME n.ml.org.
Jun 5 19:57:37 narnia named[10544]: random.ml.org has CNAME and other data (invalid)
Jun 5 19:57:37 narnia last message repeated 2 times
So, I guess the simplest answer to your question is because BIND spanked
me when I tried to do that.
) > you cannot use multiple CNAMEs. You can *physically* CNAME
) > multiple times,
) I'm not sure I understand the distinction you're trying to make here.
I was just trying to avoid someone saying "hey, pico let me add in the
second CNAME!!!!!" or something equally lame. You can physically have
multiple CNAMEs, but you're not allowed to.
) > What you're in fact doing is aliasing one host to two different
) > ones, which doesn't make sense (because a CNAME says that ThisHost is
) > actually just a pointer to ThatHost).
) Under usual situations, no it wouldn't make sense. However in the load
) balancing situation it's the only way to go for more complex setups.
)
) > Do an nslookup on irc.dal.net a couple times, or us.undernet.org. Each
) > time you do it, the IP's are shifted over to the left by one.
) Well I'll take that as a compliment, since I am DALnet's hostmaster.
) However I regret to inform you that I did use the CNAME hack to fine
) tune our load balancing.
Ah, so that explains why nslookup barfs when I try to lookup irc.dal.net
repeatedly. I thought it was just because of some peculiarity in your
setup (well, I guess it was!).
) I'd also like to point out that the IP's in a
) true round-robin setup (as manifest with BIND, et al) will be returned
) randomly, not in a rotate once cycle.
Well, if that is true, then it's because of your setup. BIND will rotate
IPs once per query, and that's documented behaviour. I guess I should have
just used us.undernet.org. as the example of a proper IN A round robin,
which is done using multiple IN A's, and also exhibits the shift-each-
host-to-the-left behaviour.
For an easier to see example, nslookup nanog.random.ml.org a couple times.
Name: nanog.random.ml.org
Addresses: 1.1.1.1, 2.2.2.2, 3.3.3.3, 4.4.4.4
5.5.5.5
Name: nanog.random.ml.org
Addresses: 2.2.2.2, 3.3.3.3, 4.4.4.4, 5.5.5.5
1.1.1.1
Name: nanog.random.ml.org
Addresses: 3.3.3.3, 4.4.4.4, 5.5.5.5, 1.1.1.1
2.2.2.2
Name: nanog.random.ml.org
Addresses: 4.4.4.4, 5.5.5.5, 1.1.1.1, 2.2.2.2
3.3.3.3
...
) Finally, if you plan to disagree with anything in this post, please
) quote chapter and verse from the relevant RFC. I've spent a lot of time
) studying this topic and am quite sure of my facts.
I'd rather come up with evidence as opposed to rhetoric, but if you
insist...
Well, I downloaded bind-8.1.2-doc.tar.gz, but I don't really have the time
currently to look through it to find out specific examples in the
documentation.
Michael Shields wrote:
In article <35788244.55A2D71@san.rr.com>,
> > For the same reason you can't CNAME a zone's root to something else
> > (meaning, if I am setting up the zone map for n.ml.org, I can CNAME
> > web.n.ml.org to narnia.n.ml.org,
>
> Right.
>
> > but I can't CNAME n.ml.org to
> > narnia.n.ml.org, nor can I CNAME n.ml.org to ftp.microsoft.com, or any
> > other host),
>
> Why not?Because you cannot have CNAME RRs along with any other RR, including
NS and SOA. DNSSEC RRs are excepted.
True, the example was a little fuzzy. If n.ml.org is the origin of that
zone then no, you can't add a CNAME for it. My point was that if it's
valid to point a name at a CNAME there is nothing wrong with pointing it
to one outside the zone, which is a common misconception. Sorry for the
confusion.
> Finally, if you plan to disagree with anything in this post, please
> quote chapter and verse from the relevant RFC. I've spent a lot of time
> studying this topic and am quite sure of my facts.RFC 2181 section 10.1.
Sorry I wasn't clear. I meant that you should actually quote the
material you want to refer to. I can't find any RFC 2181 either at
ftp://rs.internic.net/rfc/ or ftp://ftp.ietf.org/. If you would be so
kind as to quote exactly what you are referring to and provide a URL so
that I can check out the context I'd appreciate it.
Thanks,
Doug
Daniel Reed wrote:
First of all, I would have a CNAME along with extra information
Yes, I clarified that in my previous post, sorry for the confusion.
) Well I'll take that as a compliment, since I am DALnet's hostmaster.
) However I regret to inform you that I did use the CNAME hack to fine
) tune our load balancing.
Ah, so that explains why nslookup barfs when I try to lookup irc.dal.net
repeatedly.
A) Define "barfs." B) nslookup has peculiarities of its own, dig is a
much better tool. C) I never have any problems with it so I'd be curious
to know what you mean.
) I'd also like to point out that the IP's in a
) true round-robin setup (as manifest with BIND, et al) will be returned
) randomly, not in a rotate once cycle.
Well, if that is true, then it's because of your setup. BIND will rotate
IPs once per query, and that's documented behaviour.
Chapter and verse? Rotate yes, rotate left one cycle (I'm 98% sure)
no.
For an easier to see example, nslookup nanog.random.ml.org a couple times.
I strongly suspect that the behavior you're seeing is due to the small
sample set. Try it with 10 IP's or more. Also, I was speaking
specifically about how the server answers queries. You have a TTL of 8
hours, after the first answer you're getting resolver cache.
) Finally, if you plan to disagree with anything in this post, please
) quote chapter and verse from the relevant RFC. I've spent a lot of time
) studying this topic and am quite sure of my facts.
I'd rather come up with evidence as opposed to rhetoric, but if you
insist...Well, I downloaded bind-8.1.2-doc.tar.gz, but I don't really have the time
currently to look through it to find out specific examples in the
documentation.
I'll be here.
Doug
ftp://ftp.isi.edu/in-notes/rfc2181.txt
10.1. CNAME resource records
The DNS CNAME ("canonical name") record exists to provide the
canonical name associated with an alias name. There may be only one
such canonical name for any one alias. That name should generally be
a name that exists elsewhere in the DNS, though there are some rare
applications for aliases with the accompanying canonical name
undefined in the DNS. An alias name (label of a CNAME record) may,
if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
other data. That is, for any label in the DNS (any domain name)
exactly one of the following is true:
+ one CNAME record exists, optionally accompanied by SIG, NXT, and
KEY RRs,
+ one or more records exist, none being CNAME records,
+ the name exists, but has no associated RRs of any type,
+ the name does not exist at all.
Stephen
Studded wrote:
Stephen Sprunk wrote:
ftp://ftp.isi.edu/in-notes/rfc2181.txt
10.1. CNAME resource records
[snip]
That is, for any label in the DNS (any domain name)
exactly one of the following is true:+ one CNAME record exists, optionally accompanied by SIG, NXT, and
KEY RRs,
+ one or more records exist, none being CNAME records,
+ the name exists, but has no associated RRs of any type,
+ the name does not exist at all.
Thanks, someone else was kind enough to send me the ref last night too.
This RFC has been on the standards track for about a year, and isn't
moving forward (that I've seen). I follow most of the standards track
stuff but not all of it.
In any case, all this does is reinforce Paul Vixie's statement in the
FAQ that I quoted previously. Basically he said that multiple CNAME's
are allowed now, but may go away at some point in the future. That
doesn't mean it's not a valid tool now, especially since there aren't
any better tools yet.
Thanks for the quote,
Doug
manar@ivision.co.uk (Manar Hussain) writes:
Actually I'm not so sure - I can well imagine that a reasonably well
publicised change in how DNS works in order to make "the web better" would
probably get adopted more readily in browsers than mere conformance to well
documented, already existent RFCs that are currently flouted.
i imagined that, which is why i contributed to RFC 2052. but i was wrong.
the browser vendors don't think of this as one of their important problems.
Actually I'm not so sure - I can well imagine that a reasonably well
publicised change in how DNS works in order to make "the web better" would
probably get adopted more readily in browsers than mere conformance to well
documented, already existent RFCs that are currently flouted.i imagined that, which is why i contributed to RFC 2052. but i was wrong.
the browser vendors don't think of this as one of their important problems.
The key thing missing here is the presentation. You either needed it to
somehow be picked up by the more press ("better web access coming") or
convince Netscape/MS they almost came up with it themselves (at which point
they will probably do just about anything that they could then claim makes
them better :).
Manar