Yeah, as I said in one of the other emails, I can script something
with nsupdate if necessary. I was just hoping there was a way to add a
simple record that'd take care of it all, but now I understand that
wildcards don't really work that way, so I've scripted something.
I don't have separate zone
In message
, Stephen Pape writes:
> That doesn't work for me. When machine1.domain1.foo tries to look up
> the SRV record, it queries for _vlmcs._tcp.domain1.foo. Bind doesn't
> have that record, so it doesn't work.
Well add it.
If you need need change control independent of domain1.foo then ge
On Mon, Oct 31, 2016 at 12:21 PM, Tony Finch wrote:
> Jim Popovitch wrote:
>>
>> It seems to me that anycast is probably much worse in the Mirai botnet
>> scenario unless each node is pretty much as robust as a traditional
>> unicast node.
>
> This blog post is a pretty good intro to how anycast
Correct, wildcards don't work that way; in fact, it would be more accurate to
say that _vlmcs._tcp.*.foo. isn't a wildcard at all (it's just a DNS name that
happens to have an asterisk as one of its labels). See RFC 4592.
- Kevin
-Orig
That doesn't work for me. When machine1.domain1.foo tries to look up
the SRV record, it queries for _vlmcs._tcp.domain1.foo. Bind doesn't
have that record, so it doesn't work.
On Mon, Oct 31, 2016 at 1:08 PM, Eldridge, Rod A [ITNET]
wrote:
>
> Wouldn't you just need this one SRV record:
>
> _vlmc
Wouldn't you just need this one SRV record:
_vlmcs._tcp.foo IN SRV 0 0 1688 ais-dc01.ainfosec.com.
[ see
https://blogs.technet.microsoft.com/odsupport/2011/11/14/how-to-discover-office-and-windows-kms-hosts-via-dns-and-remove-unauthorized-instances/
]
--
Rod Eldridge
Networks & Communicatio
Thanks, but the names aren't predictable; they're usernames. I could
script something with nsupdate, if necessary, but I'd rather have a
simple record than have scripting/cron.
On Mon, Oct 31, 2016 at 12:44 PM, Matthew Pounsett wrote:
>
>
> On 31 October 2016 at 12:35, Stephen Pape wrote:
>>
>>
On 31 October 2016 at 12:35, Stephen Pape wrote:
> Is there a better way for me to do this, or do I have to generate a
> whole lot of specific CNAME records?
>
If your subdomains follow a predictable pattern, then this seems like a
prime use of the $GENERATE statement. You could either use it t
Hello all,
I have bind configured with a single TLD (.foo), and inside that are
records for a large number of subdomains (machine1.a.foo,
machine2.a.foo, machine1.b.foo, machine2.b.foo, etc.). DHCP clients
are assigned a domain based on some factors, but it might be a.foo,
b.foo, c.foo, etc.
I'm
I think what we see as a result of this attack is DNS provider diversity
being the new buzz phrase. The same as not relying on a single ISP link i
see more people using multiple DNS providers.
The size of these attacks will grow as IoT continues to grow. It makes
sense to have diverse providers to
On 2016/10/31 16:09, Barry Margolin wrote:
> I heard that the impact of the attack was even narrower than just the
> US, it was mostly eastern US. That suggests some things about the
> granularity of Dyn's anycast network and the distribution of the Mirai
> botnet.
There were actually three att
Jim Popovitch wrote:
>
> It seems to me that anycast is probably much worse in the Mirai botnet
> scenario unless each node is pretty much as robust as a traditional
> unicast node.
This blog post is a pretty good intro to how anycast can help with DDoS
mitgation, though I think Cloudflare are ov
In article ,
Jim Popovitch wrote:
> On Mon, Oct 31, 2016 at 11:27 AM, Matthew Seaman
> wrote:
> > On 2016/10/31 14:53, Jim Popovitch wrote:
> >> On Mon, Oct 31, 2016 at 10:25 AM, Matthew Seaman
> >> wrote:
> >>> This despite the fact that Dyn has a global anycast network with
> >>> plenty of b
On Mon, Oct 31, 2016 at 11:27 AM, Matthew Seaman
wrote:
> On 2016/10/31 14:53, Jim Popovitch wrote:
>> On Mon, Oct 31, 2016 at 10:25 AM, Matthew Seaman
>> wrote:
>>> This despite the fact that Dyn has a global anycast network with
>>> plenty of bandwidth, points of presence all round the world an
On 2016/10/31 14:53, Jim Popovitch wrote:
> On Mon, Oct 31, 2016 at 10:25 AM, Matthew Seaman
> wrote:
>> This despite the fact that Dyn has a global anycast network with
>> plenty of bandwidth, points of presence all round the world and
>> each POP contains a bunch of top-of-the-line servers.
>
>
On Mon, Oct 31, 2016 at 10:25 AM, Matthew Seaman
wrote:
> This despite the fact that Dyn has a global anycast network with
> plenty of bandwidth, points of presence all round the world and
> each POP contains a bunch of top-of-the-line servers.
It seems to me that anycast is probably much worse i
On 10/31/16 12:41, MURTARI, JOHN wrote:
> God only knows, the DDOS hackers are probably on this listbut I
> have to ask what protections DYN had in place before the attack
> occurred. RRL has been promoted as some protection against these
> types of attacks. If they had it in place, did it he
Folks,
God only knows, the DDOS hackers are probably on this
listbut I have to ask what protections DYN had in place before the attack
occurred. RRL has been promoted as some protection against these types of
attacks. If they had it in place, did it help or was the pure vol
Hello folks,
i have a question about the error codes returned by lwres_getaddrsbyname
and lwres_getrdatabyname functions. lwresd is running and working.
These functions return LWRES_R_NOTFOUND
1) if the DNS server can not be reached by the lwresd daemon
2) if the DNS server responds but does no
Dns Administrator wrote:
>
> Thought the querying appears to be correct, when I reload the dns server I
> get the following message:
>
> 27-Oct-2016 09:31:29.208 general: info: zone ./IN: (static-stub) removed
Yes, this log message is spurious.
The reason seems to be that named always reconfigur
20 matches
Mail list logo
