Michael Milligan wrote:
Mark Andrews wrote:
In message <4a4dd8a6.70...@bluewin.ch>, "Martin.Wismer." writes:
Hello Mark, Hello Jittinan,
thank you for informing us/me, that bluewin.ch shod do some
improovements in our dns-settings.
Yes, the bluewin.ch is on 4 dns-bind-Server's, but some Entries,
www.bluewin.ch, are delegated to 4 Global-Site-Selectors which act as
DNS-Server's.
Mark:
If I understand you correctly, the GSS should also return SOA and NS
Records for the domain www.bluewin.ch.
Could you confirm, that's, what a propper delegation would mean?
Yes. That is what should be returned when a SOA or NS
query is made for www.bluewin.ch to the GSS servers.
My gawd... say it ain't so. I opened bugs for this with Cisco way back
when it was called Distributed Director (circa 1996). So sad to see
this is /still/ broken and that they just don't care about fixing it.
And I bet it still does improper "bouncing" (referrals) back to a
different set of servers for resolving records it doesn't have (e.g.,
MX). All these (mis)behaviors regularly causes problems for
troubleshooters. And I can just imagine how they will deal with DNSSEC...
I think they've been promising a "fully-featured DNS implementation" for
a few releases now.
I'm not sure what you mean by "bouncing referrals". We use a "shadow"
zone behind the GSSes to provide the necessary SOA/NS apex records.
It's ugly, but it works, kinda...
One compromise we had to make is to put a "dummy" wildcard record in the
shadow zone, to prevent potentially-troublesome NXDOMAIN responses from
ever being generated by the shadow-zone servers and passed back
verbatim. It would have been nicer if the GSS could understand that
(NXDOMAIN from shadow zone + records in GSS for the name -> NODATA back
to the client), but hey, I guess that's asking too much.
Even QTYPE=* queries work, if I recall our conformance testing
correctly, with the GSS being at least smart enough to "merge" the
shadow and non-shadow RRsets in that case. We don't have any use for
that in production, but it's nice to know we could if we wanted to.
- Kevin
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
