Re: Wildcard SRV record?

[Stephen Pape]

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 zones for each of the domains; rather there's a
single top level "foo" zone. A and Ptr records are added via
DHCP/rndc, and DHCP assigns "username.foo" domain names.

My approach feels a bit "hackish" to me. Now I have several hundred
CNAME records in the .foo zone, all pointing to the same SRV record.
I'll have to deal with removing old records as users are removed, and
I'll have to make sure the script runs reliably, but it works.

I appreciate the help, anyway!

-Stephen

On Mon, Oct 31, 2016 at 6:04 PM, Mark Andrews  wrote:
>
> In message 
> 

RE: Wildcard SRV record?

[Darcy Kevin (FCA)]

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

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Stephen 
Pape
Sent: Monday, October 31, 2016 12:36 PM
To: bind-users@lists.isc.org
Subject: Wildcard SRV record?

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 trying to add a SRV record for everyone under .foo. I've tried:

_vlmcs._tcp.*.foo.IN  SRV 0 0 1688 ais-dc01.ainfosec.com.

... but it seems that wildcards don't work that way. I've tried something 
similar with CNAMEs, but that didn't work either.

What DOES work is adding a CNAME record for each and every domain that I need. 
So a CNAME for _vlmcs._tcp.a.foo, _vlmcs._tcp.b.foo, etc.

Is there a better way for me to do this, or do I have to generate a whole lot 
of specific CNAME records?

Thanks!

-Stephen
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Wildcard SRV record?

[Stephen Pape]

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:
>
> _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 & Communications
> IT Services, Iowa State University of Science and Technology
>
>
>
>> On Oct 31, 2016, at 11:35 AM, Stephen Pape  wrote:
>>
>> 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 trying to add a SRV record for everyone under .foo. I've tried:
>>
>> _vlmcs._tcp.*.foo.IN  SRV 0 0 1688 ais-dc01.ainfosec.com.
>>
>> ... but it seems that wildcards don't work that way. I've tried
>> something similar with CNAMEs, but that didn't work either.
>>
>> What DOES work is adding a CNAME record for each and every domain that
>> I need. So a CNAME for _vlmcs._tcp.a.foo, _vlmcs._tcp.b.foo, etc.
>>
>> Is there a better way for me to do this, or do I have to generate a
>> whole lot of specific CNAME records?
>>
>> Thanks!
>>
>> -Stephen
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Wildcard SRV record?

[Eldridge, Rod A [ITNET]]

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 & Communications
IT Services, Iowa State University of Science and Technology



> On Oct 31, 2016, at 11:35 AM, Stephen Pape  wrote:
> 
> 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 trying to add a SRV record for everyone under .foo. I've tried:
> 
> _vlmcs._tcp.*.foo.IN  SRV 0 0 1688 ais-dc01.ainfosec.com.
> 
> ... but it seems that wildcards don't work that way. I've tried
> something similar with CNAMEs, but that didn't work either.
> 
> What DOES work is adding a CNAME record for each and every domain that
> I need. So a CNAME for _vlmcs._tcp.a.foo, _vlmcs._tcp.b.foo, etc.
> 
> Is there a better way for me to do this, or do I have to generate a
> whole lot of specific CNAME records?
> 
> Thanks!
> 
> -Stephen
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Wildcard SRV record?

[Stephen Pape]

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:
>>
>> 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 to generate
> the CNAMEs, or directly generate the SRV records themselves.
>
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Wildcard SRV record?

[Matthew Pounsett]

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 to generate
the CNAMEs, or directly generate the SRV records themselves.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: The DDOS attack on DYN & RRL ?

[Ben Croswell]

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 ensure your domains are serviceable if a
provider gets attacked.

On Oct 31, 2016 12:25 PM, "Matthew Seaman" 
wrote:

> 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 attacks on the same day.  The first (about
> 12:00 UTC) affected pretty much just the Eastern USA, and we saw little
> beyond some raised RTTs in Europe.  The second (about 16:00UTC) took out
> all the Dyn POPs in the USA and affected their European POP.  The third
> (around 18:00UTC) ... was pretty much a non-event.  Dyn had mitigated
> the attacks pretty effectively by that point.
>
> Cheers,
>
> Matthew
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: The DDOS attack on DYN & RRL ?

[Matthew Seaman]

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 attacks on the same day.  The first (about
12:00 UTC) affected pretty much just the Eastern USA, and we saw little
beyond some raised RTTs in Europe.  The second (about 16:00UTC) took out
all the Dyn POPs in the USA and affected their European POP.  The third
(around 18:00UTC) ... was pretty much a non-event.  Dyn had mitigated
the attacks pretty effectively by that point.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: The DDOS attack on DYN & RRL ?

[Barry Margolin]

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 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 in the Mirai botnet
> >> scenario unless each node is pretty much as robust as a traditional
> >> unicast node.
> >
> > I couldn't really say whether unicast is more or less resistant to this
> > sort of attack -- I'd guess either way it would be down to the capacity
> > at each individual node.
> >
> > It was Dyn's USA POPs that bore the brunt of the attack, presumably
> > because most of the Mirai bots were located in the USA.  Even so, it
> > still caused us plenty of grief in Europe.  Apparently the effects were
> > fairly minimal in the Far East.
> >
> 
> That makes one wonder if the EU Anycast nodes are reliant on the USA
> node(s).  I have no insights (and even less DNS knowledge) but it
> makes one wonder if there's a fundamental design flaw in anycast DNS
> that relies on one or more nodes... is anycast DNS really just
> distributed cache DNS?

"Anycast" just means that a single public IP address is routed to 
different POPs depending on where the source is. So if you query 4.2.2.1 
or 8.8.8.8 from the US, you'll go to a US nameserver; if you query them 
from Europe, you'll go to a European server.

While 4.2.2.1 and 8.8.8.8 are caching DNS, the same can be done with 
authoritative DNS, and that's what was attacked in the Dyn case (I'm not 
even sure if Dyn offers caching DNS).

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.

-- 
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: The DDOS attack on DYN & RRL ?

[Jim Popovitch]

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 and
>>> each POP contains a bunch of top-of-the-line servers.
>>
>> 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.
>
> I couldn't really say whether unicast is more or less resistant to this
> sort of attack -- I'd guess either way it would be down to the capacity
> at each individual node.
>
> It was Dyn's USA POPs that bore the brunt of the attack, presumably
> because most of the Mirai bots were located in the USA.  Even so, it
> still caused us plenty of grief in Europe.  Apparently the effects were
> fairly minimal in the Far East.
>

That makes one wonder if the EU Anycast nodes are reliant on the USA
node(s).  I have no insights (and even less DNS knowledge) but it
makes one wonder if there's a fundamental design flaw in anycast DNS
that relies on one or more nodes... is anycast DNS really just
distributed cache DNS?

-Jim P.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: The DDOS attack on DYN & RRL ?

[Matthew Seaman]

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.
> 
> 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.

I couldn't really say whether unicast is more or less resistant to this
sort of attack -- I'd guess either way it would be down to the capacity
at each individual node.

It was Dyn's USA POPs that bore the brunt of the attack, presumably
because most of the Mirai bots were located in the USA.  Even so, it
still caused us plenty of grief in Europe.  Apparently the effects were
fairly minimal in the Far East.

Cheers,

Matthew






signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: The DDOS attack on DYN & RRL ?

[Jim Popovitch]

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 in the Mirai botnet
scenario unless each node is pretty much as robust as a traditional
unicast node.

-Jim P.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: The DDOS attack on DYN & RRL ?

[Matthew Seaman]

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 help or was the
> pure volume of traffic the real issue?

Having been burned by the DDoS I can tell you that 'RRL' functionality
was pretty much irrelevant in this case.  This was not using DNS servers
as traffic amplifiers (which is what RRL mitigates against).

This was using millions of insecure IoT devices -- frequently web cams
-- to generate a massive overkill-level traffic surge -- lots of DNS
lookups -- that simply overwhelmed Dyn's servers.  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.

Surviving DDoS is all about having more capacity available than your
attackers can fill up[*].  These Mirai botnets have upped the ante by a
wide margin.  I suspect that the DDoS protection companies, the big DNS
service providers, the TLD and the root operators are quietly but
franticly working on plans to beef up their defenses...

Cheers,

Matthew

[*] Even by proxy: anti-DDoS companies essentially have network capacity
available for hire as well as some pretty fancy traffic filtering
techniques.



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

The DDOS attack on DYN & RRL ?

[MURTARI, JOHN]

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 volume of 
traffic the real issue?

I know companies are loathe to share info with competitors, but 
the wolves are out there and we sheep need to communicate a bit with each other.

I think ISC does have secure channels with large corporate 
users.  Is something in place to share attack info, protections that were used? 
  Might be a good idea.

Best regards!


John Murtari - jm5...@att.com
Ciberspring
office: 315-944-0998
cell: 315-430-2702

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

lwres - Error codes

[Felix Haase]

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 not have a record for the requested
domain

Is there any way to distinguish these two cases to get a clear error
message from the lwres library?

In general it would be nice to have error messages corresponding to the
RCODE section defined in RFC 1035 p.27 ( No error, Format error, Server
failure, Name error, Not implemented, Refused)

Is that somehow possible to do using the library ?

Thanks and regards,
Felix
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Zone removal messages

[Tony Finch]

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 reconfigures static-stub zones
from scratch, rather than reusing the existing zone object (see
ns_zone_reusable at the end of bin/named/zoneconf.c) but it doesn't log
that it created a replacement zone object.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Faeroes: Westerly veering northwesterly 5 to 7, perhaps gale 8 later in north.
Rough or very rough. Showers. Moderate or good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users