Re: Query on the Order in which RR are answered by Bind of Order/preference are Same

[Mark Andrews]

In message <20160718141147.ga16...@fantomas.sk>, Matus UHLAR - fantomas writes:
> On 18.07.16 13:59, Harshith Mulky wrote:
> >I had a query on how the following Records can be ordered on how the Records 
> >are configured in the 
> Zone file
> >
> >I have done 2 different Tests
> >
> >I have configured following records in the Zone file e164enum.net with TTL 
> >value as 0
> >
> >2.7.5.2.7.9.2.5.3.1.8.e164enum.net. IN NAPTR 100 10 "u" "E2U+sip" 
> >"!^.*$!sip:7895673...@atlanta.com
> ;user=phone!" .
> >2.7.5.2.7.9.2.5.3.1.8.e164enum.net. IN NAPTR 100 10 "u" "E2U+sip" 
> >"!^.*$!sip:7895673...@atlanta.com
> ;user=phone!" .
> 
> 
> >Since I did not want the Answers to be toggled in each susbsequent digs, and 
> >I wanted the Answers t
> o be in the same Order they were configured in the Zone file(since the Order 
> and Preference of both 
> these records were same), I enabled this line in the options field of 
> named.conf
> >rrset-order {order fixed;};
> >and restarted named
> >
> >I ran the dig query again
> >
> >This time, the Answers did not toggle, but I found that, the second 
> >configured RR was being Answere
> d as first always sip:7895673...@atlanta.com
> >
> >Why is Bind answering the Second RR as first and not my original First RR as 
> >1st Answer?
> 
> the order provided applies only for your bind instance - any other
> nameserver can change the order.
> 
> why don't you use higher order if you want to have them in order?

Agreed.  NAPTR records contain instructions for how the client
processes multiple records.

   Order
  A 16-bit unsigned integer specifying the order in which the NAPTR
  records MUST be processed to ensure the correct ordering of
  rules.  Low numbers are processed before high numbers, and once a
  NAPTR is found whose rule "matches" the target, the client MUST
  NOT consider any NAPTRs with a higher value for order (except as
  noted below for the Flags field).

   Preference
  A 16-bit unsigned integer that specifies the order in which NAPTR
  records with equal "order" values SHOULD be processed, low
  numbers being processed before high numbers.  This is similar to
  the preference field in an MX record, and is used so domain
  administrators can direct clients towards more capable hosts or
  lighter weight protocols.  A client MAY look at records with
  higher preference values if it has a good reason to do so such as
  not understanding the preferred protocol or service.

  The important difference between Order and Preference is that
  once a match is found the client MUST NOT consider records with a
  different Order but they MAY process records with the same Order
  but different Preferences.  I.e., Preference is used to give weight
  to rules that are considered the same from an authority
  standpoint but not from a simple load balancing standpoint.

As for the output order from named you need to compile named with
fixed ordering support enabled (--enable-fixed-rrset). It takes
more memory per record and requires additional processing in lots
of places to preserve the entry order.  What you are seeing is named
returning the records in DNSSEC order which is how they are stored
by default.  Named needs to sort the records into DNSSEC order to
validate them.

> -- 
> 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
-- 
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: Questions on how to setup Reverse DNS in bind 9

[Spork Schivago]

Oscar,

On point 4 there,

At this time franklin.jetbbs.com ONLY RESOLVES TO 104.238.117.105

The way I wanted it was 104.238.117.105 AND 132.148.11.44to point to
jetbbs.com   but I think I setup the DNS record wrong.   I just added
another A record for jetbbs.com and added the IP address 132.148.11.44 to
it.   This part wasn't for the reverse DNS.   I got two IP addresses I'm
using.

I got an A name for franklin, and that's the 104.238.117.105.   Should I
have added another A name for franklin as well to setup the round robin
stuff?   You know, when someone connects to JetBBS.com, the first time they
connect, it takes them to 104.238.117.105.   The next time they connect, it
takes them to 132.148.11.44.   Is this why whenever I pinged jetbbs.com, I
only got a reply from 132.148.11.44 and not from 104.238.117.105 you think?
  Because I didn't setup another A name for franklin?   Thanks and sorry
for all the questions.   I know these probably aren't really bind related
questions anymore.   Thanks!

On Mon, Jul 18, 2016 at 12:29 PM, Oscar Ricardo Silva 
wrote:

> A few things:
>
>
> 1. As has already been mentioned, GoDaddy probably did not delegate
> 117.238.104.in-addr.arpa to you
>
>
>
> 2. If a network has been delegated, for example 117.238.104.in-addr.arpa.
> then in the zone file it should like like this:
>
> 104.117.238.104.in-addr.arpa.   in  ptr franklin.jetbbs.com.
>
>
> 3. You can have GoDaddy create the corresponding PTR records for you.
>
>
> 4. At this time franklin.jetbbs.com ONLY RESOLVES TO 104.238.117.105
>
>
>
>
> Oscar
>
>
>
> On 07/17/2016 09:22 PM, Spork Schivago wrote:
>
>> Hello,
>>
>> I'm new to operating a website and I'm leasing a virtual private server
>> (VPS) from GoDaddy.   I'm paying for cPanel / WHM as well.   It's
>> running CentOS 6.8 Final.  I'd like to setup reverse DNS but I'm having
>> trouble.   I'm not 100% sure how to do it.   I have my hostname,
>> franklin.jetbbs.com    and there's two IP
>> addresses assigned to that hostname, 104.238.117.105 and 132.148.11.44.
>>I was trying to setup a round robin kinda thing but I don't think I
>> set it up correctly.
>>
>> Anyway, I have ns1.jetbbs.com  which has the IP
>> of 104.238.117.105   and then I have ns2.jetbbs.com
>>  that has the IP address of 132.148.11.44.   I
>> wanted to know if someone could look over what I have so far and let me
>> know if it's correct and how I should proceed.
>>
>> So, in the /var/named directory, I create a file
>> called: 0.117.238.104.in-addr.arpa
>>
>> The contents of 0.117.238.104.in-addr.arpa are as follows:
>> $TTL 1D
>> @   IN SOA ns1.jetbbs.com . spork.jetbbs.com
>> . (
>>  2016071705  ; serial
>>  1D  ; refresh
>>  1H  ; retry
>>  1W  ; expire
>>  3H ); minimum
>>
>> 0.117.238.104.in-addr.arpa.IN  NS ns1.jetbbs.com
>> .
>> 0.11.148.132.in-addr.arpa. IN  NS ns2.jetbbs.com
>> .
>>
>> 104 IN  PTR franklin.jetbbs.com .
>> 44  IN  PTR franklin.jetbbs.com .
>>
>>
>> Does that look correct?   If not, how should I change it?   If so,
>> what's the next step?   Thank you for your help!
>>
>> Sincerely,
>> Ken
>>
>>
>> ___
>> 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: weird transfer-source problems with one DNS node

[Ian Veach]

Negative Ghostrider...:

[root@foo:~]# iptables -t raw -nvL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source
destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source
destination

[root@foo:~]# iptables -t mangle -nvL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source
destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source
destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source
destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source
destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source
destination


You might be on to something general though:  Maybe this is more of an OS
issue than a BIND issue?  BIND at least seems to think it's correct!




cheers and thanks,

Ian Veach, Senior Systems Analyst
System Computing Services, Nevada System of Higher Education


On Mon, Jul 18, 2016 at 4:11 PM, Browne, Stuart 
wrote:

> What about the mangle or raw tables?
>
> iptables -t raw -nvL
> iptables -t mangle -nvL
>
> Both tables have the ability to modify the packets as they pass through.
>
> Stuart
>
> 
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Ian Veach
> Sent: Tuesday, 19 July 2016 8:09 AM
> To: Barry Margolin; comp-protocols-dns-b...@isc.org
> Subject: Re: weird transfer-source problems with one DNS node
>
>
> I don't think my earlier response to this has made it past moderation, but
> an update:
>
> iptables looks pretty benign to me...:
>
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
> ACCEPT all  --  anywhere anywherestate
> RELATED,ESTABLISHED
> ACCEPT icmp --  anywhere anywhere
> ACCEPT all  --  anywhere anywhere
> ACCEPT all  --  anywhere anywhere
> ACCEPT tcp  --  anywhere anywherestate NEW tcp
> dpt:ssh
> ACCEPT tcp  --  anywhere anywherestate NEW tcp
> dpt:domain
> ACCEPT udp  --  anywhere anywherestate NEW udp
> dpt:domain
> (... other rules for allowed ports)
> ACCEPT ospf --  anywhere anywherestate NEW
> REJECT all  --  anywhere anywherereject-with
> icmp-host-prohibited
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
> ACCEPT all  --  anywhere anywherePHYSDEV match
> --physdev-is-bridged
> ACCEPT all  --  anywhere anywherestate
> RELATED,ESTABLISHED
> ACCEPT icmp --  anywhere anywhere
> ACCEPT all  --  anywhere anywhere
> ACCEPT all  --  anywhere anywhere
> ACCEPT all  --  anywhere anywhere
> REJECT all  --  anywhere anywherereject-with
> icmp-host-prohibited
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
>
>
>
>
>
> cheers and thanks,
>
> Ian Veach, Senior Systems Analyst
> System Computing Services, Nevada System of Higher Education
>
>
> On Mon, Jul 18, 2016 at 1:27 PM, ian_ve...@nshe.nevada.edu <
> ian_ve...@nshe.nevada.edu> wrote:
>
> I suppose, but doubt it.   I will look when I get back in office.  We do
> pretty benign ip tables though - a few firewall exceptions,  etc., and no
> Translations or any fancy stuff.  For anycast, we do use quagga and zebra
> for the ospf, but that's only for the service addresses on the loop back
> device
>
> Thanks!
>
> Sent via the Samsung Galaxy Note® 4, an AT 4G LTE smartphone
>
>
>  Original message 
> From: Barry Margolin 
> Date: 07/18/2016 12:12 (GMT-08:00)
> To: comp-protocols-dns-b...@isc.org
> Subject: Re: weird transfer-source problems with one DNS node
>
> In article ,
> Ian Veach  wrote:
>
> > So unless I'm crazy (possible, regardless)... named is reporting using
> 230,
> > but OS is showing 240 (and remote host logs confirm 240)!?
>
> Could something in iptables be transforming it at a lower level?
>
> --
> 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
>
>
> PUBLIC RECORDS NOTICE: In accordance with NRS Chapter 239, this email and
> responses, unless otherwise made confidential by law, may be 

Re: weird transfer-source problems with one DNS node

[Ian Veach]

I don't think my earlier response to this has made it past moderation, but
an update:

iptables looks pretty benign to me...:

Chain INPUT (policy ACCEPT)
target prot opt source   destination
ACCEPT all  --  anywhere anywherestate
RELATED,ESTABLISHED
ACCEPT icmp --  anywhere anywhere
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere
ACCEPT tcp  --  anywhere anywherestate NEW tcp
dpt:ssh
ACCEPT tcp  --  anywhere anywherestate NEW tcp
dpt:domain
ACCEPT udp  --  anywhere anywherestate NEW udp
dpt:domain
(... other rules for allowed ports)
ACCEPT ospf --  anywhere anywherestate NEW
REJECT all  --  anywhere anywherereject-with
icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source   destination
ACCEPT all  --  anywhere anywherePHYSDEV match
--physdev-is-bridged
ACCEPT all  --  anywhere anywherestate
RELATED,ESTABLISHED
ACCEPT icmp --  anywhere anywhere
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere
REJECT all  --  anywhere anywherereject-with
icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source   destination




cheers and thanks,

Ian Veach, Senior Systems Analyst
System Computing Services, Nevada System of Higher Education


On Mon, Jul 18, 2016 at 1:27 PM, ian_ve...@nshe.nevada.edu <
ian_ve...@nshe.nevada.edu> wrote:

>
> I suppose, but doubt it.   I will look when I get back in office.  We do
> pretty benign ip tables though - a few firewall exceptions,  etc., and no
> Translations or any fancy stuff.  For anycast, we do use quagga and zebra
> for the ospf, but that's only for the service addresses on the loop back
> device
>
> Thanks!
>
> Sent via the Samsung Galaxy Note® 4, an AT 4G LTE smartphone
>
>
>  Original message 
> From: Barry Margolin 
> Date: 07/18/2016 12:12 (GMT-08:00)
> To: comp-protocols-dns-b...@isc.org
> Subject: Re: weird transfer-source problems with one DNS node
>
> In article ,
> Ian Veach  wrote:
>
> > So unless I'm crazy (possible, regardless)... named is reporting using
> 230,
> > but OS is showing 240 (and remote host logs confirm 240)!?
>
> Could something in iptables be transforming it at a lower level?
>
> --
> 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
>

-- 
PUBLIC RECORDS NOTICE: In accordance with NRS Chapter 239, this email and 
responses, unless otherwise made confidential by law, may be subject to the 
Nevada Public Records laws and may be disclosed to the public upon request.
___
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: weird transfer-source problems with one DNS node

[Barry Margolin]

In article ,
 Ian Veach  wrote:

> So unless I'm crazy (possible, regardless)... named is reporting using 230,
> but OS is showing 240 (and remote host logs confirm 240)!?

Could something in iptables be transforming it at a lower level?

-- 
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: weird transfer-source problems with one DNS node

[Ian Veach]

Der, sorry.  Machines are all RHEL 6.8, running the BIND provided by RH:
9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6

Restarting BIND (or even the OS) doesn't seem to change anything.  I don't
seem to have scan as an option for rndc. I assume it's in a newer version
that RH doesn't yet provide for RHEL 6.

Logs are confusing.  I tailed the general log and xfer log, while running
tcpdump.

The xfer log and general log indicate that the CORRECT address is being
used:

18-Jul-2016 10:13:18.120 general: zone
153.10.10.IN-ADDR.ARPA/IN/internal-in: Transfer started.
18-Jul-2016 10:13:18.121 transfer of
'153.10.10.IN-ADDR.ARPA/IN/internal-in' from 10.10.153.225#53: connected
using 10.10.205.230#46673

However, I also ran tcpdump during that time (tcpdump -n host
10.10.153.225):

10:13:18.121138 IP 10.10.205.240.46673 > 10.10.153.225.domain: Flags [S],
seq 1847532073, win 14600, options [mss 1460,sackOK,TS val 255805503 ecr
0,nop   ,wscale 7], length 0
10:13:18.121911 IP 10.10.153.225.domain > 10.10.205.240.46673: Flags [S.],
seq 1696697219, ack 1847532074, win 8192, options [mss 1380,nop,wscale
8,sack   OK,TS val 329780493 ecr 255805503,nop,Unknown Option
1403], length 0
10:13:18.121937 IP 10.10.205.240.46673 > 10.10.153.225.domain: Flags [.],
ack 1, win 115, options [nop,nop,TS val 255805503 ecr 329780493], length 0

[me@foo:/var/named/log]# host foo
foo.scsr.nevada.edu has address 10.10.205.240
[me@foo:/var/named/log]# host foo-xfer
foo-xfer.scsr.nevada.edu has address 10.10.205.230

So unless I'm crazy (possible, regardless)... named is reporting using 230,
but OS is showing 240 (and remote host logs confirm 240)!?

Thanks!!



cheers and thanks,

Ian Veach, Senior Systems Analyst
System Computing Services, Nevada System of Higher Education


On Mon, Jul 18, 2016 at 9:28 AM, Tony Finch  wrote:

> Ian Veach  wrote:
> >
> > So, any ideas on why I would see that slave initiate transfers on it's OS
> > IP versus the transfer-source IP... especially when the other three work
> > fine?
>
> What does the log say about interface addresses? Which version of BIND are
> you running? Has the xfer interface been reconfigured on the problematic
> host? Does `rndc scan` or restarting named help?
>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h
> punycode
> Biscay: East 3 or 4, becoming cyclonic 4 or 5. Slight or moderate. Showers
> later. Good, occasionally moderate.
>

-- 
PUBLIC RECORDS NOTICE: In accordance with NRS Chapter 239, this email and 
responses, unless otherwise made confidential by law, may be subject to the 
Nevada Public Records laws and may be disclosed to the public upon request.
___
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: weird transfer-source problems with one DNS node

[Tony Finch]

Ian Veach  wrote:
>
> So, any ideas on why I would see that slave initiate transfers on it's OS
> IP versus the transfer-source IP... especially when the other three work
> fine?

What does the log say about interface addresses? Which version of BIND are
you running? Has the xfer interface been reconfigured on the problematic
host? Does `rndc scan` or restarting named help?

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Biscay: East 3 or 4, becoming cyclonic 4 or 5. Slight or moderate. Showers
later. Good, occasionally moderate.
___
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

weird transfer-source problems with one DNS node

[Ian Veach]

I'm having a weird problem where one of our DNS servers is not
communicating on the expected transfer-source IPs (but the rest are).
They're generally configured exact/similar, but there's obviously something
causing a difference on the one node.

We run four slave DNS as public NS (with private masters for mgmt.).  Two
nodes per physical site (two sites).  All run OSPF to provide anycast
addresses as service addresses.  All have an IP for the server/OS itself
(each), and all have an IP dedicated for xfers only.

So, for example (taking one location, obfuscating servers "foo" and "bar")
 10.10.205.240/25 foo (OS IP, eth0)
 10.10.205.230/25 foo-xfer (xfer, eth0:1)
 10.10.205.1/32   service-ns1 (anycast IP, lo:1)
 10.11.205.1/32   service-ns2 (anycast IP, lo:2)

 10.10.205.239/25 bar
 10.10.205.229/25 bar-xfer
 10.10.205.1/32   service-ns1
 10.11.205.1/32   service-ns2

So, on bar, everything works fine.  And when I do a tcpdump on bar-xfer, I
see the xfers occurring (connections to/from master).  However, on foo, I
see no traffic on the xfer IP.  When I tcpdump the main OS IP (or the NS
master address), I see that communication occurring on the OS IP, and not
the transfer-source IP.  And yet, here's the config line in named.conf:

 transfer-source 10.10.205.230;

So, any ideas on why I would see that slave initiate transfers on it's OS
IP versus the transfer-source IP... especially when the other three work
fine?

Same OS, same OS level, same (theoretical) config except for the IP
differences between machines...

Thanks for any pointers!


cheers and thanks,

Ian Veach, Senior Systems Analyst
System Computing Services, Nevada System of Higher Education

-- 
PUBLIC RECORDS NOTICE: In accordance with NRS Chapter 239, this email and 
responses, unless otherwise made confidential by law, may be subject to the 
Nevada Public Records laws and may be disclosed to the public upon request.
___
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: Questions on how to setup Reverse DNS in bind 9

[Jeremy C. Reed]

On Sun, 17 Jul 2016, Spork Schivago wrote:

> So, in the /var/named directory, I create a file
> called: 0.117.238.104.in-addr.arpa
> 
> The contents of 0.117.238.104.in-addr.arpa are as follows:
> $TTL 1D
> @       IN SOA  ns1.jetbbs.com. spork.jetbbs.com. (
>                                         2016071705      ; serial
>                                         1D              ; refresh
>                                         1H              ; retry
>                                         1W              ; expire
>                                         3H )            ; minimum
> 
> 0.117.238.104.in-addr.arpa.        IN      NS      ns1.jetbbs.com.
> 0.11.148.132.in-addr.arpa.         IN      NS      ns2.jetbbs.com.
> 
> 104     IN      PTR     franklin.jetbbs.com.
> 44      IN      PTR     franklin.jetbbs.com.


This won't work as you need NS records that match up to the zone name, 
In this case, the common zone name is only "in-addr.arpa." but no NS for 
that.  Also if it was only "in-addr.arpa." the two PTR records would be 
useless.  If your zone name does match so you have a NS record, as it is 
now, you'd have "out-of-zone data" which is ignored. Try using two 
different more specific zone files such as for 11.148.132.IN-ADDR.ARPA. 
and 117.238.104.IN-ADDR.ARPA.
___
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: doubt about queries.log format

[Manuel Ramírez]

Thanks Tony for your answer,
and is there any possibility using other category and/or debug level to
obtain the record and the ip resolved in the same log entry?

Regards

Manuel

2016-07-18 12:50 GMT+02:00 Tony Finch :

> Manuel Ramírez  wrote:
> >
> > I would like to know if is possible to see in the queries.log output the
> ip
> > address resolved
>
> No, it only logs the query not the answers.
>
> Have a look at passive DNS or dnstap if you want more detailed telemetry.
>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h
> punycode
> Irish Sea, Shannon: South 4 or 5, becoming variable 3 or 4. Smooth or
> slight
> in Irish Sea, moderate in Shannon. Fog patches. Moderate or good,
> occasionally
> very poor.
___
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: Query on the Order in which RR are answered by Bind of Order/preference are Same

[Matus UHLAR - fantomas]

On 18.07.16 13:59, Harshith Mulky wrote:

I had a query on how the following Records can be ordered on how the Records 
are configured in the Zone file

I have done 2 different Tests

I have configured following records in the Zone file e164enum.net with TTL 
value as 0

2.7.5.2.7.9.2.5.3.1.8.e164enum.net. IN NAPTR 100 10 "u" "E2U+sip" 
"!^.*$!sip:7895673...@atlanta.com;user=phone!" .
2.7.5.2.7.9.2.5.3.1.8.e164enum.net. IN NAPTR 100 10 "u" "E2U+sip" 
"!^.*$!sip:7895673...@atlanta.com;user=phone!" .




Since I did not want the Answers to be toggled in each susbsequent digs, and I 
wanted the Answers to be in the same Order they were configured in the Zone 
file(since the Order and Preference of both these records were same), I enabled 
this line in the options field of named.conf
rrset-order {order fixed;};
and restarted named

I ran the dig query again

This time, the Answers did not toggle, but I found that, the second configured 
RR was being Answered as first always sip:7895673...@atlanta.com

Why is Bind answering the Second RR as first and not my original First RR as 
1st Answer?


the order provided applies only for your bind instance - any other
nameserver can change the order.

why don't you use higher order if you want to have them in order?

--
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

Query on the Order in which RR are answered by Bind of Order/preference are Same

[Harshith Mulky]

Hello Experts,

I had a query on how the following Records can be ordered on how the Records 
are configured in the Zone file

I have done 2 different Tests

I have configured following records in the Zone file e164enum.net with TTL 
value as 0

2.7.5.2.7.9.2.5.3.1.8.e164enum.net. IN NAPTR 100 10 "u" "E2U+sip" 
"!^.*$!sip:7895673...@atlanta.com;user=phone!" .
2.7.5.2.7.9.2.5.3.1.8.e164enum.net. IN NAPTR 100 10 "u" "E2U+sip" 
"!^.*$!sip:7895673...@atlanta.com;user=phone!" .


Now whenever I run a "dig" query on the bind server for "dig 
2.7.5.2.7.9.2.5.3.1.8.e164enum.net. NAPTR"

I receive responses like, toggled in Answer section

QUERY#1
---
;; <<>> DiG 9.9.5-rpz2+rl.14038.05-P1 <<>> 2.7.5.2.7.9.2.5.3.1.8.e164enum.net. 
NAPTR
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37270
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;2.7.5.2.7.9.2.5.3.1.8.e164enum.net. IN NAPTR

;; ANSWER SECTION:
2.7.5.2.7.9.2.5.3.1.8.e164enum.net. 0 IN NAPTR  100 10 "u" "E2U+sip" 
"!^.*$!sip:7895673...@atlanta.com\;user=phone!" .
2.7.5.2.7.9.2.5.3.1.8.e164enum.net. 0 IN NAPTR  100 10 "u" "E2U+sip" 
"!^.*$!sip:7895673...@atlanta.com\;user=phone!" .

;; AUTHORITY SECTION:
e164enum.net.   0   IN  NS  HP3bl10VM5DNS.e164enum.net.

;; ADDITIONAL SECTION:
HP3bl10VM5DNS.e164enum.net. 0   IN  A   10.54.212.235

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 19 00:31:16 IST 2016
;; MSG SIZE  rcvd: 261


QUERY#2
---
; <<>> DiG 9.9.5-rpz2+rl.14038.05-P1 <<>> 2.7.5.2.7.9.2.5.3.1.8.e164enum.net. 
NAPTR
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40073
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;2.7.5.2.7.9.2.5.3.1.8.e164enum.net. IN NAPTR

;; ANSWER SECTION:
2.7.5.2.7.9.2.5.3.1.8.e164enum.net. 0 IN NAPTR  100 10 "u" "E2U+sip" 
"!^.*$!sip:7895673...@atlanta.com\;user=phone!" .
2.7.5.2.7.9.2.5.3.1.8.e164enum.net. 0 IN NAPTR  100 10 "u" "E2U+sip" 
"!^.*$!sip:7895673...@atlanta.com\;user=phone!" .

;; AUTHORITY SECTION:
e164enum.net.   0   IN  NS  HP3bl10VM5DNS.e164enum.net.

;; ADDITIONAL SECTION:
HP3bl10VM5DNS.e164enum.net. 0   IN  A   10.54.212.235

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 19 00:31:19 IST 2016
;; MSG SIZE  rcvd: 261


Since I did not want the Answers to be toggled in each susbsequent digs, and I 
wanted the Answers to be in the same Order they were configured in the Zone 
file(since the Order and Preference of both these records were same), I enabled 
this line in the options field of named.conf
rrset-order {order fixed;};
and restarted named

I ran the dig query again

This time, the Answers did not toggle, but I found that, the second configured 
RR was being Answered as first always sip:7895673...@atlanta.com

Why is Bind answering the Second RR as first and not my original First RR as 
1st Answer?


QUERY#1
---
; <<>> DiG 9.9.5-rpz2+rl.14038.05-P1 <<>> 2.7.5.2.7.9.2.5.3.1.8.e164enum.net. 
NAPTR
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18221
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;2.7.5.2.7.9.2.5.3.1.8.e164enum.net. IN NAPTR

;; ANSWER SECTION:
2.7.5.2.7.9.2.5.3.1.8.e164enum.net. 0 IN NAPTR  100 10 "u" "E2U+sip" 
"!^.*$!sip:7895673...@atlanta.com\;user=phone!" .
2.7.5.2.7.9.2.5.3.1.8.e164enum.net. 0 IN NAPTR  100 10 "u" "E2U+sip" 
"!^.*$!sip:7895673...@atlanta.com\;user=phone!" .

;; AUTHORITY SECTION:
e164enum.net.   0   IN  NS  HP3bl10VM5DNS.e164enum.net.

;; ADDITIONAL SECTION:
HP3bl10VM5DNS.e164enum.net. 0   IN  A   10.54.212.235

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 19 00:36:30 IST 2016
;; MSG SIZE  rcvd: 261

QUERY#2
---
; <<>> DiG 9.9.5-rpz2+rl.14038.05-P1 <<>> 2.7.5.2.7.9.2.5.3.1.8.e164enum.net. 
NAPTR
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17082
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;2.7.5.2.7.9.2.5.3.1.8.e164enum.net. IN NAPTR

;; ANSWER SECTION:
2.7.5.2.7.9.2.5.3.1.8.e164enum.net. 0 IN NAPTR  100 10 "u" "E2U+sip" 
"!^.*$!sip:7895673...@atlanta.com\;user=phone!" .
2.7.5.2.7.9.2.5.3.1.8.e164enum.net. 0 IN NAPTR  100 10 "u" "E2U+sip" 
"!^.*$!sip:7895673...@atlanta.com\;user=phone!" .

;; AUTHORITY SECTION:
e164enum.net.   0   IN  NS  HP3bl10VM5DNS.e164enum.net.

;; ADDITIONAL SECTION:
HP3bl10VM5DNS.e164enum.net. 0   IN  A   10.54.212.235

;; Query time: 0 msec
;; 

RE: Questions on how to setup Reverse DNS in bind 9

[Lightner, Jeffrey]

I haven't done it with GoDaddy but many providers WILL delegate reverse IPs to 
you if you request it.

Personal editorial comment:
Were it me I wouldn't use GoDaddy for anything.   I detest GoDaddy because 
their whole business model seems aimed at forcing you to leap through hoops to 
do anything useful.   They've recently started refusing external whois queries 
again so you must go to their website.   Often when we acquire companies and 
have to take on their domains if they're at GoDaddy they throw roadblocks in 
our way for transferring the domain to our preferred Registrar.   A new trick 
they started is denying transfers for 60 days if Registrant is updated.  They 
say they do all this to protect their customers but it seems obvious to me it 
is more to protect their bottom line.


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of John W. 
Blue
Sent: Sunday, July 17, 2016 10:47 PM
To: bind-users@lists.isc.org
Subject: Re: Questions on how to setup Reverse DNS in bind 9

Ken,

You typically will not be delegated reverse DNS.  Honestly, I would contact 
godaddy support directly and see if they can adjust it for you.  As in, not on 
your server directly but either tell you how to do it in a control panel on 
your side of the fence or they just do it from their side.

Best regards,

John

Sent from Nine

From: Spork Schivago >
Sent: Jul 17, 2016 9:24 PM
To: bind-users@lists.isc.org
Subject: Questions on how to setup Reverse DNS in bind 9

Hello,

I'm new to operating a website and I'm leasing a virtual private server (VPS) 
from GoDaddy.   I'm paying for cPanel / WHM as well.   It's running CentOS 6.8 
Final.  I'd like to setup reverse DNS but I'm having trouble.   I'm not 100% 
sure how to do it.   I have my hostname, 
franklin.jetbbs.com   and there's two IP addresses 
assigned to that hostname, 104.238.117.105 and 132.148.11.44.   I was trying to 
setup a round robin kinda thing but I don't think I set it up correctly.

Anyway, I have ns1.jetbbs.com which has the IP of 
104.238.117.105   and then I have ns2.jetbbs.com that 
has the IP address of 132.148.11.44.   I wanted to know if someone could look 
over what I have so far and let me know if it's correct and how I should 
proceed.

So, in the /var/named directory, I create a file called: 
0.117.238.104.in-addr.arpa

The contents of 0.117.238.104.in-addr.arpa are as follows:
$TTL 1D
@   IN SOA  ns1.jetbbs.com. 
spork.jetbbs.com. (
2016071705  ; serial
1D  ; refresh
1H  ; retry
1W  ; expire
3H ); minimum

0.117.238.104.in-addr.arpa.IN  NS  
ns1.jetbbs.com.
0.11.148.132.in-addr.arpa. IN  NS  
ns2.jetbbs.com.

104 IN  PTR franklin.jetbbs.com.
44  IN  PTR franklin.jetbbs.com.


Does that look correct?   If not, how should I change it?   If so, what's the 
next step?   Thank you for your help!

Sincerely,
Ken
___
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: SOA record not signed with new key at key-rollover

[Nis Wechselberg]

Am 18.07.2016 um 12:48 schrieb Tony Finch:
> If your rollover time is much shorter then you are testing something that
> is more like an emergency unplanned rollover.

At the moment I am merely testing in this "high-frequency" setup to get
a good feeling for the mechanics and the interaction between the tools.

I understand that this is not the correct approach for a stable zone.
___
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: doubt about queries.log format

[Tony Finch]

Manuel Ramírez  wrote:
>
> I would like to know if is possible to see in the queries.log output the ip
> address resolved

No, it only logs the query not the answers.

Have a look at passive DNS or dnstap if you want more detailed telemetry.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Irish Sea, Shannon: South 4 or 5, becoming variable 3 or 4. Smooth or slight
in Irish Sea, moderate in Shannon. Fog patches. Moderate or good, occasionally
very poor.___
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: SOA record not signed with new key at key-rollover

[Tony Finch]

Nis Wechselberg  wrote:

> Am I getting it right that the rest of the zone is not (re)signed
> because the current signature is still valid for some time?
>
> So if I were to set sig-validity-interval to a shorter value, this would
> help with the issue?

If you are testing out a fast rollover schedule then it would make sense
to set a short sig-validity-interval, scaled to match.

If your rollover time is much shorter then you are testing something that
is more like an emergency unplanned rollover.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: Southerly, becoming variable, 3 or 4, occasionally 5 at first in
west. Smooth or slight. Fog banks. Moderate or good, occasionally very poor.
___
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

doubt about queries.log format

[Manuel Ramírez]

Hi,

first of all sorry for my poor English.

I would like to know if is possible to see in the queries.log output the ip
address resolved, for example, this is one line from the queries.log:



*18-Jul-2016 10:54:15.226 queries: info: client 10.1.116.27#10760
(update.microsoft.com ): view
localhost_resolver: query: update.microsoft.com
 IN A + (10.1.0.244)*
I would like to see  the ip resolved for   *update.microsoft.com
 ,* is this possible?

Thanks in advance

Regards

Manuel
___
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