[prev in list] [next in list] [prev in thread] [next in thread]
List: nanog
Subject: Re: looking for hostname router identifier validation
From: "Patrick W. Gilmore" <patrick () ianai ! net>
Date: 2019-04-30 16:01:10
Message-ID: CEFB65C3-8FB2-44C4-8B2E-A920D1579078 () ianai ! net
[Download RAW message or body]
Automation isn't even that hard - just outsource (e.g. 6Connect).
I get why some things stagnate & collect kruft. But it is actually EASIER, and \
probably cheaper (including people time), to have a 3rd party "just do it" when it \
comes to things like DNS & IPAM.
Then again, if everyone ran everything perfectly … oh, then I could retire. :-)
--
TTFN,
patrick
> On Apr 30, 2019, at 8:12 AM, Jared Mauch <jared@puck.nether.net> wrote:
>
> While at NTT and at Akamai we have managed to publish sane PTR records and make the \
> forward work as well. You need to automate it by pulling from your router \
> configuration database and publish to your DNS database. If you are still doing \
> either by hand then it's time to make the switch ASAP.
> Sent from my iCar
>
> On Apr 29, 2019, at 4:13 PM, Eric Kuhnke <eric.kuhnke@gmail.com \
> <mailto:eric.kuhnke@gmail.com>> wrote:
> > I would caution against putting much faith in the validity of geolocation or site \
> > ID by reverse DNS PTR records. There are a vast number of unmaintained, ancient, \
> > stale, erroneous or wildly wrong PTR records out there. I can name at least a \
> > half dozen ISPs that have absorbed other ASes, some of those which also acquired \
> > other ASes earlier in their history, forming a turducken of obsolete PTR records \
> > that has things with ISP domain names last in use in the year 2002.
> >
> >
> > On Mon, Apr 29, 2019 at 6:15 AM Matthew Luckie <mjl@luckie.org.nz \
> > <mailto:mjl@luckie.org.nz>> wrote: Hi NANOG,
> >
> > To support Internet topology analysis efforts, I have been working on
> > an algorithm to automatically detect router names inside hostnames
> > (PTR records) for router interfaces, and build regular expressions
> > (regexes) to extract them. By "router name" inside the hostname, I
> > mean a substring, or set of non-contiguous substrings, that is common
> > among interfaces on a router. For example, suppose we had the
> > following three routers in the savvis.net <http://savvis.net/> domain suffix, \
> > each with two interfaces:
> >
> > das1-v3005.nj2.savvis.net <http://das1-v3005.nj2.savvis.net/>
> > das1-v3006.nj2.savvis.net <http://das1-v3006.nj2.savvis.net/>
> >
> > das1-v3005.oc2.savvis.net <http://das1-v3005.oc2.savvis.net/>
> > das1-v3007.oc2.savvis.net <http://das1-v3007.oc2.savvis.net/>
> >
> > das2-v3009.nj2.savvis.net <http://das2-v3009.nj2.savvis.net/>
> > das2-v3012.nj2.savvis.net <http://das2-v3012.nj2.savvis.net/>
> >
> > We might infer the router names are das1|nj2, das1|oc2, and das2|nj2,
> > respectively, and captured by the regex:
> > ^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$
> >
> > After much refinement based on smaller sets of ground truth, I'm
> > asking for broader feedback from operators. I've placed a webpage at
> > https://www.caida.org/~mjl/rnc/ <https://www.caida.org/~mjl/rnc/> that shows the \
> > inferences my algorithm made for 2523 domains. If you operate one of the domains \
> > in that list, I would appreciate it if you could comment (private is probably
> > better but public is fine with me) on whether the regex my algorithm
> > inferred represents your naming intent. In the first instance, I am
> > most interested in feedback for the suffix / date combinations for
> > suffixes that are colored green, i.e. appear to be reasonable.
> >
> > Each suffix / date combination links to a page that contains the
> > naming convention and corresponding inferences. The colored part of
> > each hostname is the inferred router name. The green hostnames appear
> > to be correct, at least as far as the algorithm determined. Some
> > suffixes have errors due to either stale hostnames or incorrect
> > training data, and those hostnames are colored red or orange.
> >
> > If anyone is interested in sets of hostnames the algorithm may have
> > inferred as 'stale' for their network, because for some operators it
> > was an oversight and they were grateful to learn about it, I can
> > provide that information.
> >
> > Thanks,
> >
> > Matthew
[Attachment #3 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class="">Automation isn't even that hard - just \
outsource (e.g. 6Connect).<div class=""><br class=""></div><div class="">I get why \
some things stagnate & collect kruft. But it is actually EASIER, and probably \
cheaper (including people time), to have a 3rd party "just do it" when it comes to \
things like DNS & IPAM.</div><div class=""><br class=""></div><div class="">Then \
again, if everyone ran everything perfectly … oh, then I could retire. :-)<br \
class=""><div class=""> <div dir="auto" style="caret-color: rgb(0, 0, 0); color: \
rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; \
text-transform: none; white-space: normal; word-spacing: 0px; \
-webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; \
-webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div \
style="font-family: Optima; font-size: 13px; font-style: normal; font-variant-caps: \
normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: \
0px; text-transform: none; white-space: normal; word-spacing: 0px; \
-webkit-text-stroke-width: 0px; text-decoration: none; color: rgb(0, 0, 0);"><span \
style="font-style: normal;" class=""><br \
class="Apple-interchange-newline">-- <br class="">TTFN,<br class="">patrick<br \
class=""></span></div><div style="font-family: Optima; font-size: 13px; font-style: \
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; \
text-align: start; text-indent: 0px; text-transform: none; white-space: normal; \
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; color: \
rgb(0, 0, 0);"><br class=""></div></div><br class="Apple-interchange-newline"> </div>
<div><br class=""><blockquote type="cite" class=""><div class="">On Apr 30, 2019, at \
8:12 AM, Jared Mauch <<a href="mailto:jared@puck.nether.net" \
class="">jared@puck.nether.net</a>> wrote:</div><br \
class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" \
content="text/html; charset=utf-8" class=""><div dir="auto" class="">While at NTT and \
at Akamai we have managed to publish sane PTR records and make the forward work as \
well. You need to automate it by pulling from your router configuration database and \
publish to your DNS database. If you are still doing either by hand then it's time to \
make the switch ASAP. <br class=""><br class=""><div dir="ltr" class="">Sent \
from my iCar</div><div dir="ltr" class=""><br class="">On Apr 29, 2019, at 4:13 PM, \
Eric Kuhnke <<a href="mailto:eric.kuhnke@gmail.com" \
class="">eric.kuhnke@gmail.com</a>> wrote:<br class=""><br \
class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div \
dir="ltr" class=""><div class="">I would caution against putting much faith in the \
validity of geolocation or site ID by reverse DNS PTR records. There are a vast \
number of unmaintained, ancient, stale, erroneous or wildly wrong PTR records out \
there. I can name at least a half dozen ISPs that have absorbed other ASes, some of \
those which also acquired other ASes earlier in their history, forming a turducken of \
obsolete PTR records that has things with ISP domain names last in use in the year \
2002.</div><div class=""><br class=""></div><div class=""><br \
class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Mon, Apr 29, 2019 at 6:15 AM Matthew Luckie <<a \
href="mailto:mjl@luckie.org.nz" class="">mjl@luckie.org.nz</a>> wrote:<br \
class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi NANOG,<br class=""> \
<br class=""> To support Internet topology analysis efforts, I have been working \
on<br class=""> an algorithm to automatically detect router names inside hostnames<br \
class=""> (PTR records) for router interfaces, and build regular expressions<br \
class=""> (regexes) to extract them. By "router name" inside the hostname, I<br \
class=""> mean a substring, or set of non-contiguous substrings, that is common<br \
class=""> among interfaces on a router. For example, suppose we had the<br \
class=""> following three routers in the <a href="http://savvis.net/" \
rel="noreferrer" target="_blank" class="">savvis.net</a> domain suffix, each with \
two<br class=""> interfaces:<br class="">
<br class="">
<a href="http://das1-v3005.nj2.savvis.net/" rel="noreferrer" target="_blank" \
class="">das1-v3005.nj2.savvis.net</a><br class=""> <a \
href="http://das1-v3006.nj2.savvis.net/" rel="noreferrer" target="_blank" \
class="">das1-v3006.nj2.savvis.net</a><br class=""> <br class="">
<a href="http://das1-v3005.oc2.savvis.net/" rel="noreferrer" target="_blank" \
class="">das1-v3005.oc2.savvis.net</a><br class=""> <a \
href="http://das1-v3007.oc2.savvis.net/" rel="noreferrer" target="_blank" \
class="">das1-v3007.oc2.savvis.net</a><br class=""> <br class="">
<a href="http://das2-v3009.nj2.savvis.net/" rel="noreferrer" target="_blank" \
class="">das2-v3009.nj2.savvis.net</a><br class=""> <a \
href="http://das2-v3012.nj2.savvis.net/" rel="noreferrer" target="_blank" \
class="">das2-v3012.nj2.savvis.net</a><br class=""> <br class="">
We might infer the router names are das1|nj2, das1|oc2, and das2|nj2,<br class="">
respectively, and captured by the regex:<br class="">
^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$<br class="">
<br class="">
After much refinement based on smaller sets of ground truth, I'm<br class="">
asking for broader feedback from operators. I've placed a webpage at<br \
class=""> <a href="https://www.caida.org/~mjl/rnc/" rel="noreferrer" target="_blank" \
class="">https://www.caida.org/~mjl/rnc/</a> that shows the inferences my \
algorithm<br class=""> made for 2523 domains. If you operate one of the domains \
in that<br class=""> list, I would appreciate it if you could comment (private is \
probably<br class=""> better but public is fine with me) on whether the regex my \
algorithm<br class=""> inferred represents your naming intent. In the first \
instance, I am<br class=""> most interested in feedback for the suffix / date \
combinations for<br class=""> suffixes that are colored green, i.e. appear to be \
reasonable.<br class=""> <br class="">
Each suffix / date combination links to a page that contains the<br class="">
naming convention and corresponding inferences. The colored part of<br \
class=""> each hostname is the inferred router name. The green hostnames \
appear<br class=""> to be correct, at least as far as the algorithm determined. \
Some<br class=""> suffixes have errors due to either stale hostnames or incorrect<br \
class=""> training data, and those hostnames are colored red or orange.<br class="">
<br class="">
If anyone is interested in sets of hostnames the algorithm may have<br class="">
inferred as 'stale' for their network, because for some operators it<br class="">
was an oversight and they were grateful to learn about it, I can<br class="">
provide that information.<br class="">
<br class="">
Thanks,<br class="">
<br class="">
Matthew<br class="">
</blockquote></div>
</div></blockquote></div></div></blockquote></div><br class=""></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic