In message <612d47d4-9465-4031-9d48-e6a0c3a8a...@dukhovni.org>
Viktor Dukhovni writes:
>
> > On Mar 13, 2016, at 5:42 PM, Curtis Villamizar <cur...@orleans.occnc.com>
> > wrote:
> >
> > The NS RR are typically delivered in a fixed order, the order in the
> > zone file, and while perhaps neither NS RR is properly a primary in
> > the sense that MX has preference, lots of code uses the first NS
> > first, then tries the second.
>
> Back to back queries about 1 second apart. :-)
>
> $ dig +noall +ans +auth +nocl +nottl -t ns orleans.occnc.com @ns01.occnc.com
> orleans.occnc.com. NS ns03.occnc.com.
> orleans.occnc.com. NS ns01.occnc.com.
>
> $ dig +noall +ans +auth +nocl +nottl -t ns orleans.occnc.com @ns01.occnc.com
> orleans.occnc.com. NS ns01.occnc.com.
> orleans.occnc.com. NS ns03.occnc.com.
>
> --
> Viktor.
Hard to argue with that. I tried @8.8.8.8 and got the same thing.
That implies that if the NS behind the MSO service is not seeing much
action the MSO might be intercepting DNS and giving cached answers.
If so, this is a free "service" to their business Internet customers
that they don't bother telling those customers about. MSO intercept
and cache might also be why I had trouble with my DNS being somewhat
unreliable when I first turned DNSSEC on (long while ago - fine now).
I just checked and found out that "rrset-order fixed" is compiled out
of bind by default and has been for quite some time, but at least I
can compile it into my next build so I can put a fixed order on my NS
records and favor the better connected nameserver as in:
rrset-order { class IN type NS order fixed; order random; };
Though if caching servers dole out cached RR random order, that might
not help.
Sometimes I wonder why I didn't just do it right and get colo on the
west coast and have two very well connected sites (oh yeah - cost).
Curtis
