date:20160913

Re: forwarders (IPv6)

2016-09-13 Thread Mark Andrews


In message 
<3c929ce024ce174480d567360a8291b1ee69071...@hq1-mailmb-v1.trade.ftc.gov>, 
"Chakrapani, Praveen CTR via bind-users" writes:
>
> Hi,
>
> I added below line to my named.conf to include IPv6 addresses to the
> forwarders list. However I am getting this error "Sep 13 10:33:06
> servername named[24778]: [ID 873579 daemon.error] /etc/named.conf:158:
> expected IP address near '2001:1890:1C04:3000:0CB7:4432'"
>
> "forwarders { 12.227.230.4; 12.227.230.10; 12.183.68.50; 12.183.68.51;
> 12.71.76.50; 12.71.76.51; 2001:1890:1C04:3000:0CB7:4432;
> 2001:1890:1C04:3000:0CB7:4433; 2001:1890:1C04:3400:0C47:4C32;
> 2001:1890:1C04:3400:0C47:4C33; };
> forward first;"
>
> Please let know how to add IPv6 addresses to the forwarders list.

Add a syntactically valid IPv6 address.  2001:1890:1C04:3000:0CB7:4432
is NOT a valid IPv6 address.  It's missing 32 bits of the address.

Did you mean 2001:1890:1C04:3000::0CB7:4432 perhaps as you seem to
be encoding the IPv4 addresses in the last 32 bits?  Note the
double "::" signifying 32 zero bits in this case.

Mark
 
> Thanks,
> Praveen Kumar Chakrapani (CTR)
> AECOM Contractor, Lead UNIX Administrator
> Desk (202)326-3282
-- 
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: forwarders (IPv6)

2016-09-13 Thread Graham Clinch


I added below line to my named.conf to include IPv6 addresses to the
forwarders list. However I am getting this error *“Sep 13 10:33:06
servername named[24778]: [ID 873579 daemon.error] /etc/named.conf:158:
expected IP address near '2001:1890:1C04:3000:0CB7:4432'”*


That's because it's not a valid representation of an IPv6 address (it 
has only 6 hextets where you would expect to see 8, or a double-colon to 
mark compressed zeros):


2001:db8:a4:ea5c:0:0:53:a1 = 2001:db8:a4:ea5c::53:a1

Graham
___
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: forwarders (IPv6)

2016-09-13 Thread Darcy Kevin (FCA)

That's not a valid IPv6 address representation. You probably mistyped a double 
colon as a single colon in the middle of the address.

(RFC 4291)

2.2.  Text Representation of Addresses

   There are three conventional forms for representing IPv6 addresses as
   text strings:

   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to
  four hexadecimal digits of the eight 16-bit pieces of the address.
  Examples:

 ABCD:EF01:2345:6789:ABCD:EF01:2345:6789

 2001:DB8:0:0:8:800:200C:417A

  Note that it is not necessary to write the leading zeros in an
  individual field, but there must be at least one numeral in every
  field (except for the case described in 2.).

   2. Due to some methods of allocating certain styles of IPv6
  addresses, it will be common for addresses to contain long strings
  of zero bits.  In order to make writing addresses containing zero
  bits easier, a special syntax is available to compress the zeros.
  The use of "::" indicates one or more groups of 16 bits of zeros.
  The "::" can only appear once in an address.  The "::" can also be
  used to compress leading or trailing zeros in an address.



- Kevin


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Chakrapani, Praveen CTR via bind-users
Sent: Tuesday, September 13, 2016 4:48 PM
To: 'bind-users@lists.isc.org'
Subject: forwarders (IPv6)

Hi,

I added below line to my named.conf to include IPv6 addresses to the forwarders 
list. However I am getting this error "Sep 13 10:33:06 servername named[24778]: 
[ID 873579 daemon.error] /etc/named.conf:158: expected IP address near 
'2001:1890:1C04:3000:0CB7:4432'"

"forwarders { 12.227.230.4; 12.227.230.10; 12.183.68.50; 12.183.68.51; 
12.71.76.50; 12.71.76.51; 2001:1890:1C04:3000:0CB7:4432; 
2001:1890:1C04:3000:0CB7:4433; 2001:1890:1C04:3400:0C47:4C32; 
2001:1890:1C04:3400:0C47:4C33; };
forward first;"

Please let know how to add IPv6 addresses to the forwarders list.

Thanks,
Praveen Kumar Chakrapani (CTR)
AECOM Contractor, Lead UNIX Administrator
Desk (202)326-3282

___
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

forwarders (IPv6)

2016-09-13 Thread Chakrapani, Praveen CTR via bind-users

Hi,

I added below line to my named.conf to include IPv6 addresses to the forwarders 
list. However I am getting this error "Sep 13 10:33:06 servername named[24778]: 
[ID 873579 daemon.error] /etc/named.conf:158: expected IP address near 
'2001:1890:1C04:3000:0CB7:4432'"

"forwarders { 12.227.230.4; 12.227.230.10; 12.183.68.50; 12.183.68.51; 
12.71.76.50; 12.71.76.51; 2001:1890:1C04:3000:0CB7:4432; 
2001:1890:1C04:3000:0CB7:4433; 2001:1890:1C04:3400:0C47:4C32; 
2001:1890:1C04:3400:0C47:4C33; };
forward first;"

Please let know how to add IPv6 addresses to the forwarders list.

Thanks,
Praveen Kumar Chakrapani (CTR)
AECOM Contractor, Lead UNIX Administrator
Desk (202)326-3282

___
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 and zone transfers, cont

2016-09-13 Thread Bob Harold

On Tue, Sep 13, 2016 at 10:58 AM, project722  wrote:

> I have moved the new views into production, and all seems to be working
> fine. I have an "internal" view and an "external" view. I have noticed a
> few re-occuring messages in the logs of the master server that I'd like to
> suppress. Here is what I am seeing:
>
> 1) Warning: view external: 'empty-zones-enable/disable-empty-zone' not
> set: disabling RFC 1918 empty zones: 37 Time(s)
>
> 2) connect(fe80::216:3eff:fe37:b866#53) 22/Invalid argument: 7 Time(s)
>
> 3) zone 
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/IN/external:
> (master) removed: 1 Time(s)
>  zone 112/x.x.x.IN-ADDR.ARPA/IN: (master) removed: 1 Time(s)
>  zone x.x.x.in-addr.arpa/IN: (master) removed: 1 Time(s)
>
> For # 3 I basically see an entry for each of our reverse mapping zones,
> which are valid and I don't want them "removed" as the message states And I
> think these are related to #1. I believe I can fix #1 with the 
> "empty-zones-enable
> no;" in my external view, but I am not sure what effect it would have on
> the message generation or how it would affect zone behavior in that view.
>
> I have "empty-zones-enable yes;" in my options, and then
"empty-zones-enable no;" in the view that is forwarding.  So either define
it in every view, or define a default in the options.


> For #2, - I already have a statement "server fe80::/16 { bogus yes; };" in
> my named.conf. However it is above the options statement and I am now
> wondering if I need this defined in each view now. Also this 
> fe80::216:3eff:fe37:b866
> is not even my actual link local IP so I am not sure where/how that is
> being generated. My actual link local is
> fe80::f21f:afff:fedd:6a26/64
>
>
I have the "server ... bogus ..." statement in each view, so try it there.


> Any help is greatly appreciated.
>
> On Thu, Sep 8, 2016 at 11:33 AM, project722  wrote:
>
>> I am not seeing that but thanks for the heads up. I will keep an eye on
>> it.
>>
>> On Thu, Sep 8, 2016 at 10:14 AM, Bob Harold  wrote:
>>
>>> I changed the subject slightly, because I had to cut out a lot of the
>>> forwarded message - the list server was complaining about the size of the
>>> messages.
>>>
>>> I just found that my setup was not working completely as I expected.
>>> The view with only a few zones and forwarding to another view automatically
>>> got the "empty zones" created, so any queries in those zones did not get
>>> forwarded.  I am fixing it by adding to that view the line:
>>>empty-zones-enable no;
>>>
>>> --
>>> Bob Harold
>>>
>>>
>>> On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold  wrote:
>>>

 On Thu, Sep 8, 2016 at 9:13 AM, project722 
 wrote:

> Bob, in our prod environment, we are allowing 127.0.0.1 to make zone
> transfers. First off, what is the reasoning or benefit of allowing
> localhost to make zone transfers? Secondly, In my new view config since I
> will be using 127.0.0.1 as a forwarder, would this in any way cause a
> problem or a conflict if I was to leave the localhost IP in the ACL for
> zone transfers?
>

 I would allow 127.0.0.1 to do zone transfers for troubleshooting
 purposes, if I am on the server and want to look at a whole zone.  But it
 is not required, if you don't use it for transfers.
 Allowing zone transfers should not affect its use for forwarding, as
 far as I can see.

 --
 Bob Harold



> On Wed, Sep 7, 2016 at 2:30 PM, Bob Harold  wrote:
>
>> You should change:
>>   match-clients { internal; key tsigkey; !key tsigkeyext;
>> To:
>>   match-clients { !key tsigkeyext; internal; key tsigkey;
>>
>> The 'not' (!) won't work if it is last, they are checked in order, so
>> it needs to be first.
>>
>> --
>> Bob Harold
>>
>>
>> On Wed, Sep 7, 2016 at 3:21 PM, project722 
>> wrote:
>>
>>> I think I have found the problem. I did not need dnssec enabled
>>> after all. All this time I thought it was needed for TSIG to work. But
>>> apparently, the forwarding is working, and zone transfers are going to 
>>> the
>>> right view without it enabled.
>>>
>>> On Wed, Sep 7, 2016 at 1:15 PM, project722 
>>> wrote:
>>>
 Ok I'm with you now. I have reconfigured my servers and I cant get
 the forwarding to work. Since 127.0.0.1 is forwarding request, I made 
 sure
 in the options stanza to set it to a listen IP. I have tried several
 different variations of this method and all end up with SERVFAIL's 
 using
 dig from a client that gets the "internal" view. Here is my config.

 acl internal {
 192.168.254.0/23; // corpnet
 };

Re: DNS views and zone transfers, cont

2016-09-13 Thread project722

I have moved the new views into production, and all seems to be working
fine. I have an "internal" view and an "external" view. I have noticed a
few re-occuring messages in the logs of the master server that I'd like to
suppress. Here is what I am seeing:

1) Warning: view external: 'empty-zones-enable/disable-empty-zone' not set:
disabling RFC 1918 empty zones: 37 Time(s)

2) connect(fe80::216:3eff:fe37:b866#53) 22/Invalid argument: 7 Time(s)

3) zone
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/IN/external:
(master) removed: 1 Time(s)
 zone 112/x.x.x.IN-ADDR.ARPA/IN: (master) removed: 1 Time(s)
 zone x.x.x.in-addr.arpa/IN: (master) removed: 1 Time(s)

For # 3 I basically see an entry for each of our reverse mapping zones,
which are valid and I don't want them "removed" as the message states And I
think these are related to #1. I believe I can fix #1 with the
"empty-zones-enable
no;" in my external view, but I am not sure what effect it would have on
the message generation or how it would affect zone behavior in that view.

For #2, - I already have a statement "server fe80::/16 { bogus yes; };" in
my named.conf. However it is above the options statement and I am now
wondering if I need this defined in each view now. Also this
fe80::216:3eff:fe37:b866
is not even my actual link local IP so I am not sure where/how that is
being generated. My actual link local is
fe80::f21f:afff:fedd:6a26/64

Any help is greatly appreciated.

On Thu, Sep 8, 2016 at 11:33 AM, project722  wrote:

> I am not seeing that but thanks for the heads up. I will keep an eye on
> it.
>
> On Thu, Sep 8, 2016 at 10:14 AM, Bob Harold  wrote:
>
>> I changed the subject slightly, because I had to cut out a lot of the
>> forwarded message - the list server was complaining about the size of the
>> messages.
>>
>> I just found that my setup was not working completely as I expected.  The
>> view with only a few zones and forwarding to another view automatically got
>> the "empty zones" created, so any queries in those zones did not get
>> forwarded.  I am fixing it by adding to that view the line:
>>empty-zones-enable no;
>>
>> --
>> Bob Harold
>>
>>
>> On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold  wrote:
>>
>>>
>>> On Thu, Sep 8, 2016 at 9:13 AM, project722  wrote:
>>>
 Bob, in our prod environment, we are allowing 127.0.0.1 to make zone
 transfers. First off, what is the reasoning or benefit of allowing
 localhost to make zone transfers? Secondly, In my new view config since I
 will be using 127.0.0.1 as a forwarder, would this in any way cause a
 problem or a conflict if I was to leave the localhost IP in the ACL for
 zone transfers?

>>>
>>> I would allow 127.0.0.1 to do zone transfers for troubleshooting
>>> purposes, if I am on the server and want to look at a whole zone.  But it
>>> is not required, if you don't use it for transfers.
>>> Allowing zone transfers should not affect its use for forwarding, as far
>>> as I can see.
>>>
>>> --
>>> Bob Harold
>>>
>>>
>>>
 On Wed, Sep 7, 2016 at 2:30 PM, Bob Harold  wrote:

> You should change:
>   match-clients { internal; key tsigkey; !key tsigkeyext;
> To:
>   match-clients { !key tsigkeyext; internal; key tsigkey;
>
> The 'not' (!) won't work if it is last, they are checked in order, so
> it needs to be first.
>
> --
> Bob Harold
>
>
> On Wed, Sep 7, 2016 at 3:21 PM, project722 
> wrote:
>
>> I think I have found the problem. I did not need dnssec enabled after
>> all. All this time I thought it was needed for TSIG to work. But
>> apparently, the forwarding is working, and zone transfers are going to 
>> the
>> right view without it enabled.
>>
>> On Wed, Sep 7, 2016 at 1:15 PM, project722 
>> wrote:
>>
>>> Ok I'm with you now. I have reconfigured my servers and I cant get
>>> the forwarding to work. Since 127.0.0.1 is forwarding request, I made 
>>> sure
>>> in the options stanza to set it to a listen IP. I have tried several
>>> different variations of this method and all end up with SERVFAIL's using
>>> dig from a client that gets the "internal" view. Here is my config.
>>>
>>> acl internal {
>>> 192.168.254.0/23; // corpnet
>>> };
>>>
>>> acl external {
>>> 192.168.155.0/24;
>>> 192.168.160.0/24;
>>> };
>>>
>>> options {
>>> listen-on port 53 { 192.168.155.128; 127.0.0.1; }; #Master
>>> DNS Servers IP
>>> directory   "/var/named";
>>> dump-file   "/var/named/data/cache_dump.db";
>>> statistics-file "/var/named/data/named.stats";
>>> memstatistics-file "/var/named/data/named_mem_stats.txt";
>>> allow-query{

Re: forwarders (IPv6)

Re: forwarders (IPv6)

RE: forwarders (IPv6)

forwarders (IPv6)

Re: DNS views and zone transfers, cont

Re: DNS views and zone transfers, cont

6 matches

Site Navigation

Mail list logo

Footer information