RE: 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). > Tom, ** Full disclosure: I am directly involved in the Internet-Draft (I-D) referenced in the below response. Although this does not necessarily help you today, some colleagues and I are working on a new standard which addresses this problem in a more general way by introducing a new RR type. It provides several features beyond simply extending the $GENERATE directive to enormous proportions such as: allowing AXFR transfers of the "intent" of BULK record generation. If you are interested in learning more about this, please follow the link in my signature below. We appreciate any comments/ suggestions regarding this draft. Regards, John -- John Woodworth CenturyLink, Inc. Q. Can a $GENERATE work for DNS on a /64 of reverse?? A. BULK CAN [ http://tools.ietf.org/html/draft-woodworth-bulk-rr-02 ] > 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 > -- 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
DNSSEC and time.nist.gov
I've noticed a spike of ServFail responses on our caching resolvers due to some DNSSEC issues on time.nist.gov (CNAME to ntp1.glb.nist.gov). If anyone of you guys has a direct contact would you be so kind and notify them... http://dnsviz.net/d/time.nist.gov/dnssec/ -- BR, Rok ___ 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: Question about dynamic IPv6-PTR-Generation
Many thanks for your quick feedback. This is the configuration-option, where I'm searching for. But probably this will take some time, until it's accepted, tested, implemented...etc. What do you propose in the meantime instead of using wildcards or allow the clients to register themselves or making static PTR-entries? How does other companies handle this issue? Kind regards, Tom On 08/26/2016 09:17 AM, Woodworth, John R wrote: 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). Tom, ** Full disclosure: I am directly involved in the Internet-Draft (I-D) referenced in the below response. Although this does not necessarily help you today, some colleagues and I are working on a new standard which addresses this problem in a more general way by introducing a new RR type. It provides several features beyond simply extending the $GENERATE directive to enormous proportions such as: allowing AXFR transfers of the "intent" of BULK record generation. If you are interested in learning more about this, please follow the link in my signature below. We appreciate any comments/ suggestions regarding this draft. Regards, John -- John Woodworth CenturyLink, Inc. Q. Can a $GENERATE work for DNS on a /64 of reverse?? A. BULK CAN [ http://tools.ietf.org/html/draft-woodworth-bulk-rr-02 ] 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 -- 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: Question about dynamic IPv6-PTR-Generation
Hello Tom I only know of Knot having a feature available for this use case: https://www.knot-dns.cz/docs/2.x/html/configuration.html#synth-record-automatic-forward-reverse-records Daniel On 26.08.16 11:51, Tom wrote: > Many thanks for your quick feedback. > > This is the configuration-option, where I'm searching for. But probably > this will take some time, until it's accepted, tested, > implemented...etc. What do you propose in the meantime instead of using > wildcards or allow the clients to register themselves or making static > PTR-entries? How does other companies handle this issue? > > Kind regards, > > Tom > > > > On 08/26/2016 09:17 AM, Woodworth, John R wrote: >>> 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). >>> >> Tom, >> >> ** Full disclosure: I am directly involved in the Internet-Draft (I-D) >> referenced in the below response. >> >> Although this does not necessarily help you today, some colleagues and I >> are working on a new standard which addresses this problem in a more >> general way by introducing a new RR type. It provides several features >> beyond simply extending the $GENERATE directive to enormous proportions >> such as: allowing AXFR transfers of the "intent" of BULK record >> generation. If you are interested in learning more about this, please >> follow the link in my signature below. >> >> We appreciate any comments/ suggestions regarding this draft. >> >> >> Regards, >> John ___ 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: > 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] Caching web pages has nothing to do with DNS caching. -- 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: Question about dynamic IPv6-PTR-Generation
On 26.08.16 07:34, Tom Tom wrote: I'm searching a way to respond to IPv6-PTR-Queries like the "$GENERATE"-mechanism for IPv4 has done it. why? configuring single IP addresses or taking them from DHCP is easier than creating new useless mechanism. -- 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 like a teepee: no Windows, no Gates and an apache inside... ___ 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: Question about dynamic IPv6-PTR-Generation
On 26 August 2016 at 13:45, Matus UHLAR - fantomas wrote: > On 26.08.16 07:34, Tom Tom wrote: > >> I'm searching a way to respond to IPv6-PTR-Queries like the >> "$GENERATE"-mechanism for IPv4 has done it. >> > > why? configuring single IP addresses or taking them from DHCP is easier > than > creating new useless mechanism. > That's not necessarily true for IPv6, where even a modest network could have trillions of addresses that may need PTR records. ___ 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: Question about dynamic IPv6-PTR-Generation
On 26 August 2016 at 15:41, Matus UHLAR - fantomas wrote: > >>> On 26.08.16 14:01, Matthew Pounsett wrote: > >> That's not necessarily true for IPv6, where even a modest network could >> have trillions of addresses that may need PTR records. >> > > that's exactly why using $GENERATE and/or creating new mechanism for that > is > useless. > $GENERATE is useless in that situation, yes. But something that provides rules to a name server to synthesize responses (vs actually generating all 18446744073709551616 PTRs in a /64) is not. ___ 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: Question about dynamic IPv6-PTR-Generation
On 26.08.16 07:34, Tom Tom wrote: I'm searching a way to respond to IPv6-PTR-Queries like the "$GENERATE"-mechanism for IPv4 has done it. On 26 August 2016 at 13:45, Matus UHLAR - fantomas wrote: why? configuring single IP addresses or taking them from DHCP is easier than creating new useless mechanism. On 26.08.16 14:01, Matthew Pounsett wrote: That's not necessarily true for IPv6, where even a modest network could have trillions of addresses that may need PTR records. that's exactly why using $GENERATE and/or creating new mechanism for that is useless. We better need something to identify network itself (even /64 is too much of IPS) and not necessarily each IPs within that network. -- 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. "To Boot or not to Boot, that's the question." [WD1270 Caviar] ___ 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: Question about dynamic IPv6-PTR-Generation
Tom wrote: > This is the configuration-option, where I'm searching for. But probably this > will take some time, until it's accepted, tested, implemented...etc. What do > you propose in the meantime instead of using wildcards or allow the clients > to register themselves or making static PTR-entries? How does other > companies handle this issue? A very popular option is to only create or delegate IPv6 PTR entries for hosts with static address assignments, and to return NXDOMAIN for address space used for dynamic address assignments. -- Robert Edmonds ___ 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: Question about dynamic IPv6-PTR-Generation
>A very popular option is to only create or delegate IPv6 PTR entries for >hosts with static address assignments, and to return NXDOMAIN for >address space used for dynamic address assignments. I talk to a lot of large providers at M3AAWG and that's the consensus about what to do. If it doesn't have a static address, it's not a server and it doesn't need rDNS. R's, John ___ 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
On Thu, Aug 25, 2016 at 6:25 PM, project722 wrote:
> 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:
>>
>>
> {
>> 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";
>> };
>>
>>
"allow-transfer { key tsigkeyext; };" means that the key tsigkeyext is the
only way to transfer this zone.
You define "other_xfer_allowed_ns" but I do not see it used anywhere.
Most likely what you want is:
allow-transfer { key tsigkeyext; other_xfer_allowed_ns; };
So that either the TSIG key can be used, or any of the IP's can transfer
regardless of TSIG.
(I don't know of a way to restrict a transfer to a specific IP *and*
require TSIG)
As to which view they "se
Re: DNS views TSIG and zone xfers
Thanks Bob, that is exactly what I ended up doing. And its working great
now. You are also right about the view selection.
On Fri, Aug 26, 2016 at 3:43 PM, Bob Harold wrote:
>
> On Thu, Aug 25, 2016 at 6:25 PM, project722 wrote:
>
>> 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:
>>>
>>>
>
>> {
>>> 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";
>>> };
>>>
>>>
> "allow-transfer { key tsigkeyext; };" means that the key tsigkeyext is
> the only way to transfer this zone.
>
> You define "other_xfer_allowed
