BIND 9.10 also-notify syntax

[greg.rabil]

Hello BIND users,
According to the BIND 9.10.3 ARM, the syntax for 'also-notify' in the options 
section of the named.conf file is:

[ also-notify { ip_addr
[port ip_port] [dscp ip_dscp] [key keyname] ;
[ ip_addr [port ip_port] [dscp ip_dscp] [key keyname] ; ... ] };

However, specifying the optional 'dscp' keyword and integer value causes named 
to abort at startup.  My understanding is that the DSCP value is for *source* 
ports, whereas the syntax above indicates that the DSCP value goes with the 
*target* port of the notify.  Interestingly, the grammar for this option from 
the BIND 9.10.3 source is as follows:

also-notify [ port  ] [ dscp  ] { (  | 
 [ port  ] |  [ port  ] ) [ key 
 ]; ... };

Which corresponds to my understanding where the optional 'dscp' keyword and 
value would be associated with the source.

Can someone please confirm if the BIND 9.10 ARM documentation is wrong?

Thanks,
Greg Rabil
This email contains BT information which may be privileged or confidential. It 
is meant only for the individual(s) or entity named above. If you are not the 
intended recipient, note that disclosing, copying, distributing or using this 
information is prohibited. If you have received this email in error, please let 
me know immediately on the email above. Thank you. We monitor our email system 
and may record your emails.
BT Americas Inc. 415 Eagleview Blvd., Suite 112, Exton, PA 19341
BT Americas Inc. is a wholly owned subsidiary of British Telecommunications plc.

___
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: BIND 9.10 also-notify syntax

[Evan Hunt]

On Wed, Sep 23, 2015 at 03:37:23PM +0100, greg.ra...@bt.com wrote:
> Can someone please confirm if the BIND 9.10 ARM documentation is wrong?

Yes, the grammar was copied incorrectly into the ARM. Thanks for 
pointing it out.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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

Caching and upper case issue with BIND 9.9.7-P3

[cypher Nix]

After upgrading BIND from BIND 9.9.7-P2 to BIND 9.9.7-P3 on about a dozen
authoritative + recursive servers, we noticed a strange caching issue on one of 
the servers.

The server is authoritative for our main domain (let's assume example.com).
There are multiple subdomains under example.com that have been NS delegated to
other servers. Whenever the DNS server would respond to a recursive "A" record 
query from its
cache, the "Answers" part of the request would always be in upper case - such
as foo.bar.EXAMPLE.COM.
More details below
I noted the following behavior using a packet capture

-A client requests for "foo.bar.example.com" "A" record.

-Our server then does a lookup against bar.example.com authoritative server for 
"A" record "foo.bar.exampe.com" 

-Our server gets a response from bar.example.com authoritative server:
; ANSWER SECTION:
foo.bar.example.com. 10 INA   192.168.0.1

-Our server responds to the clients request for foo.bar.example.com and stores
the response for 10 seconds (the TTL of the record). At this point the
answer section is still in all lower case - the clients gets the following:
; ANSWER SECTION:
foo.bar.example.com. 10 INA   192.168.0.1

-The next time the client queries for foo.bar.exmaple.com, our server responds
from the cache and changes the case from example.com to EXAMPLE.COM. It
continues to serve EXAMPLE.COM in upper case as part of the answer while the 
TTL is still valid.
; ANSWER SECTION:
foo.bar.EXAMPLE.COM. 9 INA   192.168.0.1

-This behavior was observed for "A" record responses for queries under any
subdomain of example.com.  The case was only change to upper case on the
answer section. Example.com also appeared under the question, authority, and
additional sections but only in the answer section was the case changed.

We eventually restarted BIND and the issue went
away. After restarting BIND all responses served from cache are now lower case, 
as expected.

Has anyone seen this behavior before ? Is this a bug ?
This caused issues for certain applications on our network that did string
comparison and expected the answer section to be in lower case.
___
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: Caching and upper case issue with BIND 9.9.7-P3

[Tony Finch]

cypher Nix  wrote:
>
> Has anyone seen this behavior before ? Is this a bug ?

See the CHANGES file:

4079.   [func]  Preserve the case of the owner name of records to
the RRset level. [RT #37442]

> This caused issues for certain applications on our network that did string
> comparison and expected the answer section to be in lower case.

That's a bug in those applications.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.
___
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: Caching and upper case issue with BIND 9.9.7-P3

[Evan Hunt]

On Wed, Sep 23, 2015 at 08:18:45AM -0700, cypher Nix wrote:
> After upgrading BIND from BIND 9.9.7-P2 to BIND 9.9.7-P3 on about a dozen

... that's odd, the new case compression behavior was introduced a fair
bit earlier than that; are you sure you weren't upgrading a few servers
older than 9.9.7-P2?

> Has anyone seen this behavior before ? Is this a bug ?
> [...]
> This caused issues for certain applications on our network that did string
> comparison and expected the answer section to be in lower case.

Those applications should be changed to use strcasecmp() not strcmp().
However, if that's not practical, you can configure named to work the way
it used to for selected clients, or for all clients.

The case of the question is preserved in responses, but the case of the
answer can change. BIND (and most other DNS implementations) used to
compress names in responses in a way that forced the the answer to
conform to the case of the question.  But the specification actually
says to preserve the original owner's case whenever possible, so we
changed it.

If you need the old behavior back for a particular client, add
"no-case-compress {  ; };" to your options. If you
want it back for all clients, then use "no-case-compress { any; };".

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: Caching and upper case issue with BIND 9.9.7-P3

[cypher Nix]

On Wednesday, September 23, 2015 at 12:01:15 PM UTC-4, Tony Finch wrote:
> 
> That's a bug in those applications.


I agree that this a bug on their application code. We've asked the application 
owners to fix their code.
___
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: Caching and upper case issue with BIND 9.9.7-P3

[cypher Nix]

On Wednesday, September 23, 2015 at 12:18:37 PM UTC-4, Evan Hunt wrote:
> ... that's odd, the new case compression behavior was introduced a fair
> bit earlier than that; are you sure you weren't upgrading a few servers
> older than 9.9.7-P2?
> 
We've ran 9.9.4, 9.9.6, 9.9.7, and 9.9.7-P2. We never had an issue until 
upgrading to 9.9.7-p3. Only one of the dozen severs we updated to experience 
this case issue. The issue cleared up once BIND was stopped and then restarted. 

> Those applications should be changed to use strcasecmp() not strcmp().
Application owners have been asked to update their code. However, restarting 
BIND seem to have corrected the issue we were seeing.

> However, if that's not practical, you can configure named to work the way
> it used to for selected clients, or for all clients.
> 
> The case of the question is preserved in responses, but the case of the
> answer can change. BIND (and most other DNS implementations) used to
> compress names in responses in a way that forced the the answer to
> conform to the case of the question.  But the specification actually
> says to preserve the original owner's case whenever possible, so we
> changed it.
Thanks for clarifying. It seems like our server in question was actually 
changing the case to upper case for just one domain. This behavior stopped once 
we bounced the server. However, I feel that the application should account for 
different case in DNS names.



___
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: How to Fix Reverse DNS?

[Marc Haber]

On Tue, Sep 22, 2015 at 04:54:45PM -0500, Ron Wingfield wrote:
>  I have recently converted from a "legacy" DSL service to AT's
>  U-verse . . .has been a painful experience. Heretofore, the following
>  from /var/named/named.conf
> 
>  zone "233.202.162.in-addr.arpa" {
>  type master;
>  file "./zonefiles/db.233.202.162.rev";
>  };
> 
> 
>  . . .and the contents of the zone configuration file as follows:
> 
>  $TTL 3h
> 
>  @ IN  SOA  archaxis.net.   root.archaxis.net. (
>  2015080601; Serial
>  3h  ; Refresh
>  1h  ; Retry
>  1w  ; Expire
>  1h ); Negative cashing TTL
> 
>  IN NS   ns1.archaxis.net.
>  IN NS   ns2.archaxis.net.
> 
>  1   IN PTR archaxis.net.
>  1   IN PTR ns1.archaxis.net.
>  1   IN PTR ns2.archaxis.net.

Your provider has used a RFC2317 scheme to delegate the reverse DNS to
you:

81.233.202.162.in-addr.arpa. 7200 INCNAME 81.80/29.233.202.162.in-addr.arpa.
80/29.233.202.162.in-addr.arpa. 7200 IN NS  ns2.archaxis.net.
80/29.233.202.162.in-addr.arpa. 7200 IN NS  ns1.archaxis.net.

so you need

zone "80/29.233.202.162.in-addr.arpa." {
 ...
}

Btw, this diagnosis would not have been possible if you had obfuscated
the IP address. Thanks for being open, showing your real data,
allowing swift and easy help.

Greetings
Marc


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
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: Options for non-recursive servers

[Matus UHLAR - fantomas]

On 22.09.15 12:24, Bob McDonald wrote:

for non-recursive (authoritative only) servers I have:

[deleted]

Note: There is actually only one interface with an inside address.. It's
NATed to the outside address (query-source). Several options are defaults
and specified for clarity.



Does anything jump out as being incorrect?


I don't see reason to redefine all defaults. when defaults change for a sane
reason, you may miss that reason then. 


And if you wanted to change anything, defining views could cause troubles.


Are there implications to setting minimal-responses to yes?


you can in some cases receive multiple requests that could be avoided
without this.

--
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.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
___
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: Caching and upper case issue with BIND 9.9.7-P3

[Mark Andrews]

In message , Tony Fi
nch writes:
> cypher Nix  wrote:
> >
> > Has anyone seen this behavior before ? Is this a bug ?
> 
> See the CHANGES file:
> 
> 4079.   [func]  Preserve the case of the owner name of records to
> the RRset level. [RT #37442]

BIND 9.9 only has 

3645.   [protocol]  Use case sensitive compression when responding to
queries. [RT #34737]

which returns the case of the node when it was added to the tree.
4079 adds additional data at the node that records the case of the
entire name allowing it to be returned.

For foo.bar.EXAMPLE.COM there was likely a query for "XXX.EXAMPLE.COM"
which created the nodes "EXAMPLE" and "COM".  Later on there was a
query for "foo.bar.example.com" which created the nodes "foo" and
"bar".  Combining these you get "foo.bar.EXAMPLE.COM" being returned.

Even with 4079 you will see inconsistencies over time until the
authoritative servers are all upgraded to fully preserve the case
of owner names.  Until that is done you will see the case of the
initial query being reflected in later responses, however you will
see less mixed case responses as most queries are either all uppercase
or all lowercase.

Mark

> > This caused issues for certain applications on our network that did string
> > comparison and expected the answer section to be in lower case.
> 
> That's a bug in those applications.
> 
> Tony.
> -- 
> f.anthony.n.finch    http://dotat.at/
> Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
> moderate, but rough in southwest Viking. Showers later. Good, occasionally
> poor later.
> ___
> 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