Re: This is a test. Please disregard.

[Benny Pedersen]

On 2016-08-26 07:09, project722 wrote:

syccessfully breaks dkim from gmail


___
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

This is a test. Please disregard.

[project722]

___
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: Need of caching on bind server

[Harshith Mulky]

Thank you John, Mukund, Barry and Dave for your insights and answers on this 
Topic.


@Dave, Lets say we have a Web Page cached(when queried by User 1) and the 
webpage has either moved the Link ( accessing the same Link from a different 
user would result in '504 Timeout' as it was cached by the Server)

So do we mean, every other user when querying the web page still gets the same 
link which was cached and now not reachable?

There should be some way, this should not happen

[P.S: I was trying a web link yesterday, and i got into this issue, but I was 
still able to open the cached web page link 2 days ago]


Thanks

Harshith


From: Woodworth, John R 
Sent: Thursday, August 25, 2016 10:46 AM
To: 'Harshith Mulky'; bind-users@lists.isc.org
Cc: Woodworth, John R
Subject: RE: Need of caching on bind server

> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
> Harshith Mulky
> Sent: Thursday, August 25, 2016 12:47 AM
> To: bind-users@lists.isc.org
> Subject: Need of caching on bind server
>
> Hello,
>
> I am trying to understand why caching is required on the bind server,
> when the client receiving the responses would be caching based on TTL
>  values.
>


Harshith,

I had the same question a number of years back and after gathering a fair
amount of statistics found we were seeing roughly 95% to 98% hit rates
for the cache.  This is a huge win when the answers are local to the
caching nameserver vs. recursively hitting the network again and again.

In the end if the site is unpopular (lower than 5% of nameserver traffic)
it does not really matter much but for everything else it will matter a
great deal.

My findings are likely an extreme case and the traffic of your nameservers
will depend greatly on the size of your client base so you may want to
run some tests of your own to see just how valuable the cache is.


Regards,
John


> So,
> Is caching required on the server, if the client is not able to cache
> such responses? Isn't it a overhead on both the client and server
> systems to cache the same responses at respective ends
> What are the possible Use cases of caching the responses at the Server?
> What if there is a dynamic updates of Records on Server and Server
> still sends the cached Responses?

BTW: Dynamic or not, caching is an expected part of DNS and implementors
 should take this into careful consideration when implementing
 protocols relying on DNS as a service component.


>
> Thanks
> Harshith
>

-- THESE ARE THE DROIDS TO WHOM I REFER:


This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
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: Slaves or Forwarders?

[Mark Andrews]

In message <7db0887c1dbf4ce0b1590ee09d2cb...@mxph4chrw.fgremc.it>, "Darcy Kevin 
(FCA)" writes:
> AXFR over UDP is explicitly undefined. See RFC 5936 Section 4.2. Given
> this, I would have expected either a FORMERR response (interpreting the
> request itself as "illegal"), or a NOTIMPL response (interpreting
> "undefined" as "might have been defined by an RFC subsequent to 5936, but
> I don't happen to know about it"). NOERROR response with TC is surprising.

Named sends FORMERR.
 
> IXFR over UDP is defined (RFC 1995 Section 2), but not implemented
> (apparently) by BIND. So NOTIMPL would seem appropriate.

Named sends back the current SOA record over UDP.  This is equivalent
to "up to date" or "retry over TCP as the answer will not fit in
the space available" depending upon the serial in the request.

Mark

>   - Kevin
> 
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of S Carr
> Sent: Thursday, August 25, 2016 4:09 PM
> To: bind-users
> Subject: Re: Slaves or Forwarders?
> 
> On 25 August 2016 at 21:06, Matus UHLAR - fantomas  wrote:
> > just IXFRs or AXFRs too?
> > Isn't edns over UDP enough in many cases?
> 
> >From what I've seen in past testing any attempt to request an AXFR against 
> >BIND using UDP gets an immediate TC response.
> 
> Steve
> ___
> 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

-- 
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: DNS views TSIG and zone xfers

[project722]

Actually, I got to thinking about this. The "other_allowed_ns" ACL is in
the global options, along with an "allow-transfer" for that ACL. So, I
*think* they will still be able to zone transfer via the global option
based on simply IP. BUT...since I have multiple views, which zones from
which views get sent over to these servers and how will they know how to
handle the info if zones from both views get sent. Would something like
this help:

allow-transfer { other_allowed_ns; view "external"; };

So they only get sent the zones from the external view?

On Thu, Aug 25, 2016 at 5:14 PM, project722  wrote:

> I have successfully setup TSIG keys for "views" using a DNS master/server
> pair. Zone transfers are working as expected between the 2 servers for each
> view. Before we go live into production with this I need some clarification
> on a couple things. Our prod servers are also allowing zone transfers to a
> few other servers besides the slave server. We have an acl setup that looks
> similar to this:
>
> other_xfer_allowed_ns {
> x.x.x.x; // This is our Secondary DNS server
> 127.0.0.1; // localhost can make zone transfers
> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> }; // end of "other_xfer_allowed" ACL
>
> And in the "allow transfer" statement we have included that ACL. My
> question is:
>
> Now that we are using TSIG, will I need to get with the admins of all
> these other servers and provide them my TSIG key so they can request zone
> transfers? I would think somehting like that needs to be done since it was
> required to be configured on slave server, but I am not sure. I'd rather do
> an IP based control just for these other servers instead of TSIG but I am
> not sure how that would look or how to set that up in the context of my
> config. How can I tell my conf to NOT force these other xfer allowed
> servers to use TSIG and use IP only? This gets complicated when you start
> throwing views into the mix.
>
> acl internal {
> 192.168.200.0/24; // corpnet
> };
>
> acl external {
> 192.168.201.0/24;
> 192.168.202.0/24;
> };
>
>
>  other_xfer_allowed_ns {
> x.x.x.x; // This is our Secondary DNS server
> 127.0.0.1; // localhost can make zone transfers
> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> }; // end of "other_xfer_allowed" ACL
>
>
> key "tsigkey" {
> algorithm HMAC-SHA512;
> secret   "x";
> };
>
> key "tsigkeyext" {
> algorithm HMAC-SHA512;
> secret  "xx";
> };
>
>
> view "corpnet" {
>   match-clients { internal; key tsigkey;
> };
>
>   //IP of slave server
>   server 192.168.173.78 {
>   keys { tsigkey; };
> };
>
>   also-notify {
>   192.168.173.78;
> };
>
>   zone "." IN {
>   type hint;
>   file "named.ca";
> };
>
>   zone"internalzone1.com" IN {
>   type master;
>   file "internalzone1.com";
>   allow-transfer { key tsigkey; };
> };
>
>   zone"sharedzone.com" IN {
>   type master;
>   file "sharedzone1.com";
>   allow-transfer { key tsigkey; };
> };
>
>  include "/etc/named.rfc1912.zones";
>   include "/etc/named.root.key";
> };
>
>
> view "external" {
>   match-clients { external; key tsigkeyext; };
>
>   //IP of slave server
>   server 192.168.173.78 {
>   keys { tsigkeyext; };
> };
>
>also-notify {
>   192.168.173.78;
> };
>
> zone "." IN {
> type hint;
> file "named.ca";
> };
>
> zone"externalzone1.com" IN {
> type master;
> file "externalzone1";
> allow-transfer { key tsigkeyext; };
>
> zone"sharedzone.com" IN {
> type master;
> file "sharedzone2.com";
> allow-transfer { key tsigkeyext; };
>  };
> include "/etc/named.rfc1912.zones";
> include "/etc/named.root.key";
>  };
>
>
___
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

DNS views TSIG and zone xfers

[project722]

I have successfully setup TSIG keys for "views" using a DNS master/server
pair. Zone transfers are working as expected between the 2 servers for each
view. Before we go live into production with this I need some clarification
on a couple things. Our prod servers are also allowing zone transfers to a
few other servers besides the slave server. We have an acl setup that looks
similar to this:

other_xfer_allowed_ns {
x.x.x.x; // This is our Secondary DNS server
127.0.0.1; // localhost can make zone transfers
x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
}; // end of "other_xfer_allowed" ACL

And in the "allow transfer" statement we have included that ACL. My
question is:

Now that we are using TSIG, will I need to get with the admins of all these
other servers and provide them my TSIG key so they can request zone
transfers? I would think somehting like that needs to be done since it was
required to be configured on slave server, but I am not sure. I'd rather do
an IP based control just for these other servers instead of TSIG but I am
not sure how that would look or how to set that up in the context of my
config. How can I tell my conf to NOT force these other xfer allowed
servers to use TSIG and use IP only? This gets complicated when you start
throwing views into the mix.

acl internal {
192.168.200.0/24; // corpnet
};

acl external {
192.168.201.0/24;
192.168.202.0/24;
};


 other_xfer_allowed_ns {
x.x.x.x; // This is our Secondary DNS server
127.0.0.1; // localhost can make zone transfers
x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
}; // end of "other_xfer_allowed" ACL


key "tsigkey" {
algorithm HMAC-SHA512;
secret   "x";
};

key "tsigkeyext" {
algorithm HMAC-SHA512;
secret  "xx";
};


view "corpnet" {
  match-clients { internal; key tsigkey;
};

  //IP of slave server
  server 192.168.173.78 {
  keys { tsigkey; };
};

  also-notify {
  192.168.173.78;
};

  zone "." IN {
  type hint;
  file "named.ca";
};

  zone"internalzone1.com" IN {
  type master;
  file "internalzone1.com";
  allow-transfer { key tsigkey; };
};

  zone"sharedzone.com" IN {
  type master;
  file "sharedzone1.com";
  allow-transfer { key tsigkey; };
};

 include "/etc/named.rfc1912.zones";
  include "/etc/named.root.key";
};


view "external" {
  match-clients { external; key tsigkeyext; };

  //IP of slave server
  server 192.168.173.78 {
  keys { tsigkeyext; };
};

   also-notify {
  192.168.173.78;
};

zone "." IN {
type hint;
file "named.ca";
};

zone"externalzone1.com" IN {
type master;
file "externalzone1";
allow-transfer { key tsigkeyext; };

zone"sharedzone.com" IN {
type master;
file "sharedzone2.com";
allow-transfer { key tsigkeyext; };
 };
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
 };
___
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: Slaves or Forwarders?

[Darcy Kevin (FCA)]

AXFR over UDP is explicitly undefined. See RFC 5936 Section 4.2. Given this, I 
would have expected either a FORMERR response (interpreting the request itself 
as "illegal"), or a NOTIMPL response (interpreting "undefined" as "might have 
been defined by an RFC subsequent to 5936, but I don't happen to know about 
it"). NOERROR response with TC is surprising.

IXFR over UDP is defined (RFC 1995 Section 2), but not implemented (apparently) 
by BIND. So NOTIMPL would seem appropriate.

- Kevin

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of S Carr
Sent: Thursday, August 25, 2016 4:09 PM
To: bind-users
Subject: Re: Slaves or Forwarders?

On 25 August 2016 at 21:06, Matus UHLAR - fantomas  wrote:
> just IXFRs or AXFRs too?
> Isn't edns over UDP enough in many cases?

>From what I've seen in past testing any attempt to request an AXFR against 
>BIND using UDP gets an immediate TC response.

Steve
___
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: Slaves or Forwarders?

[S Carr]

On 25 August 2016 at 21:06, Matus UHLAR - fantomas  wrote:
> just IXFRs or AXFRs too?
> Isn't edns over UDP enough in many cases?

>From what I've seen in past testing any attempt to request an AXFR
against BIND using UDP gets an immediate TC response.

Steve
___
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: Slaves or Forwarders?

[Matus UHLAR - fantomas]

In message <844475874024407090c1c2e9d5718...@mxph4chrw.fgremc.it>, "Darcy Kevin
(FCA)" writes:

From an InfoSec standpoint, of course one would prefer to use
cryptographic methods of securing DNS data, but, in the absence of that,
slaving could, arguably, be considered more secure than forwarding, in
the sense that forwarding usually generates more network transactions,
over time, for any given resolution of any given name, and thus more
chances for a bad guy to successfully spoof a response and have that
forged answer be cached.

One could also eke out a small measure of extra security (again, if
cryptographic methods are for some reason unavailable) by turning off
IXFR and thus causing all zone transfers to occur with AXFR, which is
TCP-based and thus presumably harder to spoof. But, that's a heavy price
to pay for a small increment of extra security. Better to go for crypto,
at that point, either within the DNS protocol itself (e.g. TSIG, DNSSEC),
by implementing (as many have) an out-of-band method of replicating zone
data (e.g. rsync-over-ssh, Infoblox-style "grid replication" over OpenVPN
tunnels) or by securing *all* communicati on between nameserver instances
(e.g. IPSEC tunnels).


On 24.08.16 08:00, Mark Andrews wrote:

named only accepts IXFR over TCP.  While the protocol supports sending
deltas with IXFR/UDP named does not use that part of the protocol.


just IXFRs or AXFRs too?
Isn't edns over UDP enough in many cases?
--
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.
Linux IS user friendly, it's just selective who its friends are...
___
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: DNSKEY and RRSIG DNSKEY TTL values aren't changed after changing of zone's TTL

[Thomas Schulz]

> In message 
> 

DNS views and zone transfers

[project722]

I have successfully setup TSIG keys for "views" using a DNS master/server
pair. Zone transfers are working as expected between the 2 servers for each
view. Before we go live into production with this I need some clarification
on a couple things. Our prod servers are also allowing zone transfers to a
few other servers besides the slave server. We have an acl setup that looks
similar to this:

other_xfer_allowed_ns {
x.x.x.x; // This is our Secondary DNS server
127.0.0.1; // localhost can make zone transfers
x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
}; // end of "other_xfer_allowed" ACL

And in the "allow transfer" statement we have included that ACL. My
question is:

Now that we are using TSIG, will I need to get with the admins of all these
other servers and provide them my TSIG key so they can request zone
transfers? I would think somehting like that needs to be done since it was
required to be configured on slave server, but I am not sure.

Next,

I setup views so that clients on the "internal" network when requesting a
record would be presented with different records than clients on the
outside. And at the moment there is only one zone that is required to have
different records. However, It is my understanding that since views are
based off source IP's, if I was to ONLY include that one zone in my
"internal" view, if a record was requested for another zone from that same
IP, they would probably get an nxdomain answer since that IP is limited to
that one view.

So, my question is, will I need to include all zones in both views so that
all clients can get results, even though I would only have (at the moment)
one zone that points to two different zone files? All others in both views
would point to the same zone file, unless of course there is another zone
we need to present a different view to for internal clients.

Now, last question.

I have a concern about the allow-query statement. On our production server
we have an ACL list we'll call it "trusted".
We have an allow query statement in the global options to only allow
queries from IP's in the trusted ACL. However every one of our zone entries
in the conf file also has an "allow-query { any; }; statement. Doesn't that
defeat the purpose of have a "trusted" ACL for queries? Is this bad design?
___
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: Need of caching on bind server

[Barry Margolin]

In article ,
 Harshith Mulky  wrote:

> I am trying to understand why caching is required on the bind server, when 
> the client receiving the responses would be caching based on TTL values.

A typical caching server has multiple clients. If they're an ISP, it 
will have thousands of clients, and public DNS servers like OpenDNS and 
Google DNS it may have hundreds of thousands. So even if the clients 
have caches of their own (which many do not), the cache is useful so 
that when different clients look up the same name they can be returned 
from cache.

For example, consider all the thousands of lookups for things like 
google.com, twitter.com, etc. that an ISP receives every second. If they 
didn't cache these responses, DNS traffic might rival YouTube (OK, 
that's an exaggeration).

-- 
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: DNSKEY and RRSIG DNSKEY TTL values aren't changed after changing of zone's TTL

[Aleks Ostapenko]

To make zone dinamically updated - I added into `zone` section of
named.conf 'allow-update { any; };' directive and made `rndc reload` after
that.

Then I made `rndc freeze `. But after this command - the
signed zone file (`.signed`) still remain
in raw format (not text readable) - so I can read it via
`named-compilezone` utility, but unfortunately I can't change it.

Kind regards,
Aleks Ostapenko
___
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: Need of caching on bind server

[Dave Warren]

> I am trying to understand why caching is required on the bind server,
> when the client receiving the responses would be caching based on TTL
> values. 
> 
> So,
> Is caching required on the server, if the client is not able to
> cache such responses? Isn't it a overhead on both the client and server
> systems to cache the same responses at respective ends
> What are the possible Use cases of caching the responses at the Server?
> What if there is a dynamic updates of Records on Server and
> Server still sends the cached Responses? 

Ubiquitous client-side DNS caching on workstations is relatively new in
the grand scheme of things, and shouldn't be assumed to exist. Also,
client side caches may be limited in size, may expire data far sooner
than the TTL, and with mobile devices, may dump their entire cache
frequently (perhaps every time the device jumps between networks).

Beyond that, think about the number of queries a resolver must perform
to visit a website, we first need the roots (hints or cached), then the
authoritative NS for the gTLD, then the NS for the domain, and oops it's
in another gTLD so we look that up, from the root again, etc, all just
to get a CNAME for a CDN in yet another TLD, and now a single call to a
single website has taken 10-15 separate queries just to get the final A
record.

I haven't done actual statistics, but I've yet to see any time when my
resolvers don't have the authoritative servers for COM, NET, INFO, ORG,
CA, and various other TLDs in the cache.

Plus, even if you do assume that clients cache effectively, AND you
ignore the resolver's internal needs, most DNS resolvers serve more than
one user and as such, in a company of a few hundred employees (or an ISP
with a tens or hundreds of thousands), at any one time at least half are
watching cat videos from YouTube, so the cache will help the next 'x'
number of users who all need to know www.youtube.com and it's CDN
services. Most of the internet uses Google Analytics, AdWords,
DoubleClick, has Facebook or Twitter links, Disqus, etc, all of those
are in cache approximately 100% of the time if you have more than a
handful of users.

Or maybe I am completely missing your point?

___
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