[dns-operations] question on dns setup, name-servers on adjacent IPs

[Andrew Boling]

On Wed, Aug 24, 2016 at 10:50 PM, Veaceslav Revutchi <
slavarevutchi at gmail.com> wrote:

> I know in theory the two could be further apart and announced as /32s,
> however mtr shows almost identical hops and latency, sprint looking
> glass shows a /24 and the rest of the world sees a /14 for those IPs.
> Would you flag this as a poor setup where a network problem affecting
> that subnet could take down both servers?
>

It is likely a poor setup. Reference BCP 16 (RFC 2182): (
https://tools.ietf.org/html/rfc2182#section-3.1)

   Secondary servers must be placed at both topologically and
   geographically dispersed locations on the Internet, to minimise the
   likelihood of a single failure disabling all of them.

   That is, secondary servers should be at geographically distant
   locations, so it is unlikely that events like power loss, etc, will
   disrupt all of them simultaneously.  They should also be connected to
   the net via quite diverse paths.  This means that the failure of any
   one link, or of routing within some segment of the network (such as a
   service provider) will not make all of the servers unreachable.


Any problems encountered along the route will apply to authoritative
lookups directed at both servers. This includes intermittent packet loss
where the remote hosts are not completely unreachable, which will result in
some difficult to troubleshoot DNS lookup failures for end users.


Also, the two servers do not respond if I set the edns version to
> something other than 0. Does that mean there is a firewall in front of
> them that doesn't handle dns properly? I understand this means not
> following the RFC.
>

It could also be poorly written software. Without knowing the software the
authoritative server runs, it's not obvious what is at fault here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160825/0b08d4e3/attachment.html>