In message <4a528a41.5000...@chrysler.com>, Kevin Darcy writes:
> 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.
Actually that isn't too much to ask. This sort of inconsistancy
is what causes real problems and has delayed the deployment of IPv6
by years. There are even CERT advisaries about it.
Adding A records for the names being served to the shadow zone
should prevent wrong anwers being returned. It shouldn't require
a wildcard to be installed.
> 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.
Hopefully it filters out the records from should be supplied by the
GSS.
> - Kevin
Given the number of sites that appear to get the concept of a
backing/shadow zone wrong. I expect the documentation leaves a lot
to be desired. I lost count of the number of load balancers where
www.example.com is delegated to the load balancer and the backing/shadow
zone is example.com not www.example.com.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
