Subject: [dnsop] Implementation of stub DNS Server

From: Guido Roeskens <[email-masked]>
Date: Fri, 12 Aug 2005 17:06:17 +0200

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

---

From: Mark Andrews <[email-masked]>
Date: Sun, 14 Aug 2005 11:52:00 +1000

> 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.

	Mark

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 23 Aug 2005 18:12:02 -0400

>	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

.