Mark Andrews wrote:
Hello,
I hope this is the right list for my question.
(the implemnetation in question is closed source and
no mailing list exists for it. I need "quality input"
on the issue to send to the manufacturer so that they
will implement their "DNS server implementation" as
correct as possible.)
Maybe it would also make sense to put the information
asked here in a "best practice" document on the issue
of devices implementing such "stub DNS server implementation".
----
Many load balancers implement some DNS functionality,
but their implementation is very limited.
Example:
www.example.com gets delegated to lb1.example.com and
lb2.example.com, which are load balancers.
In Zone file terms:
www.example.com. IN NS lb1.example.com.
www.example.com. IN NS lb2.example.com.
In therory the load balancer should have a "zone" for
www.example.com with SOA records, NS records etc.
However they typically just implement A records
(maybe some exist which also can serve A6 or AAAA records)
Now to the question:
How should the load balancer react to queries?
To most of the queries the load balancer must send back
"empty answers". It sends back the question with the
flags corrected, an empty answer, authoritative,
and additional section.
How should it react "correctly" to queries for NS entries
and SOA entries? (These RR types are and will NOT
be implemented on the load balancer)
Should it send back NOTIMP (NOTIMPL in Bind) answers?
Or should it also send back empty answers?
I assume, a solution which sends back "REFUSED" to a
query will be wrong for any type of query.
What should be sent back for other classes (like CHAOS)?
empty answers, NOTIMP answer or anything else?
(REFUSED should be ok in this case)
The load balancers also don't implement ANY '*' queries.
Am I right to assume that 'NOTIMP' would be the right answer?
Thanks for any Input on the issue.
Kind regards
Guido Roeskens
Swisscom Fixnet AG
Bluewin
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
I really don't understand this attitude. It takes almost no
extra work to handle SOA, NS and ANY queries. Basically you
are asking us to say that you don't have to follow RFC 1034
and RFC 1035. Sorry you are not going to get that from me
atleast.
I really don't understand why LB vendors don't implement
returning cachable negative answers and EDNS. Basically
the LB clients buy the LB to get quicker responses for
their clients yet failure to implement both of these leads
to lot of extra queries and hence extra resolution time.
I concur with Mark's statement. The LB vendors need to step up to the
plate and provide more complete DNS implementations. At least up to the
level of 1034/1035. Trying to come up with "reasonable" RCODEs for
shoddy DNS implementations just gives them an excuse to not improve them.
Having said that, however, I think much of the pain and messiness
associated with DNS-based load-balancing can be mitigated operationally
by taking an RFC 2317-like approach, as we have. Delegate a single zone
for each set of load-balancers (e.g. lb.example.com), and then just make
all of the load-balanced names aliases to corresponding names under the
relevant delegated zone(s), according to some consistent convention. In
our case, the convention is to change all dots to dashes (leaving them
as dots makes it look like someone forgot a trailing period in the zone
file). So, for example, www.hemi.com is an alias to
www-hemi-com.us1.lb.dcx.com, where us1.lb.dcx.com is delegated to a
particular set of load-balancers. In this way, we only have 1 "zone" per
load-balancer set. While I hesitate to recommend a local convention as a
Best Practice for the entire Internet, my thought is that if more folks
set things up this way, there would only be a need for a single SOA and
a single NS RRset for any given load-balancer, and at that minimal
level, maybe the LB vendors would find it an easier pill to swallow.
Once they implement SOA, then of course negative cacheability wouldn't
be much harder to implement.
That wouldn't help the EDNS situation, however.
As for ANY queries, I know at least one big LB vendor has improved their
ANY query support in response to our complaints, as a fairly large
customer of theirs. Don't know about other LB vendors though...
- Kevin
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
