Re: DLZ $client% parameter segfault

[Mark Andrews]

In message , Michael 
McConnell writes:
> 
> The $client$ parameter appears to work for zone transfers, as per this =
> example https://github.com/opennetadmin/ona/wiki/bind-dlz
> However if I use $client$ on any other queries bind segfaults.
> 
> Strace doesn't seem to show anything useful...
> 
> Ideas?

* Run named in a debugger. 
gdb /path/to/named
run -f [the rest of named's usual arguements]
thread apply all bt full

* Load the named and the core file into a debugger.
gdb /path/to/named /path/to/core
thread apply all bt full
 
> Thanks again,
> Mike
> 
> On Apr 1, 2013, at 2:51 PM, Michael McConnell =
>  wrote:
> 
> > Hello All,
> >=20
> > I am trying to use Bind 9.9.2-P2 with the DLZ module, however I =
> continue to run into segfault issues when trying to use $client$
> >=20
> > {SELECT SQL_CACHE zone_name FROM dns_zones =85 }
> > {{select zone_ttl AS ttl =85. WHERE geo_ip LIKE '$client$'}
> >=20
> > I am trying to user $client$ in the A record lookup, not the zone =
> transfer. Is this possible?
> >=20
> > Thanks so much,
> > Michael
> >=20
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to =
> unsubscribe from this list
> >=20
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> --Apple-Mail=_D1B66773-B991-4C3C-9832-14222DFFE4D9
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/html;
>   charset=windows-1252
> 
>  charset=3Dwindows-1252"> -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The =
> $client$ parameter appears to work for zone transfers, as per this =
> example  href=3D"https://github.com/opennetadmin/ona/wiki/bind-dlz";>https://github.=
> com/opennetadmin/ona/wiki/bind-dlzHowever if I use $client$ on =
> any other queries bind segfaults.Strace =
> doesn't seem to show anything =
> useful...Ideas?Thanks =
> again,Mike
>  medium; font-style: normal; font-variant: normal; letter-spacing: =
> normal; line-height: normal; orphans: 2; text-align: -webkit-auto; =
> text-indent: 0px; text-transform: none; white-space: normal; widows: 2; =
> word-spacing: 0px; -webkit-text-size-adjust: auto; =
> -webkit-text-stroke-width: 0px; word-wrap: break-word; =
> -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> class=3D"Apple-style-span" style=3D"border-collapse: separate; =
> border-spacing: 0px; "> ">On Apr 1, 2013, at 2:51 PM, =
> Michael McConnell < href=3D"mailto:mich...@winkstreaming.com";>mich...@winkstreaming.com>=
> ; wrote: type=3D"cite"> charset=3Dwindows-1252"> -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello =
> All,I am trying to use Bind 9.9.2-P2 with the DLZ =
> module, however I continue to run into segfault issues when trying to =
> use $client${SELECT SQL_CACHE zone_name FROM =
> dns_zones =85 }{{select zone_ttl AS ttl =85. WHERE geo_ip =
> LIKE '$client$'}I am trying to user $client$ =
> in the A record lookup, not the zone transfer. Is this =
> possible? class=3D"webkit-block-placeholder">Thanks so =
> much,Michael
>  normal; font-variant: normal; letter-spacing: normal; line-height: =
> normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
> text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
> -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; =
> word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
> after-white-space; "> style=3D"border-collapse: separate; border-spacing: 0px; "> style=3D"font-weight: normal; "> class=3D"Apple-interchange-newline">_=
> __Please visit  href=3D"https://lists.isc.org/mailman/listinfo/bind-users";>https://lists.i=
> sc.org/mailman/listinfo/bind-users to unsubscribe from this =
> listbind-users mailing list href=3D"mailto:bind-users@lists.isc.org";>bind-users@lists.isc.orgh=
> ttps://lists.isc.org/mailman/listinfo/bind-users iv>=
> 
> --Apple-Mail=_D1B66773-B991-4C3C-9832-14222DFFE4D9--
> 
> 
> --===5099056141735232217==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> ___
> 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
> --===5099056141735232217==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: Forward First on Master Zone (bypass SOA)

[Doug Barton]

On 04/01/2013 11:46 AM, Kevin Darcy wrote:

On 3/29/2013 12:09 AM, Doug Barton wrote:

On 03/28/2013 12:28 PM, Ben-Eliezer, Tal (ITS) wrote:

My organization is evaluating the use of split-view DNS in our
environment.


Simple ... don't do it. It's almost never the right answer, and as
you're learning carries with it more administrative overhead than the
problems it's designed to solve.

Much better to spend the time carefully considering what your goals
are, and finding other ways to reach them.

>

And your alternative is what? Run the external version of the namespace
on a completely separate infrastructure from the internal version?


No, my point was don't do 2 versions.

Somewhere in the last 10 years (roughly corresponding to the popularity 
of NAT) it became baked in to a large segment of the DNS operator 
community that having internal and external views of the same zones was 
not only necessary, it was the only right way to do things. In my 
experience the number of times that this is the right answer are very 
few and far between. Looking at the actual problems that need solving 
without the prejudice that multiple views are necessary (or even 
correct) often leads to better solutions.


Doug

___
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

is NS record pointing to "some other name server" needed in case of classless IN-ADDR.ARPA delegations?

[Martin T]

Hi,

in case of classless IN-ADDR.ARPA
delegations(http://www.ietf.org/rfc/rfc2317.txt) I have usually seen
at least one NS record pointing to name server other than the
end-customer ones. Example from rfc2317.txt where there are two NS
records and the second one is not the end-customer name server:


;  <<0-127>> /25
0/25NS  ns.A.domain.
0/25NS  some.other.name.server.
;
1   CNAME   1.0/25.2.0.192.in-addr.arpa.
2   CNAME   2.0/25.2.0.192.in-addr.arpa.
3   CNAME   3.0/25.2.0.192.in-addr.arpa.
;


Another example from one real name server zone file:

;
0   IN  NS  ns.content-providerA.com.
0   IN  NS  ns2.content-providerA.com.
0   IN  NS  ns.isp-of-content-providerA.net.
;
1   IN  CNAME   1.0.47.168.192.in-addr.arpa.
2   IN  CNAME   2.0.47.168.192.in-addr.arpa.
3   IN  CNAME   3.0.47.168.192.in-addr.arpa.
;

Is NS record pointing to "some other name server" needed in case of
classless IN-ADDR.ARPA delegations? What happens if one does not
specify this?


regards,
Martin
___
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: Auto-dnssec maintain and 'continous' resigning

[Phil Mayers]

On 04/01/2013 07:36 PM, Carlos M. Martinez wrote:

Reframing the question in more general terms... Which events trigger a
zone re-sign and reload when using "auto-dnssec maintain" ?


As someone else has already said, zone updates, signature expiration and 
key events.


In particular, it's normal for the SOA serial to constantly increase in 
a zone with "auto-dnssec maintain", even if nothing else happens, 
because the signatures will be regenerated every N days. N depends on 
your config, but is 0.75 * default_sig_life (30 days) by default i.e. 
signatures are generated every 22.5 days.

___
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

RPZ and negative answers

[Chris Buxton]

Can anyone explain this to me?

If a name exists in the response policy, and also exists in the real Internet 
namespace, the value from the policy is returned. But if it doesn't exist out 
on the Internet, then the value is not returned -- an NXDOMAIN (or SERVFAIL, or 
whatever) is returned instead.

I've known this for a while but haven't understood why it is thus. Today, it 
has become a problem for me. If I set a policy of "this name gets response X", 
I expect that policy to be used rather than "this name gets response X unless 
it doesn't exist out on the Internet or can't be resolved due to an error."

Chris Buxton
BlueCat Networks
___
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: Blocking private addresses with a optionq

[Lawrence K. Chen, P.Eng.]

- Original Message -
> > From: "Lawrence K. Chen, P.Eng." 
> 
> > ... So, being able to filter out these 'bad' things when responding
> > queries against that data might be a good thing.
> 
> RPZ might be used for such things.  However, by design RPZ rewrites
> entire responses.  It is triggered by individual records in a
> response,
> but changes the entire response and not just individual records
> within
> the response.
> 
> To use RPZ for such filtering, you would probably use views with
> a response-policy{} statement in the external view to be filtered.
> 
> The RPZ rules could be triggered by rpz-ip records for 10.0.0.0/8 or
> similar.  The rules might rewrite responses to a CNAME or to sets of
> A and  records suitable for outsiders.  That sounds a lot more
> fragile and error prone than distinct zones for insiders and
> outsiders
> specified in the view statements.  However, RPZ might be good as a
> failsafe against leaks (perhaps rewriting to NXDOMAIN).
> 
> 
> Vernon Schryverv...@rhyolite.com
> 

Since this problem has started increasing again, I went to look to see how to 
use RPZ

First thing that got my attention was that "The rules encoded in a response 
policy zone (RPZ) are applied only to responses to queries that ask for 
recursion".  But, these are authoritative only nameservers   So, would RPZ 
work in this case?

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
Snail: Computing and Telecommunications Services (CTS)
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library
___
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: DLZ $client% parameter segfault

[Vadim S. Goncharov]

On 02.04.2013 01:13, Michael McConnell wrote:

Unfortunatelly, $client$ is only supported in allowzonexfr() method (see 
e.g. http://bind-dlz.sourceforge.net/mysql_driver.html for some info about 
SDLZ methods). It would be nice to have it in others, too, but BIND does not 
pass it via current API, alas.


In all others 'client' struct member just becomes NULL, so leads to segfault 
(yes, that's a bug).



The $client$ parameter appears to work for zone transfers, as per this
example https://github.com/opennetadmin/ona/wiki/bind-dlz
However if I use $client$ on any other queries bind segfaults.

Strace doesn't seem to show anything useful...

Ideas?

Thanks again,
Mike

On Apr 1, 2013, at 2:51 PM, Michael McConnell mailto:mich...@winkstreaming.com>> wrote:


Hello All,

I am trying to use Bind 9.9.2-P2 with the DLZ module, however I continue
to run into segfault issues when trying to use $client$

{SELECT SQL_CACHE zone_name FROM dns_zones … }
{{select zone_ttl AS ttl …. WHERE geo_ip LIKE '$client$'}

I am trying to user $client$ in the A record lookup, not the zone
transfer. Is this possible?

Thanks so much,
Michael



--
Vadim GoncharovRU-Center
NET Departmenthttp://www.nic.ru
NET-SYS Group phone:+7(495)737-7646  (ext.4019)
___
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: RPZ and negative answers

[Noel Butler]

On Tue, 2013-04-02 at 14:16 -0700, Chris Buxton wrote:

> Can anyone explain this to me?
> 
> If a name exists in the response policy, and also exists in the real Internet 
> namespace, the value from the policy is returned. But if it doesn't exist out 
> on the Internet, then the value is not returned -- an NXDOMAIN (or SERVFAIL, 
> or whatever) is returned instead.
> 
> I've known this for a while but haven't understood why it is thus. Today, it 
> has become a problem for me. If I set a policy of "this name gets response 
> X", I expect that policy to be used rather than "this name gets response X 
> unless it doesn't exist out on the Internet or can't be resolved due to an 
> error."
> 


Perhaps because it is a  "response" zone, not an actual  authoritative
"zone"?
Sounds strange, but makes sense to me.


signature.asc
Description: This is a digitally signed message part
___
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: Auto-dnssec maintain and 'continous' resigning

[Mark Andrews]

In message <515a92a5.3020...@imperial.ac.uk>, Phil Mayers writes:
> On 04/01/2013 07:36 PM, Carlos M. Martinez wrote:
> > Reframing the question in more general terms... Which events trigger a
> > zone re-sign and reload when using "auto-dnssec maintain" ?
> 
> As someone else has already said, zone updates, signature expiration and 
> key events.
> 
> In particular, it's normal for the SOA serial to constantly increase in 
> a zone with "auto-dnssec maintain", even if nothing else happens, 
> because the signatures will be regenerated every N days. N depends on 
> your config, but is 0.75 * default_sig_life (30 days) by default i.e. 
> signatures are generated every 22.5 days.

Named attempts to spread out re-signing load for a zone over time
even is the zone content is essentially static.  It takes time to
regenerate signatures so you don't want non-threaded builds to stall
too long res-signing.

> ___
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: Blocking private addresses with a optionq

[Vernon Schryver]

> From: "Lawrence K. Chen, P.Eng." 

> First thing that got my attention was that "The rules encoded in a
> response policy zone (RPZ) are applied only to responses to queries
> that ask for recursion".  But, these are authoritative only nameservers
> So, would RPZ work in this case?

This is some more complete text from the 9.8.4-P1 ARM without patches:

By default, the actions encoded in an RPZ are applied
only to queries that ask for recursion (RD=1).
That default can be changed for a single RPZ or all RPZs in a view
with a recursive-only no clause.


Vernon Schryverv...@rhyolite.com
___
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: is NS record pointing to "some other name server" needed in case of classless IN-ADDR.ARPA delegations?

[Mark Andrews]

If a zone is being made available to the public (which these are)
then steps should be taken to ensure it is resolvable all the time.
This means having multiple servers that are not subject to common
failures.  This is basic DNS.

In message 
, Martin T 
writes:
> Hi,
> 
> in case of classless IN-ADDR.ARPA
> delegations(http://www.ietf.org/rfc/rfc2317.txt) I have usually seen
> at least one NS record pointing to name server other than the
> end-customer ones. Example from rfc2317.txt where there are two NS
> records and the second one is not the end-customer name server:
> 
> 
> ;  <<0-127>> /25
> 0/25NS  ns.A.domain.
> 0/25NS  some.other.name.server.
> ;
> 1   CNAME   1.0/25.2.0.192.in-addr.arpa.
> 2   CNAME   2.0/25.2.0.192.in-addr.arpa.
> 3   CNAME   3.0/25.2.0.192.in-addr.arpa.
> ;
> 
> 
> Another example from one real name server zone file:
> 
> ;
> 0   IN  NS  ns.content-providerA.com.
> 0   IN  NS  ns2.content-providerA.com.
> 0   IN  NS  ns.isp-of-content-providerA.net.
> ;
> 1   IN  CNAME   1.0.47.168.192.in-addr.arpa.
> 2   IN  CNAME   2.0.47.168.192.in-addr.arpa.
> 3   IN  CNAME   3.0.47.168.192.in-addr.arpa.
> ;
> 
> Is NS record pointing to "some other name server" needed in case of
> classless IN-ADDR.ARPA delegations? What happens if one does not
> specify this?
> 
> 
> regards,
> Martin
> ___
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: DLZ $client% parameter segfault

[Michael McConnell]

Thanks certainly blows up the possibility of doing native GeoDNS at the moment… 
Any chance I am overlooking a method which I could effectively get the clients 
address into a MySQL query with the current 9.9.2 release?

Thanks again,
Michael

--

Michael McConnell
WINK Streaming;
email: mich...@winkstreaming.com
phone: +1 312 281-5433 x 7400
cell: +506 8706-2389
skype: wink-michael
web: http://winkstreaming.com

On Apr 2, 2013, at 4:03 AM, "Vadim S. Goncharov"  wrote:

> On 02.04.2013 01:13, Michael McConnell wrote:
> 
> Unfortunatelly, $client$ is only supported in allowzonexfr() method (see e.g. 
> http://bind-dlz.sourceforge.net/mysql_driver.html for some info about SDLZ 
> methods). It would be nice to have it in others, too, but BIND does not pass 
> it via current API, alas.
> 
> In all others 'client' struct member just becomes NULL, so leads to segfault 
> (yes, that's a bug).
> 
>> The $client$ parameter appears to work for zone transfers, as per this
>> example https://github.com/opennetadmin/ona/wiki/bind-dlz
>> However if I use $client$ on any other queries bind segfaults.
>> 
>> Strace doesn't seem to show anything useful...
>> 
>> Ideas?
>> 
>> Thanks again,
>> Mike
>> 
>> On Apr 1, 2013, at 2:51 PM, Michael McConnell > > wrote:
>> 
>>> Hello All,
>>> 
>>> I am trying to use Bind 9.9.2-P2 with the DLZ module, however I continue
>>> to run into segfault issues when trying to use $client$
>>> 
>>> {SELECT SQL_CACHE zone_name FROM dns_zones … }
>>> {{select zone_ttl AS ttl …. WHERE geo_ip LIKE '$client$'}
>>> 
>>> I am trying to user $client$ in the A record lookup, not the zone
>>> transfer. Is this possible?
>>> 
>>> Thanks so much,
>>> Michael
> 
> 
> -- 
> Vadim GoncharovRU-Center
> NET Departmenthttp://www.nic.ru
> NET-SYS Group phone:+7(495)737-7646  (ext.4019)
> ___
> 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: RPZ and negative answers

[Vernon Schryver]

> From: Chris Buxton 

> If a name exists in the response policy, and also exists in the real
> Internet namespace, the value from the policy is returned. But if it
> doesn't exist out on the Internet, then the value is not returned --
> an NXDOMAIN (or SERVFAIL, or whatever) is returned instead.
>
> I've known this for a while but haven't understood why it is thus.
> Today, it has become a problem for me. If I set a policy of "this
> name gets response X", I expect that policy to be used rather than
> "this name gets response X unless it doesn't exist out on the
> Internet or can't be resolved due to an error."

RPZ stands for "response policy zone" and concerns rewriting responses
instead of queries.  The answer section of an NXDOMAIN or SERFVAIL
response does not contain a domain name that could trigger rewriting.

Rewriting queries instead of responses would fail to rewrite CNAME
chains.

Even when the unrewritten response is an error such as NXDOMAIN, an
RPZ action can be triggered by the name or address of any NS RR that
is authoritative for the response and that is found in glue or otherwise.

Previous versions of the RPZ mechanism in BIND required ./configure
settings to enable rpz-nsip and rpz-nsdname rules.  They are enabled
by default in future released versions of BIND as well as the speed-up
patches that can found by following the  link labeled "Patch files for
BIND9" on http://www.redbarn.org/dns/ratelimits


Vernon Schryverv...@rhyolite.com
___
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: RPZ and negative answers

[Chris Buxton]

On Apr 3, 2013, at 4:13 PM, Vernon Schryver wrote:
>> From: Chris Buxton 
> 
>> If a name exists in the response policy, and also exists in the real
>> Internet namespace, the value from the policy is returned. But if it
>> doesn't exist out on the Internet, then the value is not returned --
>> an NXDOMAIN (or SERVFAIL, or whatever) is returned instead.
>> 
>> I've known this for a while but haven't understood why it is thus.
>> Today, it has become a problem for me. If I set a policy of "this
>> name gets response X", I expect that policy to be used rather than
>> "this name gets response X unless it doesn't exist out on the
>> Internet or can't be resolved due to an error."
> 
> RPZ stands for "response policy zone" and concerns rewriting responses
> instead of queries.  The answer section of an NXDOMAIN or SERFVAIL
> response does not contain a domain name that could trigger rewriting.
> 
> Rewriting queries instead of responses would fail to rewrite CNAME
> chains.

Thanks for the explanation. It seems to me this is a gap in coverage of RPZ -- 
the algorithm should be updated, in my opinion, to cover the case of a negative 
answer.

Chris Buxton
BlueCat Networks
___
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: Forward First on Master Zone (bypass SOA)

[Kevin Darcy]

On 4/2/2013 2:00 AM, Doug Barton wrote:

On 04/01/2013 11:46 AM, Kevin Darcy wrote:

On 3/29/2013 12:09 AM, Doug Barton wrote:

On 03/28/2013 12:28 PM, Ben-Eliezer, Tal (ITS) wrote:

My organization is evaluating the use of split-view DNS in our
environment.


Simple ... don't do it. It's almost never the right answer, and as
you're learning carries with it more administrative overhead than the
problems it's designed to solve.

Much better to spend the time carefully considering what your goals
are, and finding other ways to reach them.

>

And your alternative is what? Run the external version of the namespace
on a completely separate infrastructure from the internal version?


No, my point was don't do 2 versions.

Somewhere in the last 10 years (roughly corresponding to the 
popularity of NAT) it became baked in to a large segment of the DNS 
operator community that having internal and external views of the same 
zones was not only necessary, it was the only right way to do things. 
In my experience the number of times that this is the right answer are 
very few and far between. Looking at the actual problems that need 
solving without the prejudice that multiple views are necessary (or 
even correct) often leads to better solutions.


It's still not clear to me what you think is the "right" way to do it. 
Completely different namespaces for internal versus external 
(external-example.com versus internal-example.com)? Carve up the 
namespace at some level of the hierarchy (internal.example.com versus 
external.example.com)? My users, and management, simply don't find the 
infrastructure benefits of such naming conventions compelling enough, 
compared to the "image" or "aesthetic" problems from which those 
conventions supposedly suffer.


NAT doesn't really have any bearing on this, by the way. I realize most 
folks have gone hog-wild with NAT, but fortunately we've (mostly) been 
able to avoid that pitfall.


- Kevin

___
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: DLZ $client% parameter segfault

[Evan Hunt]

> Thanks certainly blows up the possibility of doing native GeoDNS at the
> moment? Any chance I am overlooking a method which I could effectively
> get the clients address into a MySQL query with the current 9.9.2
> release?

It's not quite the same as %client%, but I suggest you take a look at
contrib/dlz/example/dlz_example.c, note the use of the clientinfo
structure in dlz_lookup(), and see if it's any use to you.  You'd have
to hack the corresponding routine in the mysql DLZ driver.

Incidentally, native GeoIP support has been added as a feature in the
9.10 release -- you'll be able to use it to specify ACLs, e.g.,
"match-clients { geoip country US; };".  I expect it to be published
in Q4 of this year.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: is NS record pointing to "some other name server" needed in case of classless IN-ADDR.ARPA delegations?

[Doug Barton]

On 04/02/2013 12:47 AM, Martin T wrote:


Is NS record pointing to "some other name server" needed in case of
classless IN-ADDR.ARPA delegations? What happens if one does not
specify this?


It's very common for the parent name server(s) to slave the 2317 zone so 
that it can answer directly. It's also common for the child to slave the 
parent zone so that it can answer internal queries directly. And of 
course as Mark pointed out "name servers > 1" is basic DNS.


You may find this useful as well:

https://dougbarton.us/DNS/2317.html

Doug

___
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: Forward First on Master Zone (bypass SOA)

[Doug Barton]

On 04/03/2013 05:30 PM, Kevin Darcy wrote:

It's still not clear to me what you think is the "right" way to do it.


I'm not saying that there is only one right way. I'm saying you first 
have to answer the question, "What might we want to achieve by having 
different answers internally vs. externally for the same label?"


Sometimes multiple views are actually necessary to accomplish business 
goals. IME however it's become so baked in that "we need multiple views" 
that the right questions are never asked.


Doug

___
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: bind-users Digest, Vol 1487, Issue 2

[prakash]

> WINK Streaming;
> email: mich...@winkstreaming.com
> phone: +1 312 281-5433 x 7400
> cell: +506 8706-2389
> skype: wink-michael
> web: http://winkstreaming.com
> 
> On Apr 2, 2013, at 4:03 AM, "Vadim S. Goncharov" 
>  wrote:
> 
> > On 02.04.2013 01:13, Michael McConnell wrote:
> > 
> > Unfortunatelly, $client$ is only supported in allowzonexfr() 
> method (see e.g. http://bind-
> dlz.sourceforge.net/mysql_driver.html for some info about SDLZ 
> methods). It would be nice to have it in others, too, but BIND 
> does not pass it via current API, alas.
> > 
> > In all others 'client' struct member just becomes NULL, so 
> leads to segfault (yes, that's a bug).
> > 
> >> The $client$ parameter appears to work for zone transfers, as 
> per this
> >> example https://github.com/opennetadmin/ona/wiki/bind-dlz
> >> However if I use $client$ on any other queries bind segfaults.
> >> 
> >> Strace doesn't seem to show anything useful...
> >> 
> >> Ideas?
> >> 
> >> Thanks again,
> >> Mike
> >> 
> >> On Apr 1, 2013, at 2:51 PM, Michael McConnell 
> > 
> <mailto:mich...@winkstreaming.com>> wrote:
> >> 
> >>> Hello All,
> >>> 
> >>> I am trying to use Bind 9.9.2-P2 with the DLZ module, 
> however I continue
> >>> to run into segfault issues when trying to use $client$
> >>> 
> >>> {SELECT SQL_CACHE zone_name FROM dns_zones ? }
> >>> {{select zone_ttl AS ttl ?. WHERE geo_ip LIKE '$client$'}
> >>> 
> >>> I am trying to user $client$ in the A record lookup, not the zone
> >>> transfer. Is this possible?
> >>> 
> >>> Thanks so much,
> >>> Michael
> > 
> > 
> > -- 
> > Vadim Goncharov 
>RU-Center
> > NET 
> Departmenthttp://www.nic.ru
> > NET-SYS 
> Group phone:+7(495)737-7646  (ext.4019)
> > ___
> > 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
> 
> -- next part --
> An HTML attachment was scrubbed...
> URL: <https://lists.isc.org/pipermail/bind-
> users/attachments/20130403/5b6686cc/attachment-0001.html>
> 
> --
> 
> Message: 6
> Date: Wed, 3 Apr 2013 23:13:27 GMT
> From: Vernon Schryver 
> To: bind-users@lists.isc.org
> Subject: Re: RPZ and negative answers
> Message-ID: <201304032313.r33ndr3g014...@calcite.rhyolite.com>
> 
> > From: Chris Buxton 
> 
> > If a name exists in the response policy, and also exists in 
> the real
> > Internet namespace, the value from the policy is returned. But 
> if it
> > doesn't exist out on the Internet, then the value is not 
> returned --
> > an NXDOMAIN (or SERVFAIL, or whatever) is returned instead.
> >
> > I've known this for a while but haven't understood why it is thus.
> > Today, it has become a problem for me. If I set a policy of "this
> > name gets response X", I expect that policy to be used rather than
> > "this name gets response X unless it doesn't exist out on the
> > Internet or can't be resolved due to an error."
> 
> RPZ stands for "response policy zone" and concerns rewriting responses
> instead of queries.  The answer section of an NXDOMAIN or 
> SERFVAILresponse does not contain a domain name that could 
> trigger rewriting.
> 
> Rewriting queries instead of responses would fail to rewrite CNAME
> chains.
> 
> Even when the unrewritten response is an error such as NXDOMAIN, an
> RPZ action can be triggered by the name or address of any NS RR that
> is authoritative for the response and that is found in glue or 
> otherwise.
> Previous versions of the RPZ mechanism in BIND required ./configure
> settings to enable rpz-nsip and rpz-nsdname rules.  They 
> are enabled
> by default in future released versions of BIND as well as the 
> speed-up
> patches that can found by following the  link labeled 
> "Patch files for
> BIND9" on http://www.redbarn.org/dns/ratelimits
> 
> 
> Vernon Schryverv...@rhyolite.com
> 
> 
> --
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> End of bind-users Digest, Vol 1487, Issue 2
> ***
___
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

rate limit dns query response ...

[prakash]

 McConnell
> WINK Streaming;
> email: mich...@winkstreaming.com
> phone: +1 312 281-5433 x 7400
> cell: +506 8706-2389
> skype: wink-michael
> web: http://winkstreaming.com
> 
> On Apr 2, 2013, at 4:03 AM, "Vadim S. Goncharov" 
>  wrote:
> 
> > On 02.04.2013 01:13, Michael McConnell wrote:
> > 
> > Unfortunatelly, $client$ is only supported in allowzonexfr() 
> method (see e.g. http://bind-
> dlz.sourceforge.net/mysql_driver.html for some info about SDLZ 
> methods). It would be nice to have it in others, too, but BIND 
> does not pass it via current API, alas.
> > 
> > In all others 'client' struct member just becomes NULL, so 
> leads to segfault (yes, that's a bug).
> > 
> >> The $client$ parameter appears to work for zone transfers, as 
> per this
> >> example https://github.com/opennetadmin/ona/wiki/bind-dlz
> >> However if I use $client$ on any other queries bind segfaults.
> >> 
> >> Strace doesn't seem to show anything useful...
> >> 
> >> Ideas?
> >> 
> >> Thanks again,
> >> Mike
> >> 
> >> On Apr 1, 2013, at 2:51 PM, Michael McConnell 
> > 
> <mailto:mich...@winkstreaming.com>> wrote:
> >> 
> >>> Hello All,
> >>> 
> >>> I am trying to use Bind 9.9.2-P2 with the DLZ module, 
> however I continue
> >>> to run into segfault issues when trying to use $client$
> >>> 
> >>> {SELECT SQL_CACHE zone_name FROM dns_zones ? }
> >>> {{select zone_ttl AS ttl ?. WHERE geo_ip LIKE '$client$'}
> >>> 
> >>> I am trying to user $client$ in the A record lookup, not the zone
> >>> transfer. Is this possible?
> >>> 
> >>> Thanks so much,
> >>> Michael
> > 
> > 
> > -- 
> > Vadim Goncharov 
>RU-Center
> > NET 
> Departmenthttp://www.nic.ru
> > NET-SYS 
> Group phone:+7(495)737-7646  (ext.4019)
> > ___
> > 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
> 
> -- next part --
> An HTML attachment was scrubbed...
> URL: <https://lists.isc.org/pipermail/bind-
> users/attachments/20130403/5b6686cc/attachment-0001.html>
> 
> --
> 
> Message: 6
> Date: Wed, 3 Apr 2013 23:13:27 GMT
> From: Vernon Schryver 
> To: bind-users@lists.isc.org
> Subject: Re: RPZ and negative answers
> Message-ID: <201304032313.r33ndr3g014...@calcite.rhyolite.com>
> 
> > From: Chris Buxton 
> 
> > If a name exists in the response policy, and also exists in 
> the real
> > Internet namespace, the value from the policy is returned. But 
> if it
> > doesn't exist out on the Internet, then the value is not 
> returned --
> > an NXDOMAIN (or SERVFAIL, or whatever) is returned instead.
> >
> > I've known this for a while but haven't understood why it is thus.
> > Today, it has become a problem for me. If I set a policy of "this
> > name gets response X", I expect that policy to be used rather than
> > "this name gets response X unless it doesn't exist out on the
> > Internet or can't be resolved due to an error."
> 
> RPZ stands for "response policy zone" and concerns rewriting responses
> instead of queries.  The answer section of an NXDOMAIN or 
> SERFVAILresponse does not contain a domain name that could 
> trigger rewriting.
> 
> Rewriting queries instead of responses would fail to rewrite CNAME
> chains.
> 
> Even when the unrewritten response is an error such as NXDOMAIN, an
> RPZ action can be triggered by the name or address of any NS RR that
> is authoritative for the response and that is found in glue or 
> otherwise.
> Previous versions of the RPZ mechanism in BIND required ./configure
> settings to enable rpz-nsip and rpz-nsdname rules.  They 
> are enabled
> by default in future released versions of BIND as well as the 
> speed-up
> patches that can found by following the  link labeled 
> "Patch files for
> BIND9" on http://www.redbarn.org/dns/ratelimits
> 
> 
> Vernon Schryverv...@rhyolite.com
> 
> 
> --
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> End of bind-users Digest, Vol 1487, Issue 2
> ***
___
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