[no subject]

[Mark Andrews]

In message , hugo hugoo writes:
> 
> Doug
> 
> The problem is that the parent zone and the subzone are on the same name se=
> rver.
> 
> If I do a dig @name_server subzone NS  or   dig @name_server zone NS   ... =
> I receive the same NS answer.
 
Hugo, you asked this before and you got a number of answers already
which I will repeat below.

Mark

1)  Make a DS query.  A DNSSEC aware nameserver will answer from
the parent zone, not the child zone.  From that you can determine
if the NS RRset is present or not.  You can't however check the
contents.

2) Transfer the parent zone and check the records in that.

3) Set up a slave of the parent zone only and ask it.

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

[Doug Barton]

On 3/19/2012 3:58 PM, hugo hugoo wrote:
> Doug,
> 
> The problem is that the parent zone and the subzone are on the same name
> server.
> 
> If I do a dig @name_server subzone NS  or   dig @name_server zone NS  
> ... I receive the same NS answer.

Then you would need access to the text files.


-- 
If you're never wrong, you're not trying hard enough
___
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:

[hugo hugoo]

Doug,

The problem is that the parent zone and the subzone are on the same name server.

If I do a dig @name_server subzone NS  or   dig @name_server zone NS   ... I 
receive the same NS answer.


> From: do...@dougbarton.us
> To: hugo...@hotmail.com
> CC: cat...@isc.org; bind-users@lists.isc.org
> Subject: Re:
> 
> On 3/19/2012 10:08 AM, hugo hugoo wrote:
> > Hello,
> >  
> > I have correctly understood the need to have the NS of a subdomain in
> > the parent domain to avoid any malfunction with a future migratio to DNSSEC.
> >  
> > But can anybody give me a clear method to detect such missconfiguration?
> > Is this possible with dig or is it ony possible with the access to the
> > bind text files?
> 
> When you query the parent name servers for those records, what happens?
> 
> 
> Doug
> 
> 
> -- 
> If you're never wrong, you're not trying hard enough
  ___
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:

[Doug Barton]

On 3/19/2012 10:08 AM, hugo hugoo wrote:
> Hello,
>  
> I have correctly understood the need to have the NS of a subdomain in
> the parent domain to avoid any malfunction with a future migratio to DNSSEC.
>  
> But can anybody give me a clear method to detect such missconfiguration?
> Is this possible with dig or is it ony possible with the access to the
> bind text files?

When you query the parent name servers for those records, what happens?


Doug


-- 
If you're never wrong, you're not trying hard enough
___
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: reverse dns for IPV6 ranges

[Jay Ford]

On Mon, 19 Mar 2012, hugo hugoo  wrote:

 Jay,

- Can you give me an example of such configuration?


Sure.

Say I use a DHCP pool of :a123:b456::/96 within each /64 subnet.

For example:
   subnet DHCP pool
   _  ___
   2001:db8:0:a::/64  2001:db8:0:a:a123:b456::/96
   2001:db8:0:b::/64  2001:db8:0:b:a123:b456::/96
   2001:db8:0:c::/64  2001:db8:0:c:a123:b456::/96

Then you put this in every /64 subnet zone:
;
*.6.5.4.b.3.2.1.a   IN  PTR dhcpv6.whatever.edu.
;

so that PTR queries for addresses like:
   2001:db8:0:a:a123:b456::4
   2001:db8:0:b:a123:b456:1:2
   2001:db8:0:c:a123:b456:abc:def
all return "dhcpv6.whatever.edu".

To make that less tedious, I create a file called "dhcpv6.ptr.inc" like this:

;
; dhcpv6.ptr.inc
; include file defining wildcard PTR record for DHCPv6 pools
$TTL 86400
@   IN  PTR dhcpv6.whatever.edu.
;

Each subnet zone file (e.g., zone a.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
for subnet 2001:db8:0:a::/64) pulls in that file via:

;
$INCLUDE dhcpv6.ptr.inc *.6.5.4.b.3.2.1.a
;

That way if I want to change the name in the PTR record I edit 1 file instead
of every zone file.


Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
___
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: reverse dns for IPV6 ranges

[michoski]

On 3/19/12 11:58 AM, "Peter Andreev"  wrote:
> 2012/3/19 hugo hugoo 
>>  Jay,
>> 
>> - Can you give me an example of such configuration?
>> 
>> As anyone else some examples of IPV6 reverse configuration used in
>> production environment?
>> 
>> Thanks for sharing your experience...
> 
> We use IPv6 in production environment. It was a real headache to fill
> reverse ip6.arpa zones by hand until I have learned about "arpaname"
> utility. Since that maintaining reverse IPv6 zones is just a piece of cake.

Hmm...  Yes, well I can see this as useful (though not much more than a few
lines of any programming language?) if you intend to maintain generic
placeholders...but not if you want RFC-compliant matching A/PTR.  Granted,
you should not drop mail in such cases, but many do.  I guess tools and best
practices take time to catch up to technological leaps.  ;-)

Or do you actually create A's matching your generic PTR and heavily rely on
CNAMEs?  Of course that simply won't do for some standard RR types.

As much as I dislike djb in general, the way tinydns auto-creates matching
PTR (and also provides a mechanism to disable as needed) for each A RR kinda
makes sense.  Granted, it doesn't do IPv6 at all without 3rd-party
hacks...but they do at least exist.

-- 
All his life he has looked away... to the horizon, to the sky,
to the future.  Never his mind on where he was, on what he was doing.
-- Yoda

___
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: "rndc reconfig" vs. "rndc reload"

[Mark Pettit]

Yeah, I'm familiar with the improvements to "reconfig".  You all have answered 
my questions.

To be clear, the issue was that "reload" by itself was taking way too long.  We 
have already implemented changes for when the *list of zones* has not changed, 
we do "reload " for each individually-changed zone file.  But I was 
wondering what to do if we have a *new zone* added to named.conf.

I've learned from the various responses that the best solution is just "rndc 
reconfig" with BIND 9.9.  It will cause minimum downtime and will pick up the 
new zones without having to subsequently do "rndc reload ".

On Mar 16, 2012, at 4:09 AM, Matus UHLAR - fantomas wrote:

>> On 3/16/2012 4:10 AM, Mark Pettit wrote:
>>> We have an antiquated push process that copies files into the 
>>> zonefile directory and then tells BIND "rndc reload".  For various 
>>> reasons, "rndc reload" takes about 120 seconds to complete.  BIND is 
>>> not answering queries for a very large part of that time.
> 
>>> I recently started experimenting with a different process: instead of 
>>> "rndc reload" after updaing some of the zone files, I loop through 
>>> the list of updated zone files and run "rndc reload" for each 
>>> one.
> 
> could the push process be changed to reload each individual zone after 
> it's changed?
> 
>>> This is a vast improvement, because BIND doesn't appear to ever stop 
>>> answering queries.
> 
>>> However, I'm curious what I should do when an update contains both a 
>>> new config file and new zone files.
> 
> as others have already mentioned, 'rndc reconfig' will rescan config 
> file and load new zones. You must still reload those updated.
> 
>>> Normally a "rndc reload" would rescan the config and then scan all 
>>> zone files (including the new ones), loading the new ones into 
>>> memory and starting to serve them.  But obviously we want to avoid 
>>> "rndc reload" at all costs.
> 
> iiuc, reload forcifullly reloads all zones from disk, without checking 
> for files' timestamps (just for cases where timestamp didn't change but 
> files did). That would explain the delays. loading zones is very slow, 
> BIND 9.9 should make it faster.
> 
>>> I was considering doing "rndc reconfig", followed by a "rndc 
>>> reload" for each of the new zones.
> 
>>> Would this work?
> 
> yes, this should work.
> 
> On 16.03.12 05:49, Jonathan Vomacka wrote:
>> an rndc reload is usually for an individual zone file. If you update 
>> a zone (and change the serial number) a reload will implement the new 
>> changes.
> 
> Well, iirc the OP's problem is that when "rndc reload" is NOT for 
> individual zone file, it takes very long. The question is, if/how can 
> it be made to run faster.
> 
> -- 
> 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.
> I just got lost in thought. It was unfamiliar territory. 
> ___
> 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: Name Resolution issue with one domain

[Anand Buddhdev]

On 19/03/2012 21:28, babu dheen wrote:

Babu,

> Dear Support,
>  
> I am trying to resolve www.dubaiairport.com from my GW BIND server
> as below. But not getting any output
>  
>  $ dig A www.dubaiairport.com
> ; <<>> DiG 9.3.4-P1 <<>> A www.dubaiairport.com
> ;; global options:  printcmd
> ;; connection timed out; no servers could be reached
> 
>  
> Whereas, when i try through dubaiairport.com NS, i am getting the
> response as below. What could be the problem. Any idea?

It could be any number of things, and your vague question doesn't
provide any useful information for anyone to even begin guessing at the
problem. First of all, learn how to ask smart questions:

http://www.catb.org/~esr/faqs/smart-questions.html

Next, try looking at the logs of your BIND server; perhaps it has logged
the reason for this resolution failure.

Regards,

Anand Buddhdev
RIPE NCC
___
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: Name Resolution issue with one domain

[Michael Sinatra]

On 03/19/12 13:28, babu dheen wrote:

Dear Support,
I am trying to resolve www.dubaiairport.com
 from my GW BIND server as below. But not
getting any output
$ dig A www.dubaiairport.com 
; <<>> DiG 9.3.4-P1 <<>> A www.dubaiairport.com

;; global options: printcmd
;; connection timed out; no servers could be reached
Whereas, when i try through dubaiairport.com NS, i am getting the
response as below. What could be the problem. Any idea?
$ dig @213.42.52.79 A www.dubaiairport.com 
; <<>> DiG 9.3.4-P1 <<>> @213.42.52.79 A www.dubaiairport.com

; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48514
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.dubaiairport.com. IN A
;; ANSWER SECTION:
www.dubaiairport.com . 7200 IN A 213.42.55.169
;; Query time: 127 msec
;; SERVER: 213.42.52.79#53(213.42.52.79)
;; WHEN: Mon Mar 19 23:25:35 2012
;; MSG SIZE rcvd: 54


When you see this sort of situation, a good guess is that there is an 
authority mismatch and some/all of the authoritative NS records listed 
in the child zone are not responding.  In this case, there is an 
authority mismatch:


dig +trace ns dubaiairport.com

[skip root response]

dubaiairport.com.   172800  IN  NS  dcaowa01.dubaiairport.com.
dubaiairport.com.   172800  IN  NS  svr-b003.dubaiairport.com.
[RRSIG deleted]
;; Received 608 bytes from 192.12.94.30#53(192.12.94.30) in 724 ms

dubaiairport.com.   7200IN  NS  secdns.dubaiairport.com.
dubaiairport.com.   7200IN  NS  auhans2.ecompany.ae.
dubaiairport.com.   7200IN  NS  dxbans2.ecompany.ae.
dubaiairport.com.   7200IN  NS  dxbans1.ecompany.ae.
dubaiairport.com.   7200IN  NS  dcaowa01.dubaiairport.com.
dubaiairport.com.   7200IN  NS  auhans1.ecompany.ae.
dubaiairport.com.   7200IN  NS  svr-b003.dubaiairport.com.
;; Received 323 bytes from 213.42.52.79#53(213.42.52.79) in 279 ms

One of the above DNS servers, secdns.dubaiairport.com, isn't responding 
for me.  Sometimes that's enough to cause intermittent timeouts for dig.


dig +nssearch dubaiairport.com
SOA dcaowa01.dca.com. administrator.dubaiairport.com. 2005061961 900 600 
86400 7200 from server 213.42.52.79 in 278 ms.
SOA dcaowa01.dca.com. administrator.dubaiairport.com. 2005061961 900 600 
86400 7200 from server 195.229.237.52 in 278 ms.
SOA dcaowa01.dca.com. administrator.dubaiairport.com. 2005061961 900 600 
86400 7200 from server 194.170.1.99 in 282 ms.
SOA dcaowa01.dca.com. administrator.dubaiairport.com. 2005061961 900 600 
86400 7200 from server 213.42.52.75 in 288 ms.
SOA dcaowa01.dca.com. administrator.dubaiairport.com. 2005061961 900 600 
86400 7200 from server 194.170.1.6 in 289 ms.
SOA dcaowa01.dca.com. administrator.dubaiairport.com. 2005061961 900 600 
86400 7200 from server 194.170.1.7 in 293 ms.
;; connection timed out; no servers could be reached [referring to 
secdns.dubaiairport.com]


michael



___
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

Name Resolution issue with one domain

[babu dheen]

Dear Support,
 
 I am trying to resolve www.dubaiairport.com from my GW BIND server as below. 
But not getting any output
 
 $ dig A www.dubaiairport.com
; <<>> DiG 9.3.4-P1 <<>> A www.dubaiairport.com
;; global options:  printcmd
;; connection timed out; no servers could be reached

 
Whereas, when i try through dubaiairport.com NS, i am getting the response as 
below. What could be the problem. Any idea?
 
$ dig @213.42.52.79 A www.dubaiairport.com
; <<>> DiG 9.3.4-P1 <<>> @213.42.52.79 A www.dubaiairport.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48514
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.dubaiairport.com.  IN  A
;; ANSWER SECTION:
www.dubaiairport.com.   7200    IN  A   213.42.55.169
;; Query time: 127 msec
;; SERVER: 213.42.52.79#53(213.42.52.79)
;; WHEN: Mon Mar 19 23:25:35 2012
;; MSG SIZE  rcvd: 54
___
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: zone transfer with DIG: SOA duplicate

[michoski]

On 3/19/12 10:49 AM, "hugo hugoo"  wrote:
> thanks for this quick answer.
> I am a liitle bit lost...
>  
> What is the starting and ending SOA record?
>  
> In the original zone, there is ony one SOA record...

FWIW,

When transferring it is normal to get the SOA as first and last record.  Use
+onesoa to avoid this with dig.  Lots of info on Google about this.  Also in
dig's man page, depending on your BIND/dig version.

-- 
Don't worry about avoiding temptation -- as you grow older, it starts
avoiding you.  -- The Old Farmer's Almanac


___
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: reverse dns for IPV6 ranges

[Peter Andreev]

2012/3/19 hugo hugoo 

>  Jay,
>
> - Can you give me an example of such configuration?
>
>
>
> As anyone else some examples of IPV6 reverse configuration used in
> production environment?
>
> Thanks for sharing your experience...
>
> Hugo,
>

We use IPv6 in production environment. It was a real headache to fill
reverse ip6.arpa zones by hand until I have learned about "arpaname"
utility. Since that maintaining reverse IPv6 zones is just a piece of cake.


>  > Date: Mon, 12 Mar 2012 16:28:53 -0500
> > From: jay-f...@uiowa.edu
>
> > To: hugo...@hotmail.com
> > CC: bind-users@lists.isc.org
> > Subject: RE: reverse dns for IPV6 ranges
> >
> > On Mon, 12 Mar 2012, hugo hugoo wrote:
> > > Has anyone else experience with reverse IPV6 configuration with Bind?
> >
> > We do static PTR records in the ip6.arpa zones like we do in the
> in-addr.arpa
> > zones, to create address->name mappings matching the name->address
> mappings
> > created by the  & A records.
> >
> > I fairly recently started fiddling with wildcard PTR records for DHCPv6
> > address pools, to at least return some answer for a query about the
> > addresses. Right now I have it configured so that a query for any
> address in
> > any of the pools returns the same name, but it could be changed to
> return
> > different names for different pools. This obviously doesn't create
> symmetric
> > name->address & address->name mapping, which might or might not be a
> problem.
> > I don't have enough real use of this to know whether this wildcard stuff
> is
> > helpful or not.
> >
> > 
> > Jay Ford, Network Engineering Group, Information Technology Services
> > University of Iowa, Iowa City, IA 52242
> > email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
>
> ___
> 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
>



-- 
AP
___
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: zone transfer with DIG: SOA duplicate

[Jan-Piet Mens]

> What is the starting and ending SOA record?
>  
> In the original zone, there is ony one SOA record...

The "starting" SOA is the SOA in your zone. The final SOA is used to
indicate end-of-transfer and is a copy of the first; you can safely
ignore it or, as Michael pointed out, supress it.

-JP
___
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: zone transfer with DIG: SOA duplicate

[Anand Buddhdev]

On 19/03/2012 18:49, hugo hugoo wrote:

> thanks for this quick answer.
> I am a liitle bit lost...
>  
> What is the starting and ending SOA record?
>  
> In the original zone, there is ony one SOA record...

The SOA record at the end signals the end of the zone transfer.

Regards,

Anand
___
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: zone transfer with DIG: SOA duplicate

[hugo hugoo]

Hello,
 
thanks for this quick answer.
I am a liitle bit lost...
 
What is the starting and ending SOA record?
 
In the original zone, there is ony one SOA record...
 
Hugo,
 

 

> Date: Mon, 19 Mar 2012 10:41:22 -0700
> From: mich...@rancid.berkeley.edu
> To: hugo...@hotmail.com
> CC: bind-users@lists.isc.org
> Subject: Re: zone transfer with DIG: SOA duplicate
> 
> On 03/19/12 10:33, hugo hugoo wrote:
> > Dear all,
> >
> > I have this strange behaviour when I do a zone transfer with the
> > following commande:
> >
> > dig @name_server zone_name AXFR
> >
> >
> > ==> I received 2 SOA records (duplicates).
> >
> > One SOA record is at the end of the received information.
> >
> >
> > Is this normal?
> 
> Yes.
> 
> In recent versions of dig, you can use the following option, as 
> documented in the man page:
> 
> +[no]onesoa
> Print only one (starting) SOA record when performing an 
> AXFR. The
> default is to print both the starting and ending SOA records.
> 
> 
> michael
  ___
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: zone transfer with DIG: SOA duplicate

[Michael Sinatra]

On 03/19/12 10:33, hugo hugoo wrote:

Dear all,

I have this strange behaviour when I do a zone transfer with the
following commande:

dig @name_server zone_name AXFR


==> I received 2 SOA records (duplicates).

One SOA record is at the end of the received information.


Is this normal?


Yes.

In recent versions of dig, you can use the following option, as 
documented in the man page:


   +[no]onesoa
   Print only one (starting) SOA record when performing an 
AXFR. The

   default is to print both the starting and ending SOA records.


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

zone transfer with DIG: SOA duplicate

[hugo hugoo]

Dear all,
 
I have this strange behaviour when I do a zone transfer with the following 
commande:
 
dig @name_server  zone_name AXFR
 
 
==> I received 2 SOA records (duplicates).
 
One SOA record is at the end of the received  information.
 
 
Is this normal?
 
 
Thanks for any feedback,
 
Hugo,
 
 
PS I used a DIG from a BIND 9.7 on redhat.  
  ___
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: reverse dns for IPV6 ranges

[hugo hugoo]

Jay,
 
- Can you give me an example of such configuration?
 
 

As anyone else some examples of IPV6 reverse configuration used in production 
environment?
 
Thanks for sharing your experience...
 
Hugo,
 

> Date: Mon, 12 Mar 2012 16:28:53 -0500
> From: jay-f...@uiowa.edu
> To: hugo...@hotmail.com
> CC: bind-users@lists.isc.org
> Subject: RE: reverse dns for IPV6 ranges
> 
> On Mon, 12 Mar 2012, hugo hugoo wrote:
> > Has anyone else experience with reverse IPV6 configuration with Bind?
> 
> We do static PTR records in the ip6.arpa zones like we do in the in-addr.arpa
> zones, to create address->name mappings matching the name->address mappings
> created by the  & A records.
> 
> I fairly recently started fiddling with wildcard PTR records for DHCPv6 
> address pools, to at least return some answer for a query about the 
> addresses. Right now I have it configured so that a query for any address in 
> any of the pools returns the same name, but it could be changed to return 
> different names for different pools. This obviously doesn't create symmetric 
> name->address & address->name mapping, which might or might not be a problem. 
> I don't have enough real use of this to know whether this wildcard stuff is 
> helpful or not.
> 
> 
> Jay Ford, Network Engineering Group, Information Technology Services
> University of Iowa, Iowa City, IA 52242
> email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
  ___
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:

[hugo hugoo]

Hello,
 
I have correctly understood the need to have the NS of a subdomain in the 
parent domain to avoid any malfunction with a future migratio to DNSSEC.
 
But can anybody give me a clear method to detect such missconfiguration?
Is this possible with dig or is it ony possible with the access to the bind 
text files?
 
Regards,
 
Hugo,
 

 

> Date: Wed, 14 Mar 2012 09:36:26 +
> From: cat...@isc.org
> To: bind-users@lists.isc.org
> Subject: Re:
> 
> On 13/03/12 20:46, Mark Andrews wrote:
> > 
> > In message , Daniel McDonald 
> > writ
> > es:
> >>
> >> On 3/13/12 8:20 AM, "hugo hugoo"  wrote:
> >>
> >>> ==> do I have to create in zone "toto.be" the following NS record:
> >>> 
> >>> titi.toto.be. TTL IN NS ns1.xxx.be
> >>> 
> >>> 
> >>> I have found cases where this situation is present and other when it is 
> >>> not
> >>> present...and both cases seems to work.
> >>> What is the difference?
> >>
> >> The glue records aren't necessary when both the zone and subzone are on the
> >> same server, although it is good to have them for completeness. When the
> >> zones are on different servers you need the glue records.
> > 
> > No, they *are* necessary. Just because their lack does not cause
> > a resolution failure in all cases it doesn't mean they are not
> > necessary.
> > 
> > If the parent zone is signed but the child zone is unsigned then
> > the lack of NS records *will* cause validation failures unless
> > OPTOUT is in use even when both zones are only served by a common
> > set of servers.
> > 
> > DNSSEC catches out lots of bad practices that mostly pass unnoticed
> > with plain DNS.
> > 
> > Mark
> 
> I would recommend doing it properly including adding glue records (glue
> is the A records associated with the NS records for the delegated child
> zone - but only if those NS records point to names actually in the
> delegated zone).
> 
> If you don't do it properly, and then in say 12 months time, someone
> else starts slaving the parent zone to another server that doesn't also
> slave the child zone, things are going to break...
> ___
> 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