<div dir="ltr"><div>On Wed, Aug 24, 2016 at 10:50 PM, Veaceslav Revutchi <span dir="ltr"><<a href="mailto:slavarevutchi@gmail.com" target="_blank">slavarevutchi@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I know in theory the two could be further apart and announced as /32s,<br>
however mtr shows almost identical hops and latency, sprint looking<br>
glass shows a /24 and the rest of the world sees a /14 for those IPs.<br>
Would you flag this as a poor setup where a network problem affecting<br>
that subnet could take down both servers?<br></blockquote><div><br></div>It is likely a poor setup. Reference BCP 16 (RFC 2182): (<a href="https://tools.ietf.org/html/rfc2182#section-3.1">https://tools.ietf.org/html/rfc2182#section-3.1</a>)<div><div><br></div></div><div><pre class="" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"> 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.</pre></div><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, the two servers do not respond if I set the edns version to<br>
something other than 0. Does that mean there is a firewall in front of<br>
them that doesn't handle dns properly? I understand this means not<br>
following the RFC.<br></blockquote><div><br></div><div>It could also be poorly written software. Without knowing the software the authoritative server runs, it's not obvious what is at fault here.</div><div><br></div></div></div></div>