Re: swedish dns zone enumerator

[Randy Bush]

ya, right,  and at a whole bunch of other cctld servers

from a network called domaincrawler-hosting

shall we smoke another?

/home/randy> sudo tcpdump -pni vtnet0 -c 500 port 53 and net 193.235.141
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
05:12:30.563268 IP 193.235.141.169.32768 > 666.42.7.11.53: 14 NS? 
cgatcity.com.cu. (33)
05:12:30.565017 IP 193.235.141.215.32768 > 666.42.7.11.53: 14 NS? 
christ-jockel.jo. (34)
05:12:30.565660 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? cgatcity.al. 
(29)
05:12:30.566490 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? 
cgatcity.org.al. (33)
05:12:30.566694 IP 193.235.141.3.32768 > 666.42.7.11.53: 14 NS? 
christian-luber-jr.net.al. (43)
05:12:30.569474 IP 193.235.141.239.32768 > 666.42.7.11.53: 14 NS? 
clearing-muenchen.eg. (38)
05:12:30.571870 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? 
clearing-muenchen.com.ps. (42)
05:12:30.573436 IP 193.235.141.23.32768 > 666.42.7.11.53: 14 NS? 
cofls-welt.xn--pgbs0dh. (40)
05:12:30.573914 IP 193.235.141.173.32768 > 666.42.7.11.53: 14 NS? 
club-lederwerk-neustadt.net.al. (48)
05:12:30.574608 IP 193.235.141.60.32768 > 666.42.7.11.53: 14 NS? cofls-welt.az. 
(31)
05:12:30.575203 IP 193.235.141.183.32768 > 666.42.7.11.53: 14 NS? 
cofls-welt.lb. (31)
05:12:30.575356 IP 193.235.141.215.32768 > 666.42.7.11.53: 14 NS? conomix.eg. 
(28)
05:12:30.575950 IP 193.235.141.171.32768 > 666.42.7.11.53: 14 NS? 
conomix.net.ps. (32)
05:12:30.577242 IP 193.235.141.90.32768 > 666.42.7.11.53: 14 NS? 
computercheck-online.tn. (41)
05:12:30.577800 IP 193.235.141.134.32768 > 666.42.7.11.53: 14 NS? conomix.cu. 
(28)
05:12:30.578272 IP 193.235.141.177.32768 > 666.42.7.11.53: 14 NS? 
conomix.net.lb. (32)
05:12:30.578480 IP 193.235.141.114.32768 > 666.42.7.11.53: 14 NS? cstreibel.lr. 
(30)
05:12:30.578896 IP 193.235.141.114.32768 > 666.42.7.11.53: 14 NS? 
cstreibel.org.lb. (34)
05:12:30.579060 IP 193.235.141.244.32768 > 666.42.7.11.53: 14 NS? 
cristallcard.az. (33)
05:12:30.580681 IP 193.235.141.11.32768 > 666.42.7.11.53: 14 NS? d-cypher.tn. 
(29)
05:12:30.581812 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? d-cypher.al. 
(29)
05:12:30.582157 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? 
dailycatesse.sz. (33)
05:12:30.582381 IP 193.235.141.142.32768 > 666.42.7.11.53: 14 NS? d-cypher.eg. 
(29)
05:12:30.583340 IP 193.235.141.125.32768 > 666.42.7.11.53: 14 NS? 
damensattel-duesseldorf.net.ps. (48)
05:12:30.583439 IP 193.235.141.181.32768 > 666.42.7.11.53: 14 NS? 
dailycatesse.az. (33)
05:12:30.584078 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? 
dailycatesse.mw. (33)
05:12:30.584330 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? 
dailycatesse.org.al. (37)
05:12:30.584730 IP 193.235.141.3.32768 > 666.42.7.11.53: 14 NS? 
darkroom24.net.al. (35)
05:12:30.585506 IP 193.235.141.7.32768 > 666.42.7.11.53: 14 NS? 
damensattel-duesseldorf.jo. (44)
05:12:30.585995 IP 193.235.141.127.32768 > 666.42.7.11.53: 14 NS? dassehen.lr. 
(29)
05:12:30.587759 IP 193.235.141.173.32768 > 666.42.7.11.53: 14 NS? 
darkroom24.tn. (31)
05:12:30.588076 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? 
dgurock.org.al. (32)
05:12:30.589055 IP 193.235.141.212.32768 > 666.42.7.11.53: 14 NS? dictys.jo. 
(27)
05:12:30.589640 IP 193.235.141.240.32768 > 666.42.7.11.53: 14 NS? dgurock.az. 
(28)
05:12:30.591432 IP 193.235.141.172.32768 > 666.42.7.11.53: 14 NS? 
dictys.com.ps. (31)
05:12:30.592608 IP 193.235.141.213.32768 > 666.42.7.11.53: 14 NS? 
disko-thema.org.al. (36)
05:12:30.593365 IP 193.235.141.247.32768 > 666.42.7.11.53: 14 NS? 
diesling-1.net.al. (35)
05:12:30.593814 IP 193.235.141.147.32768 > 666.42.7.11.53: 14 NS? 
diesling-1.ps. (31)
05:12:30.595057 IP 193.235.141.240.32768 > 666.42.7.11.53: 14 NS? 
disko-thema.net.al. (36)
05:12:30.595722 IP 193.235.141.157.32768 > 666.42.7.11.53: 14 NS? 
disko-thema.xn--mgbayh7gpa. (44)
05:12:30.596496 IP 193.235.141.135.32768 > 666.42.7.11.53: 14 NS? 
downbeat-band.com.lb. (38)
05:12:30.596898 IP 193.235.141.185.32768 > 666.42.7.11.53: 14 NS? 
dj-hc-team.sz. (31)
05:12:30.598077 IP 193.235.141.177.32768 > 666.42.7.11.53: 14 NS? 
dnd-testdomain.net.al. (39)
05:12:30.598203 IP 193.235.141.146.32768 > 666.42.7.11.53: 14 NS? 
dnd-testdomain.net.ps. (39)
05:12:30.598338 IP 193.235.141.215.32768 > 666.42.7.11.53: 14 NS? 
druck-hamster.lr. (34)
05:12:30.599224 IP 193.235.141.168.32768 > 666.42.7.11.53: 14 NS? 
druckerei-hilden.az. (37)
05:12:30.602031 IP 193.235.141.45.32768 > 666.42.7.11.53: 14 NS? 
druckerei-hilden.com.lb. (41)
05:12:30.604763 IP 193.235.141.210.32768 > 666.42.7.11.53: 14 NS? 
drumandy.xn--pgbs0dh. (38)
05:12:30.605420 IP 193.235.141.212.32768 > 666.42.7.11.53: 14 NS? 
dugehoerstmir.tz. (34)
05:12:30.607074 IP 193.235.141.142.32768 > 666.42.7.11.53: 14 NS? 
dugehoerstmir.eg. (34)
05:12:30.607465 IP 193.235.141.152.32768 > 666.42.7.11.53: 14 NS? 
dugehoerstmir.net.lb. (38)
05:12:30.608142 IP 

Re: swedish dns zone enumerator

[Mark Andrews]

While I see evidence for the claim, 5 character left hand label and all 
non-existant.
I also see QNAME minimisation in action as the QTYPE is NS.  This could just be 
a open
recursive servers using QNAME minimisation.  With QNAME minimisation working 
correctly
all parent zones should see is NS queries with the occasional DNSKEY and DS 
query.  Both
BIND and Knot use NS queries for QNAME minimisation.  Other query types and/or 
prefixes
do not work as they have undesirable side effects.

I would not like anyone to take seeing mostly NS queries as any evidence of bad 
practice.
On the contrary, this is best practice.  It’s just relatively new.

I would also like to remind everyone here that QNAME minimisation using NS 
queries will
expose the bad practice of having mis-matching NS RRsets above and below the 
zone cut and
having garbage NS RRsets in the child zone when both parent and child are 
served by the same
servers.  Please ensure your NS RRsets are consistent on both sides of the zone 
cut and that
they are sane.

Mark


> On 1 Nov 2023, at 09:46, Randy Bush  wrote:
> 
> i have blocked a zone enumerator, though i guess they will be a
> whack-a-mole
> 
> others have reported them as well
> 
> /home/randy> sudo tcpdump -pni vtnet0 -c 10 port 53 and net 193.235.141
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 22:42:39.516849 IP 193.235.141.90.32768 > 666.42.7.11.53: 14 NS? 
> 33j4h.org.al. (30)
> 22:42:39.517640 IP 193.235.141.17.32768 > 666.42.7.11.53: 14 NS? 
> 33m6d.xn--mgbayh7gpa. (38)
> 22:42:39.519169 IP 193.235.141.17.32768 > 666.42.7.11.53: 14 NS? 33lxd.tn. 
> (26)
> 22:42:39.520064 IP 193.235.141.171.32768 > 666.42.7.11.53: 14 NS? 33md6.jo. 
> (26)
> 22:42:39.521081 IP 193.235.141.247.32768 > 666.42.7.11.53: 14 NS? 33lxd.lb. 
> (26)
> 22:42:39.523981 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? 33pd2.az. 
> (26)
> 22:42:39.525043 IP 193.235.141.60.32768 > 666.42.7.11.53: 14 NS? 
> 33nc5.com.al. (30)
> 22:42:39.526185 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? 33nc5.sz. 
> (26)
> 22:42:39.527931 IP 193.235.141.150.32768 > 666.42.7.11.53: 14 NS? 
> 33q5p.com.al. (30)
> 22:42:39.529516 IP 193.235.141.210.32768 > 666.42.7.11.53: 14 NS? 
> 33qbq.com.al. (30)
> 10 packets captured
> 124 packets received by filter
> 0 packets dropped by kernel
> 
> inetnum:193.235.141.0 - 193.235.141.255
> netname:domaincrawler-hosting
> descr:  domaincrawler hosting
> org:ORG-ABUS1196-RIPE
> country:SE
> admin-c:VIJE1-RIPE
> tech-c: VIJE1-RIPE
> status: ASSIGNED PA
> notify: c+1...@resilans.se
> mnt-by: RESILANS-MNT
> mnt-routes: ETTNET-LIR
> created:2008-04-03T11:21:00Z
> last-modified:  2017-04-10T12:47:06Z
> source: RIPE
> 
> randy

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: swedish dns zone enumerator

[Amir Herzberg]

Randy, thanks for sharing, I didn't know this is actually done. Any idea if
they use something clever or just exhaustive search? thanks Amir
-- 
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
https://sites.google.com/site/amirherzberg/cybersecurity




On Tue, Oct 31, 2023 at 6:49 PM Randy Bush  wrote:

> i have blocked a zone enumerator, though i guess they will be a
> whack-a-mole
>
> others have reported them as well
>
> /home/randy> sudo tcpdump -pni vtnet0 -c 10 port 53 and net 193.235.141
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 22:42:39.516849 IP 193.235.141.90.32768 > 666.42.7.11.53: 14 NS?
> 33j4h.org.al. (30)
> 22:42:39.517640 IP 193.235.141.17.32768 > 666.42.7.11.53: 14 NS?
> 33m6d.xn--mgbayh7gpa. (38)
> 22:42:39.519169 IP 193.235.141.17.32768 > 666.42.7.11.53: 14 NS? 33lxd.tn.
> (26)
> 22:42:39.520064 IP 193.235.141.171.32768 > 666.42.7.11.53: 14 NS? 33md6.jo.
> (26)
> 22:42:39.521081 IP 193.235.141.247.32768 > 666.42.7.11.53: 14 NS? 33lxd.lb.
> (26)
> 22:42:39.523981 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? 33pd2.az.
> (26)
> 22:42:39.525043 IP 193.235.141.60.32768 > 666.42.7.11.53: 14 NS?
> 33nc5.com.al. (30)
> 22:42:39.526185 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? 33nc5.sz.
> (26)
> 22:42:39.527931 IP 193.235.141.150.32768 > 666.42.7.11.53: 14 NS?
> 33q5p.com.al. (30)
> 22:42:39.529516 IP 193.235.141.210.32768 > 666.42.7.11.53: 14 NS?
> 33qbq.com.al. (30)
> 10 packets captured
> 124 packets received by filter
> 0 packets dropped by kernel
>
> inetnum:193.235.141.0 - 193.235.141.255
> netname:domaincrawler-hosting
> descr:  domaincrawler hosting
> org:ORG-ABUS1196-RIPE
> country:SE
> admin-c:VIJE1-RIPE
> tech-c: VIJE1-RIPE
> status: ASSIGNED PA
> notify: c+1...@resilans.se
> mnt-by: RESILANS-MNT
> mnt-routes: ETTNET-LIR
> created:2008-04-03T11:21:00Z
> last-modified:  2017-04-10T12:47:06Z
> source: RIPE
>
> randy
>

Re: [EXTERNAL] DNS filtering in practice, Re: Charter DNS servers returning malware filtered IP addresses

[Delong.com via NANOG]

> On Nov 1, 2023, at 13:28, Michael Thomas  wrote:
> 
> 
> On 10/28/23 3:13 AM, John Levine wrote:
>> It appears that Michael Thomas  said:
 If you're one of the small minority of retail users that knows enough
 about the technology to pick your own resolver, go ahead.  But it's
 a reasonable default to keep malware out of Grandma's iPad.
>>> How does this line up with DoH? Aren't they using hardwired resolver
>>> addresses? I would hope they are not doing anything heroic.
>> Generally, no.  I believe that Chrome probes whatever resolver is configured
>> into the system and uses that if it does DoH or DoT.
>> 
>> At one point Firefox was going to send everything to their favorite
>> DoH resolver but they got a great deal of pushback from people who
>> pointed out that they had policies on their networks and they'd have
>> to ban Firefox.  Firefox responded with a lame hack
>> where you can tell your cache to respond to some name and if so
>> Firefox will use your resolver.
> 
> That's probably what I'm remembering with Firefox. But doesn't probing the 
> local resolver sort of defeat the point of DoH? That is, I really don't want 
> my ISP to be able to snoop on my DNS history. Sending it off to one of the 
> well known resolvers at least gives me a chance to know whether they are evil 
> or not because there aren't very many of them vs every random ISP out there. 
> Since nobody but people like us know about those resolvers it seems to me 
> that without preconfiguration meaningful DoH is pretty limited?

The point of DoH is to move the ability to monetize your DNS history away from 
the public resolver world and into the hands of the content providers and other 
DoH providers.

I’m not sure I see that as an improvement, but I guess it depends on who you 
want to donate to.

Personally, I run my own resolvers and that doesn’t leak any data that wouldn’t 
have to be leaked anyway (after all, the DoH resolvers have to query the 
upstream authoritative servers on my behalf anyway, and with EDNS0, they’re 
likely passing along enough to deanonymize those queries, at least in my case.

YMMV

Owen

Re: [EXTERNAL] DNS filtering in practice, Re: Charter DNS servers returning malware filtered IP addresses

[Michael Thomas]

On 10/28/23 3:13 AM, John Levine wrote:

It appears that Michael Thomas  said:

If you're one of the small minority of retail users that knows enough
about the technology to pick your own resolver, go ahead.  But it's
a reasonable default to keep malware out of Grandma's iPad.

How does this line up with DoH? Aren't they using hardwired resolver
addresses? I would hope they are not doing anything heroic.

Generally, no.  I believe that Chrome probes whatever resolver is configured
into the system and uses that if it does DoH or DoT.

At one point Firefox was going to send everything to their favorite
DoH resolver but they got a great deal of pushback from people who
pointed out that they had policies on their networks and they'd have
to ban Firefox.  Firefox responded with a lame hack
where you can tell your cache to respond to some name and if so
Firefox will use your resolver.


That's probably what I'm remembering with Firefox. But doesn't probing 
the local resolver sort of defeat the point of DoH? That is, I really 
don't want my ISP to be able to snoop on my DNS history. Sending it off 
to one of the well known resolvers at least gives me a chance to know 
whether they are evil or not because there aren't very many of them vs 
every random ISP out there. Since nobody but people like us know about 
those resolvers it seems to me that without preconfiguration meaningful 
DoH is pretty limited?


Or maybe I just don't understand what problem they were trying to solve?

Mike

Re: Charter DNS servers returning invalid IP addresses

[Jason J. Gullickson via NANOG]

This is very interesting.

I did some poking-around and found other Squarespace customers with 
similar issues (in their case it was Google complaining that their sites 
were suspicious and therefore couldn't serve Google ads).  The leading 
theory is that the "canned" Squarespace sites are using an old version 
of some library or other piece of code that some software identifies as 
malware or otherwise dubious.


If I can figure out exactly what these services are upset about maybe I 
can take that to Squarespace and get them to fix it, but I'm not sure 
how far I'll get with what I know so far.



- Jason

On 2023-10-27 6:44 am, John Levine wrote:

It appears that J. Hellenthal via NANOG  said:

-=-=-=-=-=-

Maybe the site "has/had" a shopping cart infection at one point that 
has been found and eradicated at one point ?


Virustotal reported it four days ago, which suggests that whatever was
wrong with it is still wrong with it,

The usual (correct) response to "whitelist us because your malware
report is wrong" is "no, because it's not."

R's,
John

Re: OSP Management

[michael brooks - ESC]

We used to have an FTE for ArcGIS. We got by pretty well until we needed to
document circuits down to the NIC level, and then we lost that FTE
altogether. PatchManager was chosen from an RFP for its granularity and
(seeming) user-friendliness.




michael brooks
Sr. Network Engineer
Adams 12 Five Star Schools
michael.bro...@adams12.org

"flying is learning how to throw yourself at the ground and miss"



On Tue, Oct 31, 2023 at 4:29 PM Eric Kuhnke  wrote:

> On that topic, I find it interesting to see how different medium/regional
> scale ISPs have developed their own in-house GIS systems, once they reach
> the size and scale where one FTE staff position to run GIS systems/database
> backend is a necessity.
>
> There is a great deal that can be done with QGIS and entirely GPL/BSD
> licensed software, if your GIS person has a background in this sort of
> thing.
>
> Privately hosting a intranet-based tile-server for openstreetmap data and
> overlaying your own network on top of it is not extremely difficult.
>
>
>
> On Tue, Oct 31, 2023 at 6:27 AM michael brooks - ESC <
> michael.bro...@adams12.org> wrote:
>
>> On that note, what do you all use for managing OSP? We have been
>> attempting to stand up PatchManager for quite some time, and find it a good
>> product, but the billions of options can be overwhelming
>>
>>
>>
>>
>> michael brooks
>> Sr. Network Engineer
>> Adams 12 Five Star Schools
>> michael.bro...@adams12.org
>> 
>> "flying is learning how to throw yourself at the ground and miss"
>>
>>
>>
>> On Fri, Oct 27, 2023 at 5:54 AM Mike Hammett  wrote:
>>
>>>  Always fun managing OSP.
>>>
>>>
>>>
>>> -
>>> Mike Hammett
>>> Intelligent Computing Solutions
>>> http://www.ics-il.com
>>> 
>>>
>>> Midwest-IX
>>> http://www.midwest-ix.com
>>> 
>>>
>>>
>> This is a staff email account managed by Adams 12 Five Star Schools.
>> This email and any files transmitted with it are confidential and intended
>> solely for the use of the individual or entity to whom they are addressed.
>> If you have received this email in error please notify the sender.
>
>

-- 
This is a staff email account managed by Adams 12 Five Star Schools.  This 
email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the sender.