Re: Why does dig queries for NAPTR not return Additional Section info as Detailed returned in SRV dig response

2017-05-25 Thread Mark Andrews

RFC 3404

   At this time only four flags, "S", "A", "U", and "P", are defined.
   The "S", "A" and "U" flags are for a terminal lookup.  This means
   that the Rule is the last one and that the flag determines what the
   next stage should be.  The "S" flag means that the output of this
   Rule is a domain-name for which one or more SRV [9] records exist.
   See Section 5 for additional information on how URI and URN
   Resolution use the SRV record type.  "A" means that the output of the
   Rule is a domain-name and should be used to lookup either A, , or
   A6 records for that domain.  The "U" flag means that the output of
   the Rule is a URI [15].

Named examines the Flags field to determine what additional data to add.

"S" -> SRV records
"A" -> A and  records

Mark

In message 
,
 Harshith Mulky writes:
> Hello,
>
>
> This is my Zone File
>
>
> $TTL 1
>
> @ IN SOA hp3bl5PSXDNS.testnet.com.  root.testnet.com. (
> 2017051700 ; Serial number (mmdd-num)
> 8H ; Refresh
> 2M ; Retry
> 4W ; Expire
> 1D ) ; Minimum
>  IN NS hp3bl5PSXDNS
>
> hp3bl5PSXDNS  A 10.54.213.8
>
> testnet.com.  IN  NAPTR   22   32   "u""SIP+D2U"   ""
>  _sip._udp.testnet.com.
> atlanta.testnet.com.  IN  NAPTR   22   32   "u""SIP+D2U"
>  ""  _sip._udp.testnet.com.
> _sip._udp.testnet.com.IN  SRV   030  7700
> atlanta.testnet.com.
> _sip._udp.testnet.com.IN  SRV   020  7701
> atlanta.testnet.com.
> atlanta.testnet.com.  IN  fd00:10:6b50:4500::78
> _sip._udp   IN  SRV   040  51380
> arizona.testnet.com.
> arizona.testnet.com.  IN A10.54.80.14
> atlanta1.testnet.com.  IN    fd00:10:6b50:4500::22
> atlanta.testnet.com.  IN A   10.54.80.14

-- 
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: Weird issue with bind & router

2017-05-25 Thread Darcy Kevin (FCA)
As far as I know, the only "special" thing that BIND does consistently on a 
restart, that it doesn't do on a regular basis in normal operation, is a 
"priming" query to whatever is configured as root nameservers. I suppose it's 
_possible_ that there is something about priming queries, particularly, that 
exercises a codepath in the router, with a horrible bug in it. This is - as 
Mark speculated - much more likely if the router is trying to do something 
"smart" with your DNS, e.g. intrusion detection/prevention, reputation-based 
blacklisting, something like that. I'd look at the router config and see if you 
can turn any feature(s) like that *off*.

Failing that, if priming queries are the culprit, it should be fairly easy to 
reproduce the scenario, since one can issue identical-looking queries to the 
same root-nameserver destinations (the main difference between these and other 
command-line-generated queries would consist of making them non-recursive). If 
you can reproduce the issue at will, maybe the router manufacturer would 
actually listen to your trouble report.

Putting on my InfoSec paranoia hat for a second, if it's the *responses* to the 
priming queries that are causing the router to go belly-up, then this is a 
scary prospect indeed, since it raises the possibility that evildoers could 
send *spoofed* responses like that, to routers of that make/model, and this 
would be a powerful Denial of Service attack.




- Kevin



From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris 
Serella
Sent: Thursday, May 25, 2017 10:24 AM
To: bind-users@lists.isc.org
Subject: Weird issue with bind & router


I run a small dev system on my home network, housing dns etc all under the one 
server.

System: ubuntu16.04 server, ispconfig etc etc etc, you get the idea.

Anyway, the problem i am having comes down to the router rebooting (is it 
crashing? I cant tell) every time bind starts/restarts. This ordinarily wouldnt 
be an issue, DNS rarely changes so the service does not need restarting but the 
problem occurs on system boot too.

The router in question is a Plusnet Hub One which I believe is actually a 
repackaged BT Hub 5. The "server" is an ACER AX3300 desktop with ubuntu server 
installed.

Troubleshooting was difficult as i couldnt isolate what it was until i went 
over to ISPConfig for assistance, they informed me that a DNS reload on their 
software simply saves data to files and initiates a service restart.

With this information to hand I made no changes to the DNS in ISPConfig, 
instead i opened a terminal and tunnels into the server and issued a bind9 
restart from there.

Sure enough the problem reared its ugly little head, The ssh session dropped 
out and looking over to the router i could see it was going through its power 
cycle. To be sure this wasn't some freakishly well timed coincidence, I 
completed the steps several times more (3) all with the same result.
___
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 issue with bind & router

2017-05-25 Thread Mark Andrews

Even home routers sometimes try to police DNS traffic and I would
expect there is a bug in the code doing that.

As this is a ISP supplied router (if my Google Foo is accurate)
report the fault to the ISP.  It is their job to fix it.

If it wasn't a ISP supplied router, update the router firmware and
see if the problem goes away.  If that doesn't work.  Try to report
the bug to the router manufacture.  If you can't do that return the
router requesting a full refund as it is not fit for purpose.

Suppliers and manufactures need to get some pushback on broken products.

Mark

in message <8c799e52-3a3d-46b9-9f31-8df4e3b1d...@rrcic.com>, "john w. blue" 
writes:
> chris,
> 
> first, what a strange problem to have.
> 
> you really need to spend some time capturing the traffic placed on the wire=
>  via tcpdump and then slicing it up for clues with wireshark.
> 
> if you set a continuous ping to the router that would be a good timestamp t=
> hat you can use to correlate as a marker.  when it stops responding look at=
>  all of the other traffic around that time.
> 
> i doubt that it will be bind but stranger things have happened before!
> 
> good luck.
> 
> john
> 
> sent from nine
> 
> from: chris serella 
> sent: may 25, 2017 9:24 am
> to: bind-users@lists.isc.org
> subject: weird issue with bind & router
> 
> 
> i run a small dev system on my home network, housing dns etc all under the =
> one server.
> 
> system: ubuntu16.04 server, ispconfig etc etc etc, you get the idea.
> 
> anyway, the problem i am having comes down to the router rebooting (is it c=
> rashing? i cant tell) every time bind starts/restarts. this ordinarily woul=
> dnt be an issue, dns rarely changes so the service does not need restarting=
>  but the problem occurs on system boot too.
> 
> the router in question is a plusnet hub one which i believe is actually a r=
> epackaged bt hub 5. the "server" is an acer ax3300 desktop with ubuntu serv=
> er installed.
> 
> troubleshooting was difficult as i couldnt isolate what it was until i went=
>  over to ispconfig for assistance, they informed me that a dns reload on th=
> eir software simply saves data to files and initiates a service restart.
> 
> with this information to hand i made no changes to the dns in ispconfig, in=
> stead i opened a terminal and tunnels into the server and issued a bind9 re=
> start from there.
> 
> sure enough the problem reared its ugly little head, the ssh session droppe=
> d out and looking over to the router i could see it was going through its p=
> ower cycle. to be sure this wasn't some freakishly well timed coincidence, =
> i completed the steps several times more (3) all with the same result.

-- 
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: Weird issue with bind & router

2017-05-25 Thread John W. Blue
Chris,

First, what a strange problem to have.

You really need to spend some time capturing the traffic placed on the wire via 
tcpdump and then slicing it up for clues with wireshark.

If you set a continuous ping to the router that would be a good timestamp that 
you can use to correlate as a marker.  When it stops responding look at all of 
the other traffic around that time.

I doubt that it will be BIND but stranger things have happened before!

Good luck.

John

Sent from Nine

From: Chris Serella 
Sent: May 25, 2017 9:24 AM
To: bind-users@lists.isc.org
Subject: Weird issue with bind & router


I run a small dev system on my home network, housing dns etc all under the one 
server.

System: ubuntu16.04 server, ispconfig etc etc etc, you get the idea.

Anyway, the problem i am having comes down to the router rebooting (is it 
crashing? I cant tell) every time bind starts/restarts. This ordinarily wouldnt 
be an issue, DNS rarely changes so the service does not need restarting but the 
problem occurs on system boot too.

The router in question is a Plusnet Hub One which I believe is actually a 
repackaged BT Hub 5. The "server" is an ACER AX3300 desktop with ubuntu server 
installed.

Troubleshooting was difficult as i couldnt isolate what it was until i went 
over to ISPConfig for assistance, they informed me that a DNS reload on their 
software simply saves data to files and initiates a service restart.

With this information to hand I made no changes to the DNS in ISPConfig, 
instead i opened a terminal and tunnels into the server and issued a bind9 
restart from there.

Sure enough the problem reared its ugly little head, The ssh session dropped 
out and looking over to the router i could see it was going through its power 
cycle. To be sure this wasn't some freakishly well timed coincidence, I 
completed the steps several times more (3) all with the same result.
___
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

Why does dig queries for NAPTR not return Additional Section info as Detailed returned in SRV dig response

2017-05-25 Thread Harshith Mulky
Hello,


This is my Zone File


$TTL 1

@ IN SOA hp3bl5PSXDNS.testnet.com.  root.testnet.com. (
2017051700 ; Serial number (mmdd-num)
8H ; Refresh
2M ; Retry
4W ; Expire
1D ) ; Minimum
 IN NS hp3bl5PSXDNS

hp3bl5PSXDNS  A 10.54.213.8

testnet.com.  IN  NAPTR   22   32   "u""SIP+D2U"   ""  
_sip._udp.testnet.com.
atlanta.testnet.com.  IN  NAPTR   22   32   "u""SIP+D2U"   ""   
   _sip._udp.testnet.com.
_sip._udp.testnet.com.IN  SRV   030  7700 
atlanta.testnet.com.
_sip._udp.testnet.com.IN  SRV   020  7701 
atlanta.testnet.com.
atlanta.testnet.com.  IN  fd00:10:6b50:4500::78
_sip._udp   IN  SRV   040  51380 
arizona.testnet.com.
arizona.testnet.com.  IN A10.54.80.14
atlanta1.testnet.com.  IN    fd00:10:6b50:4500::22
atlanta.testnet.com.  IN A   10.54.80.14




When i do a dig for NAPTR and SRV records the answer is different

Question A: Why does not NAPTR Response additional section contain the 
responses for A RR too?  Why is it answering only NS A RR Answer?


hp3bl5PSXDNS:/var/lib/named # dig atlanta.testnet.com. NAPTR

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;atlanta.testnet.com.   IN   NAPTR

;; ANSWER SECTION:
atlanta.testnet.com.1IN   NAPTR  22 32 "u" 
"SIP+D2U" "" _sip._udp.testnet.com.

;; AUTHORITY SECTION:
testnet.com.  1IN   NS  
hp3bl5PSXDNS.testnet.com.

;; ADDITIONAL SECTION:
hp3bl5PSXDNS.testnet.com. 1 INA 10.54.213.8

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 24 17:00:08 IST 2017
;; MSG SIZE  rcvd: 143


hp3bl5PSXDNS:/var/lib/named # dig _sip._udp.testnet.com. SRV

; <<>> DiG 9.9.5-rpz2+rl.14038.05-P1 <<>> _sip._udp.testnet.com. SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26243
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_sip._udp.testnet.com.   IN   SRV

;; ANSWER SECTION:
_sip._udp.testnet.com.1IN   SRV0 40 51380 
arizona.testnet.com.
_sip._udp.testnet.com.1IN   SRV0 20 7701 
atlanta.testnet.com.
_sip._udp.testnet.com.1IN   SRV0 30 7700 
atlanta.testnet.com.

;; AUTHORITY SECTION:
testnet.com.  1IN   NS  
hp3bl5PSXDNS.testnet.com.

;; ADDITIONAL SECTION:
atlanta.testnet.com.1IN   A 
10.54.80.14
atlanta.testnet.com.1IN   
fd00:10:6b50:4500::78
arizona.testnet.com. 1IN   A 10.54.80.14
hp3bl5PSXDNS.testnet.com. 1 INA 10.54.213.8

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 24 17:00:35 IST 2017
;; MSG SIZE  rcvd: 273

___
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