Re: hosts or subnet number in delegation?

[Doug Barton]

On 02/23/10 23:01, sasa sasa wrote:
> Hello,
> 
> for a 192.168.199.64/26 in zone file to delegate to a customer;
> should i put subnet number:
> 
> 64/26 IN NS ns1.example.com.
> 64/26 IN NS ns2.example.com.
> 
> or host ranges:
> 
> 64-126 IN NS ns1.example.com.
> 64-126 IN NS ns2.example.com.
> 
> .
> .
> $GENERATE 65-126 $ CNAME $.65-126 

I always use the range for several reasons, mostly related to ease of
management. I like to give my zone files the same names as the zones
they represent, and names with / in them require subdirectories. The /
can also require special handling in scripts. Finally the range makes it
very clear exactly what IP addresses are intended to be part of the zone
which cuts down on errors in the parent /24 zone file (especially when
you correctly specify the range, which you did not do above). :)


hth,

Doug

-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

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

Re: Fwd: IPv6 client and negative cache - some doubts

[Kevin Darcy]

As Mark explained, the server is marked as bad because it returned an 
illegal response.


If *all* of the nameservers which would be used to answer a particular 
query are marked as bad, then the query fails. This is as it should be.


The fact that you see some residue in the cache that _could_, in some 
way, shape or form, allow the query to be answered, doesn't change the 
fact that named doesn't trust nameservers that give illegal responses 
and is perfectly within its rights to avoid those nameservers for some 
period of time.





- Kevin


On 2/24/2010 1:48 AM, Michal Wesolowski wrote:
On Tue, Feb 23, 2010 at 11:19 PM, Mark Andrews > wrote:



In message
mailto:f677fefa1002230600n4694161cu315e5dd4beaaa...@mail.gmail.com>>,
Micha
l Wesolowski writes:
>
> sorry for replying directly, still have some problems with gmail UI.
>
> -- Forwarded message --
> From: Michal Wesolowski mailto:gmic...@gmail.com>>
> Date: Tue, Feb 23, 2010 at 2:47 PM
> Subject: Re: IPv6 client and negative cache - some doubts
> To: Sam Wilson mailto:sam.wil...@ed.ac.uk>>
>
>
> On Tue, Feb 23, 2010 at 1:33 PM, Sam Wilson mailto:sam.wil...@ed.ac.uk>> wrote:
>
> > In article
mailto:mailman.529.1266923597.21153.bind-us...@lists.isc.org>>,
> >  Michal Wesolowski mailto:gmic...@gmail.com>> wrote:
> >
> > > Hello Everyone
> > >
> > > I have a problem with Bind 9.3.6-P1 (included in Solaris 10)
but honestly
> > I
> > > don't even understand if it is wrong Bind behaviour or my
ignorance. It
> > does
> > > apply only to some specific cases when external domain
delegation is also
> > > somewhat broken. My server is caching only. Let me show it
by the
> > example:
> > >
> > Host "www.goleszow.pl " has bad NS
delegation on country root servers
> > level
> > > because virtual.sincom.pl  is not
resolvable:
> > >
> > > goleszow.pl .86400INNS
virtual.sincom.pl .
> > > goleszow.pl .86400INNS
virtual.jasnet.pl .
> > > ;; Received 91 bytes from 149.156.1.6#53(G-DNS.pl) in 19 ms
> >
> > That may be part of the problem, and it needs to be fixed, but
I don't
> > think that's all of it.
> >
>
> > > When dns client asks my server for A record of
"www.goleszow.pl " -
> > > everything is fine. But when first query (after cache is
flushed) asks
> > for
> > >  record - my server seems to cache negative answer and
all subsequent
> > > queries for A record also fails. ...
> > > [snip]
> > > This is what I found in the Bind cache:
> > > # rndc dumpdb -all
> > > # cat /var/named/log/named_dump.db | grep virt
> > > goleszow.pl .85994   NS
virtual.jasnet.pl .
> > > 85994   NS virtual.sincom.pl
.
> > > virtual.jasnet.pl .  3194A
  85.202.208.254
> > > virtual.sincom.pl .  3194  
 \-ANY   ;-$NXDOMAIN

> > > ; virtual.jasnet.pl  alias
jasnet.pl  [v4 TTL 3194] [target TTL 3194] [v4
> > > success] [v6 unexpected]
> > > ; virtual.sincom.pl  [v4 TTL 3194]
[v6 TTL 3194] [v4 nxdomain] [v6
> > nxdomain]
> > >
> > > Which for me doesn't explain this behaviour. Please advice.
> >
> > Note that line beginning "virtual.jasnet.pl
 alias jasnet.pl ".
jasnet.pl 
> > is delegated to ns10.az.pl  and ns11.az.pl
.  If you ask them for an A
> > record for virtual.jasnet.pl  you
get an A record; if you ask for 
> > you get a CNAME pointing to jasnet.pl .  I
can't imagine what sort of
> > configuration could cause that to happen.  I'm also not sure
how that
> > might be screwing up your lookups, but it's certainly weird.
 On the
> > 'fix what you know to be broken' principle I'd try to get that
and the
> > broken delegation sorted first before looking any further.
> >
> > Sam
> >
> >
> Thank you Sam for pointing this out. This is probably real
source of the
> problem. I looked over what could cause such situation and so
far found old
> b

Re: Blacklisting private address range

[Diosney Sarmiento Herrera]

Hi, Bill!

   Actually, we have the same point of view of the term "Internet",
because I'm in the same situation than you: I'm in a private network
that is conected to Internet trough NAT. I just misused the term, I had
to have used the term "public newtork" and not "Internet".

   In my private network I use an internal nameserver that forwards all
the "non-internal-domain" queries to an external nameserver(forwarder).
The question that I have made is referred to the forwarder nameserver.

   I agree with all of your proposals and solutions, and I think that
the best thing for us is to do that you recommend at the end: filter the
traffic of private addresses in the IP layer and not in the application
one. 

-- 
  Diosney



On Fri, 2010-02-26 at 09:53 -0700, Bill Larson wrote: 
> Diosney Sarmiento Herrera  said:
> 
> >   In our nameserver we do not apply the bogon filter to the bogus
> > addresses because it will change with time and we not know how update
> > them automatically.
> > 
> >   My question is that if it is useful to blacklist the private address
> > range(this addresses never change with time ;) ) so our nameserver will
> > never respond queries from this addresses.
> > 
> >   I ask if this is usefull because the private address range don't have
> > meaning of sense in Internet.
> 
> Your definition of what the Internet "is" and mine differs.  My network uses 
> addresses in the private IP space and is connected to the Internet using 
> NAT.  So, to me, the private address range DOES have a meaning in terms of 
> the Internet.
> 
> That being said, if you have no reason to accept DNS queries from sources 
> with IP addresses in the private address space, then sure, put them in 
> the "blackhole" option statement and your server will never respond to them.
> 
> One problem with having a large number of "allowed" and/or "disallowed" ACLs 
> in your "named.conf" file is that comparing source addresses against these 
> ACLs does take away resources from your server.  Implementing everything in 
> the "Secure BIND Template" (back when they included the "bogon" ACLS - sorry 
> I haven't reviewed this for a while) took it's toll on the server that I was 
> testing with.  This WAS a fair while back and the server wasn't that 
> powerful, but...  For me, at the time, the decrease in performance due to a 
> large list of "bogon" addresses was deemed acceptable.
> 
> Now, I think that the commonly accepted "Best Current Practice" is to block 
> Internet traffic based upon the source IP address at your router rather than 
> trying to control this at the application level.  But, if you don't have the 
> ability to do this at the router, then as a simple option it can be done at 
> the application level.
> 
> Bill Larson

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

Re: Blacklisting private address range

[John Wobus]

On Feb 26, 2010, at 9:54 AM, Diosney Sarmiento Herrera wrote:

Hi!

 Sorry for the delay.

 It was very useful for me. Thanks!

 In our nameserver we do not apply the bogon filter to the bogus
addresses because it will change with time and we not know how update
them automatically.

 My question is that if it is useful to blacklist the private address
range(this addresses never change with time ;) ) so our nameserver  
will

never respond queries from this addresses.

 I ask if this is usefull because the private address range don't have
meaning of sense in Internet.

 Thanks!

--
 Diosney



Re discarding queries from private space that came from the Internet:

Many sites would handle this at the routing level so as to protect  
more than just
bind, and to allow you to make use of private space within your own  
network.
An access list on a router interface would assure none of your own  
network
receives packets from private space that actually originated outside  
your network.
An app like bind can't sort out whether the packet with a source  
address in

private space came from your own network or came from the Internet at
large.

But if you've arranged things so this bind instance never receives  
traffic
from your own private space (e.g. if you aren't even using private  
space),
then you could certainly add such filtering to bind's normal access  
list.


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

Re: Blacklisting private address range

[Bill Larson]

Diosney Sarmiento Herrera  said:

>   In our nameserver we do not apply the bogon filter to the bogus
> addresses because it will change with time and we not know how update
> them automatically.
> 
>   My question is that if it is useful to blacklist the private address
> range(this addresses never change with time ;) ) so our nameserver will
> never respond queries from this addresses.
> 
>   I ask if this is usefull because the private address range don't have
> meaning of sense in Internet.

Your definition of what the Internet "is" and mine differs.  My network uses 
addresses in the private IP space and is connected to the Internet using 
NAT.  So, to me, the private address range DOES have a meaning in terms of 
the Internet.

That being said, if you have no reason to accept DNS queries from sources 
with IP addresses in the private address space, then sure, put them in 
the "blackhole" option statement and your server will never respond to them.

One problem with having a large number of "allowed" and/or "disallowed" ACLs 
in your "named.conf" file is that comparing source addresses against these 
ACLs does take away resources from your server.  Implementing everything in 
the "Secure BIND Template" (back when they included the "bogon" ACLS - sorry 
I haven't reviewed this for a while) took it's toll on the server that I was 
testing with.  This WAS a fair while back and the server wasn't that 
powerful, but...  For me, at the time, the decrease in performance due to a 
large list of "bogon" addresses was deemed acceptable.

Now, I think that the commonly accepted "Best Current Practice" is to block 
Internet traffic based upon the source IP address at your router rather than 
trying to control this at the application level.  But, if you don't have the 
ability to do this at the router, then as a simple option it can be done at 
the application level.

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

Re: Help with logrotate and bind

[Diosney Sarmiento Herrera]

Hi Alan!

   I think that you are right. Sorry for that :(

   Thanks for the tip, but I want to save the logs using the syslog
facilities and with the date in the the log name. I looked into the
"logging" statement syntax and I think that the "file" and the "syslog"
options are mutually exclusive.

-- 
  Diosney



On Fri, 2010-02-26 at 10:08 -0500, Alan Clegg wrote: 
> Diosney Sarmiento Herrera wrote:
> 
> >I am trying to rotate my named logfile with logrotate and I
> > configured it as I show:
> 
> [...]
> 
> This is much more a question for a list that discusses the logrotate
> application than it is to bind-users.  I would recommend, however, that
> you look into the built-in ability of named to roll log files:
> 
> channel general_log {
> file "logs/general.log" versions 2 size 2m;
> severity info;
> };
> 
> will keep logs/general.log (current) and a .0 and .1 version of the
> file, all of 2m in size.  When the primary log exceeds this size,
> rolling is automatic.
> 
> AlanC
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

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

Re: Help with logrotate and bind

[David Forrest]

On Fri, 26 Feb 2010, Diosney Sarmiento Herrera wrote:


H
i!

  I am trying to rotate my named logfile with logrotate and I
configured it as I show:

#
#   Logrotate fragment for bind.
#
/var/log/named.log {
   daily
   ifempty
   compress
   delaycompress
   dateext
   rotate 14
   missingok
   nocreate
}

  The problem is that when the log is rotated the file
"/var/log/named.log" dissapear.

  How I can fix this issue?

  By the way, there is a need to include a prerotate and postrotate
scripts?

  Thanks in advance!



You have nocreate specified and that may be the problem.  I have:
create 0644 named named
in my logrotate.conf and it rotates properly.
And I have no pre or postrotate scripts.
Dave


--
David Forrest
Maple Park Development Corporation 
St. Louis, Missouri

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

Re: Help with logrotate and bind

[Alan Clegg]

Diosney Sarmiento Herrera wrote:

>I am trying to rotate my named logfile with logrotate and I
> configured it as I show:

[...]

This is much more a question for a list that discusses the logrotate
application than it is to bind-users.  I would recommend, however, that
you look into the built-in ability of named to roll log files:

channel general_log {
file "logs/general.log" versions 2 size 2m;
severity info;
};

will keep logs/general.log (current) and a .0 and .1 version of the
file, all of 2m in size.  When the primary log exceeds this size,
rolling is automatic.

AlanC



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Help with logrotate and bind

[Diosney Sarmiento Herrera]

H
i!

   I am trying to rotate my named logfile with logrotate and I
configured it as I show:

#
#   Logrotate fragment for bind.
#
/var/log/named.log {
daily
ifempty
compress
delaycompress
dateext
rotate 14
missingok
nocreate
}

   The problem is that when the log is rotated the file
"/var/log/named.log" dissapear.
   
   How I can fix this issue?

   By the way, there is a need to include a prerotate and postrotate
scripts? 

   Thanks in advance! 

-- 
  Diosney




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

Help with logrotate and bind

[Diosney Sarmiento Herrera]

Hi!

   I am trying to rotate my named logfile with logrotate and I
configured it as I show:

#
#   Logrotate fragment for bind.
#
/var/log/named.log {
daily
ifempty
compress
delaycompress
dateext
rotate 14
missingok
nocreate
}

   The problem is that when the log is rotated the file
"/var/log/named.log" dissapear.
   
   How I can fix this issue?

   By the way, there is a need to include a prerotate and postrotate
scripts? 

   Thanks in advance! 

-- 
  Diosney




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

Re: Blacklisting private address range

[Diosney Sarmiento Herrera]

Hi!

  Sorry for the delay.

  It was very useful for me. Thanks!

  In our nameserver we do not apply the bogon filter to the bogus
addresses because it will change with time and we not know how update
them automatically.

  My question is that if it is useful to blacklist the private address
range(this addresses never change with time ;) ) so our nameserver will
never respond queries from this addresses.

  I ask if this is usefull because the private address range don't have
meaning of sense in Internet.

  Thanks!

-- 
  Diosney



On Wed, 2010-02-24 at 02:30 -0700, Bill Larson wrote: 
> On Feb 23, 2010, at 7:56 PM, Diosney Sarmiento Herrera wrote:
> 
> > Hi!
> >
> >Have any sense to blacklist the private address ranges on a server
> > that is facing Internet? I mean, this address ranges is not even  
> > routed
> > on the Internet.
> >
> >There is a trick about this?
> 
> No trick, it is commonly done.  For a good example of this (and many  
> other things), see the Secure BIND Template at 
> http://www.cymru.com/Documents/secure-bind-template.html 
> .
> 
> Bill Larson

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

RE: Question about dig command

[Khuu, Linh MicroTech]

Thanks Stephane!!! Adding ::1 in the ACL did the trick.

Linh Khuu

-Original Message-
From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] 
Sent: Thursday, February 25, 2010 11:09 AM
To: Khuu, Linh MicroTech
Cc: 'bind-users@lists.isc.org'
Subject: Re: Question about dig command

On Thu, Feb 25, 2010 at 10:58:49AM -0500,
 Khuu, Linh   MicroTech  wrote 
 a message of 54 lines which said:

> client ::1#33086: query (cache) 'dnssec12.datamtn.com//IN' denied
> 
> Then I switched to use the ???dig??? command from 9.4.1-P1 to query the same 
>  record, I got result nicely.

Possible reason: the recent dig can use IPv6 *transport* (talking to
the server with IPv6, not just asking IPv6 *data*). But may be ::1
(localhost in IPv6) is not authorized by your name server. Check the
ACL, try dig with -4 (or @127.0.0.1), etc.



PGP.sig
Description: PGP signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Alan Clegg]

Jonathan de Boyne Pollard wrote:

> That's also nothing to do with DNSCurve.  You weren't making a DNSCurve
> query there.  You were simply querying, with an ordinary DNS query, a
> proxy DNS server that is under someone else's control and getting the
> view of the DNS namespace that that someone else chose to give to you.
> OpenDNS have "subverted" you (inasmuch as one can call accepting control
> of the DNS namespace from people who deliberately hand it over to them
> "subversion") entirely without DNSCurve.  This is simply the well-known
> risk of using other people's proxy servers.  There's nothing new here,
> and nothing related to DNSCurve here.

I fully understand that this was not a DNSCurve query.  My point was
that this "ability" of OpenDNS will go away if and when they choose a
technology that actually provides end-to-end validation of the DNS
query/response in question.

Why would OpenDNS adopt a technology that destroys their own business
model?  They argue against DNSSEC, yet they implement DNSCurve.

Interesting...

Anyway, this has gone far enough off-topic ("bind-users") that I'm going
to curtail my responses here.  Feel free to follow up with me directly
if you'd like.

AlanC



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: check-names vs. acl

[Matus UHLAR - fantomas]

> In message <20100225123134.gb2...@fantomas.sk>, Matus UHLAR - fantomas writes:
> > On 25.02.10 12:01, Matus UHLAR - fantomas wrote:
> > > I see that hosts that are not allowed to recurse are often generating
> > > check-named errors.
> > 
> > check-names it is.
> > 
> > I apparently too often use "named" so I do this king of mistypes.
> > 
> > > I wonder if it wouldn't be better to check ACL's first and check-names 
> > > just
> > > after it?

On 26.02.10 13:08, Mark Andrews wrote:
> It really depends what's more important for you to see.  Whether
> you got a recursive query that didn't match a acl or a query that
> failed check-names.  Both get REFUSED so the client can't tell the
> difference.

I personally don't care about broken requests from unknown IPs and would
like to log them as unauthorized, not invalid requests.
My question is if this is acceptable and doable.
-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Quantum mechanics: The dreams stuff is made of. 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users