Re: DNSKEY and RRSIG DNSKEY TTL values aren't changed after changing of zone's TTL
Aleks Ostapenko wrote: > > 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. Ah, I should have checked that more thoroughly, sorry - I wasn't sure if the signed zone followed the unsigned master file format or did something else... You can use `named-compilezone` to convert from raw to text, edit the text, then convert back to raw. e.g. $ named-comilezone -f raw -F text -o myzone.text myzone myzone.signed $ vi myzone.text $ named-comilezone -f text -F raw -o myzone.signed myzone myzone.text Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Northwest Fitzroy, Sole: Variable becoming southwesterly 3 or 4, occasionally 5 later. Moderate. Showers. 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
Re: Need of caching on bind server
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
DNS views and zone transfers
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: DNSKEY and RRSIG DNSKEY TTL values aren't changed after changing of zone's TTL
> In message > > , =?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCe0YHRgtCw0L/QtdC90LrQvg==?= writes: > > Hello. > > > > I'm using BIND 9.9.5. > > My steps: > > > >1. Sign zone using one 1 ZSK and 2 KSK: a) adding "*auto-dnssec > >maintain;*" and "*inline-signing yes;*" directive into zone section of > >named.conf; b) setting publication and activation timestamps to current > >time in key files; c) *rndc reload*. > >2. Change TTL value in the zone file ($TTL 86400 ==> $TTL 432000). > >3. Increase serial number in SOA record by 1. > >4. *rndc reload*. > > > > After that - DNSKEY and RRSIG DNSKEY records still have 86400 value in TTL > > (checked via *dig*). > > What could be the reason for such behavior? When you use inline-signing yes, Bind increments the effictive serial number each time it makes a change in the zone as published. So the serial number actually being used is likely more that 1 more than the serial number in the zone file. So perhaps you should use dig to find the published serial number and then set the number in the zone file to be greater than that. > > Kind regards, > > Aleks Ostapenko > > Use "dnssec-settime -L ttl" > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org Tom Schulz Applied Dynamics Intl. sch...@adi.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: Slaves or Forwarders?
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: 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
RE: Slaves or Forwarders?
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
DNS views TSIG and zone xfers
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: DNS views TSIG and zone xfers
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
Re: Slaves or Forwarders?
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: Need of caching on bind server
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
This is a test. Please disregard.
___ 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: This is a test. Please disregard.
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
Question about dynamic IPv6-PTR-Generation
Hi list I'm searching a way to respond to IPv6-PTR-Queries like the "$GENERATE"-mechanism for IPv4 has done it. I read about Delegation, self-registration with "tcp-self" or using Wildcards with the disadvantage, that every query has the same response. Is there a (planned) way, to generate reverse-responses "on-the-fly" with bind? I'm using the latest bind (9.10.4-P2). Many thanks for your help. Kind regards, Tom ___ 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
