RFC for SOA record for delegated subdomaain
Dear All, Is there any RFC which specifies that every delegated subdomain shall have SOA record ? Thanks and regards Abdul Khader -- ___ 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: RFC for SOA record for delegated subdomaain
In message <67724e80-a40d-25e4-aea4-c53fca8cf...@ies.etisalat.ae>, Abdul Khader writes: > Dear All, > > Is there any RFC which specifies that every delegated subdomain shall > have SOA record ? Every zone has a SOA record. This is specified in RFC 1034. > Thanks and regards > > Abdul Khader > > > -- > > ___ > 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
Configuration advice for a post-8020 world
All,
I am asking for advice/ comments/ best-practices for bind
configuration and zone RRs to avoid potential issues with
Empty Non-Terminal (ENT) domain names.
Before continuing, I feel I must point out I am a big fan
of improvements in network and protocol efficiency
including RFC-8020. I also feel the authors did an excellent
job of identifying potential critical regions and agree with
their cost-benefit analysis.
Having said that, I downloaded the latest bind (9.11.0-P3),
set up a couple sample zones and ran the test outlined below.
SAMPLE ZONES:
101{redacted}.com. (REAL ZONE FILE)
jwjw.sales.101{redacted}.com. (REAL ZONE FILE)
**
NOTE: This is not intended to be commentary on "blah blah bind's
**defective clairvoyance module blah blah blah" but rather
**how a zone/ bind admin can best prepare for this scenario
**
TESTING:
I ran a very simple test where I had 2 valid zones with an ENT
between them. If I understand RFC-8020 correctly, they have
formalized the response of an ENT to RCODE=NOERROR and an empty
ANSWER section.
By querying the ENT "sales.101{redacted}.com." all descendants
(including the legitimate one "jwjw.sales.101{redacted}.com.")
would be effectively "cut" creating a temporary outage (Section 5).
My questions are:
* Did I include an error/ use bad logic in the test itself?
* Aside from stubbing out every ENT, what can be done to mitigate/
minimize this scenario?
* Are there any features I am overlooking which could help in
this case?
* For those with customers that cannot upgrade to latest bind,
how far back will these solutions work? (9.2.3rc1 -- 9.4.0a0)?
TEST DETAILS:
--
#> dig @127.0.0.1 101{redacted}.com.
; <<>> DiG 9.11.0-P3 <<>> @127.0.0.1 101{redacted}.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47566
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6
;; WARNING: recursion requested but not available
...
--
#> dig @127.0.0.1 sales.101{redacted}.com.
; <<>> DiG 9.11.0-P3 <<>> @127.0.0.1 sales.101{redacted}.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2264
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
...
--
#> dig @127.0.0.1 jwjw.sales.101{redacted}.com.
; <<>> DiG 9.11.0-P3 <<>> @127.0.0.1 jwjw.sales.101{redacted}.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25145
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6
;; WARNING: recursion requested but not available
...
Thanks,
John
-- 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: Configuration advice for a post-8020 world
On 12/02/2017 11:09, Woodworth, John R wrote:
SAMPLE ZONES:
101{redacted}.com. (REAL ZONE FILE)
jwjw.sales.101{redacted}.com. (REAL ZONE FILE)
You are missing the glue NS records in the parent zone (just verified by
local test of the before/after case). You need:
jwjw.sales.101{red}.com. IN NS ...
...in the "101{red}.com" zonefile. Yes, even if the same server has the
child 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: Configuration advice for a post-8020 world
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Phil
Mayers
>
> On 12/02/2017 11:09, Woodworth, John R wrote:
>
> > SAMPLE ZONES:
> > 101{redacted}.com. (REAL ZONE FILE)
> > jwjw.sales.101{redacted}.com. (REAL ZONE FILE)
>
> You are missing the glue NS records in the parent zone (just verified by
> local test of the before/after case). You need:
>
> jwjw.sales.101{red}.com. IN NS ...
>
> ...in the "101{red}.com" zonefile. Yes, even if the same server has the child
> zone.
Thanks Phil!
I was really hoping it was something in my setup. Guess I kind of thought bind
had
been inferring these same-server delegations with some type of elfin magic since
they just work.
I'll run some more tests this evening.
Thanks again,
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
>
>
-- 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
Quick Response Query for server-fail?
Hello. I found the slow response query at dns server. This query is server fail response. In reality, this query gets to response a server fail for foreign dns server. For example, maincastad.com’s glue record has 3 name server, 5 ip address. All glue record dns is not response. So, this query responses to slow. Is it possible to cache and quick response like ncache(negative cache)? Thanks. $ dig @b.gtld-servers.net maincastad.com ; <<>> DiG 9.9.9-P5 <<>> @b.gtld-servers.net maincastad.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38238 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 5 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;maincastad.com.IN A ;; AUTHORITY SECTION: maincastad.com. 172800 IN NS ns1.site4now.net. maincastad.com. 172800 IN NS ns2.site4now.net. maincastad.com. 172800 IN NS ns3.site4now.net. ;; ADDITIONAL SECTION: ns1.site4now.net. 172800 IN A 198.98.124.111 ns1.site4now.net. 172800 IN A 72.26.101.2 ns2.site4now.net. 172800 IN A 209.132.245.131 ns2.site4now.net. 172800 IN A 23.89.199.119 ns3.site4now.net. 172800 IN A 208.118.63.170 ;; Query time: 5 msec ;; SERVER: 192.33.14.30#53(192.33.14.30) ;; WHEN: Mon Feb 13 08:54:22 KST 2017 ;; MSG SIZE rcvd: 178 ___ 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: Quick Response Query for server-fail?
It looks like the domain has been abandoned. You could complain to domainab...@tucows.com to have NS records removed as the servers don't answer for the domain anymore. Domain Name: MAINCASTAD.COM Domain ID: 2007206421_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.tucows.com Registrar URL: http://tucowsdomains.com Updated Date: 2016-05-28T11:37:04Z Creation Date: 2016-02-28T05:16:55Z Registrar Registration Expiration Date: 2017-02-28T05:16:55Z Registrar: TUCOWS, INC. Registrar IANA ID: 69 Registrar Abuse Contact Email: domainab...@tucows.com Registrar Abuse Contact Phone: +1.4165350123 Domain Status: ok https://icann.org/epp#ok Registry Registrant ID: Registrant Name: Minjeong Na Registrant Organization: NONE Registrant Street: LA LA Registrant City: LA Registrant State/Province: LA Registrant Postal Code: 12345 Registrant Country: US Registrant Phone: +1.12345678 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: naminjeong...@gmail.com Registry Admin ID: Admin Name: Minjeong Na Admin Organization: NONE Admin Street: LA LA Admin City: LA Admin State/Province: LA Admin Postal Code: 12345 Admin Country: US Admin Phone: +1.12345678 Admin Phone Ext: Admin Fax: Admin Fax Ext: Admin Email: naminjeong...@gmail.com Registry Tech ID: Tech Name: Minjeong Na Tech Organization: NONE Tech Street: LA LA Tech City: LA Tech State/Province: LA Tech Postal Code: 12345 Tech Country: US Tech Phone: +1.12345678 Tech Phone Ext: Tech Fax: Tech Fax Ext: Tech Email: naminjeong...@gmail.com Name Server: NS1.SITE4NOW.NET Name Server: NS2.SITE4NOW.NET Name Server: NS3.SITE4NOW.NET DNSSEC: unsigned URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/ >>> Last update of WHOIS database: 2016-05-28T11:37:04Z <<< In message <8020ad1a5ac147d09769f298aab71...@skt-tnetpmx2.skt.ad>, Sukmoon Lee writes: > Hello. > > I found the slow response query at dns server. This query is server fail > response. > In reality, this query gets to response a server fail for foreign dns > server. > > For example, maincastad.coms glue record has 3 name server, 5 ip address. > All glue record dns is not response. So, this query responses to slow. > > Is it possible to cache and quick response like ncache(negative cache)? > Thanks. > > > $ dig @b.gtld-servers.net maincastad.com > > ; <<>> DiG 9.9.9-P5 <<>> @b.gtld-servers.net maincastad.com > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38238 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 5 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;maincastad.com.IN A > > ;; AUTHORITY SECTION: > maincastad.com. 172800 IN NS ns1.site4now.net. > maincastad.com. 172800 IN NS ns2.site4now.net. > maincastad.com. 172800 IN NS ns3.site4now.net. > > ;; ADDITIONAL SECTION: > ns1.site4now.net. 172800 IN A 198.98.124.111 > ns1.site4now.net. 172800 IN A 72.26.101.2 > ns2.site4now.net. 172800 IN A 209.132.245.131 > ns2.site4now.net. 172800 IN A 23.89.199.119 > ns3.site4now.net. 172800 IN A 208.118.63.170 > > ;; Query time: 5 msec > ;; SERVER: 192.33.14.30#53(192.33.14.30) > ;; WHEN: Mon Feb 13 08:54:22 KST 2017 > ;; MSG SIZE rcvd: 178 -- 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: Configuration advice for a post-8020 world
> -Original Message-
> From: Woodworth, John R
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Phil
> Mayers
> >
> > On 12/02/2017 11:09, Woodworth, John R wrote:
> >
> > > SAMPLE ZONES:
> > > 101{redacted}.com. (REAL ZONE FILE)
> > > jwjw.sales.101{redacted}.com. (REAL ZONE FILE)
> >
> > You are missing the glue NS records in the parent zone (just verified
> > by local test of the before/after case). You need:
> >
> > jwjw.sales.101{red}.com. IN NS ...
> >
> > ...in the "101{red}.com" zonefile. Yes, even if the same server has the
> > child zone.
>
> Thanks Phil!
>
> I was really hoping it was something in my setup. Guess I kind of thought
> bind had
> been inferring these same-server delegations with some type of elfin magic
> since
> they just work.
>
> I'll run some more tests this evening.
>
Phil,
Just ran a few more tests and it works without a hitch (even with an older
9.8 branch). I should have tried this before assuming it wouldn't make a
difference.
Thanks for reminding me about assumptions :)
/John
>
> Thanks again,
> 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
> >
> >
>
-- 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: Configuration advice for a post-8020 world
Named does not check that a parent zone has NS records for a child zone on the same server. Always add delegating NS records. As for ENT returning NXDOMAIN. Early versions of the specifications of DNSSEC said there were no NAMES, rather than NAMES with RECORDS, between names in a DNSSEC sorted zone. This changed the behaviour of ENTs from NODATA to NXDOMAIN. Versions of named which supported this specification of DNSSEC return NXDOMAIN rather than NODATA for ENT. It took a while to get the IETF working group to update to specification to restore ENT. -- 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
