Re: Using BIND-DLZ for a hidden master [was: Re: dns master-slave transfer]

[Jan-Piet Mens]

Chris,

> Can one use BIND 9.9 "inline signing"
> with the unsigned version provided by a DLZ interface?

there's no reason why you shouldn't be able to.

Your BIND 9.9 inline signer would AXFR from BIND DLZ without trouble,
but your signer won't be notified by DLZ; you'd have to "manually"
issue NOTIFY (e.g. dnsnotify.pl) via cron or from a MySQL trigger
(that's how I'd do it, anyway :)

-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: BIND and DNSSEC

[Feng He]

? 2012-10-31 23:05, Kobus Bensch ??:
Can anybody point me in the direction of a good guide on setting up 
BIND split horizon DNS and DNSSEC?


Take a look at:
http://www.dnssec.lk/docs/DNSSEC_in_6_minutes.pdf
___
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: Delegations

[Mark Andrews]

In message <5091adef.1040...@dougbarton.us>, Doug Barton writes:
> On 10/31/2012 03:56 PM, Mark Andrews wrote:
> > You are equating a practice that was techically wrong, and known
> > to be wrong from the get go, with one that has never been techically
> > wrong.
> 
> Yes, I'm making exactly the same judgment that typical users make. "It
> works, so it must be Ok."
> 
> The fact that we ("experts") can get away with something, whether it's
> technically right/wrong/indifferent not withstanding, doesn't mean that
> it's good advice for the average user.
> 
> Doug

Putting in delegations where they are not needed introduces additional
work and more places that can go wrong.

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

Using BIND-DLZ for a hidden master [was: Re: dns master-slave transfer]

[Chris Thompson]

On Oct 29 2012, Feng He wrote:


于 2012-10-29 9:58, kavin 写道:

Now，I want transfer the zone data from the master dns serverto slave
dns server ,the master dns use bind-dlz+mysql and the slave dns server
use bind+file.


AFAIK, BIND DLZ doesn't send a notify message to slave, so both your
master and slave should be able to use the DLZ backend and run a mysql
replication for data sync.


That exchange prompts me to ask whether anyone has managed to use
BIND-DLZ in something like the following scenario.

We have a hidden master for vanity zones (we call them something else
for the punters) that runs in a small footprint virtual machine
together with the web server providing the updating interface. The
latter stores the data in a MySQL database.

At the moment there is a crontab that extracts data from that database
and updates zone files (if they need changing - there are some neat-o
optimisations) and does an "rndc reload" on the hidden master daemon.
That NOTIFYs the public nameservers for the zones, which are are in fact
our regular authoritative-only ones.

It seems that one ought to be able to use BIND-DLZ to cut out a step
there, but none of the how-to's for it seem to address this sort of
scenario, and the NOTIFY issue is particularly relevant. Fast responses
from the hidden master to queries are certainly *not* a requirement here,
and indeed we expect to be able to operate with it (and its MySQL database)
down for significant periods.

On the other hand, there is also a possibility that we might want to sign
the vanity zones (we use JANET, Nominet and Gandi for their registrations,
who all support signed delegations now), and how that would interact with
BIND-DLZ might also be an issue. Can one use BIND 9.9 "inline signing"
with the unsigned version provided by a DLZ interface?

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Delegations

[Doug Barton]

On 10/31/2012 03:56 PM, Mark Andrews wrote:
> You are equating a practice that was techically wrong, and known
> to be wrong from the get go, with one that has never been techically
> wrong.

Yes, I'm making exactly the same judgment that typical users make. "It
works, so it must be Ok."

The fact that we ("experts") can get away with something, whether it's
technically right/wrong/indifferent not withstanding, doesn't mean that
it's good advice for the average user.

Doug
___
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: Delegations

[Mark Andrews]

In message <5091a8bc.70...@dougbarton.us>, Doug Barton writes:
> On 10/31/2012 03:22 PM, Chris Thompson wrote:
> > On Oct 31 2012, Kevin Darcy wrote:
> > 
> > [...snip...]
> >> I know of at least 2 commerically-available DNS maintenance systems
> >> that, by default, do not allow what they call "dotted hostnames", by
> >> which they mean a name which is at least 2 labels below a zone cut, e.g.
> >> "foo.bar" in the "example.com" zone. Their underlying assumption seems
> >> to be that *every* level of the hierarchy will, in the
> >> usual/typical/default case, be delegated.
> >>
> >> I don't agree with this assumption in the slightest, but some people are
> >> afraid of changing default behaviors...
> > 
> > What "default behavior"? The default behavior of (seriously) defective
> > DNS maintenance systems? (You wouldn't like to name-and-shame, I suppose?)
> > 
> > The end-point of that sort of logic is that, for example, the SRV record
> > for _someservice._tcp.somename.example.com has to have separate zones
> > for somename.example.com and _tcp.somename.example.com, probably
> > containing nothing but the names mentioned.  I've seen people actually
> > do this, and it's painful to watch.
> 
> Chris, I specifically asked the OP if they wanted a zone cut at the
> higher level, or if they were just looking for multi-dot names. So this
> particular argumentum ad absurdum is particularly inappropriate.
> 
> We used to say that you didn't need to do a delegation if the subzone
> was going to be hosted on the same auth. name server either, and then
> along came DNSSEC and lots of people with systems that weren't breaking
> any rules are suddenly dealing with strange error messages.

Adding a child zone without adding the delegating NS records was
always a bad idea.  Such "instruction" also usually contained the
caveat "this is technically wrong and will cause issues if you ever
have machines that do not host both zones but you can get away with
it."

Nameserver also used to merge zone contents so that AXFR included
the NS records from the child zone.

> So sure, the OP could probably "get away with it" even without doing a
> zone cut at the middle level. But I stand by my assertion that for
> maximum future-proofing they're safer with it than without. Doing the
> zone cut costs them almost nothing now, and may save time/effort/energy
> down the road.

You are equating a practice that was techically wrong, and known
to be wrong from the get go, with one that has never been techically
wrong.

> Doug
> ___
> 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: Delegations

[Doug Barton]

On 10/31/2012 03:22 PM, Chris Thompson wrote:
> On Oct 31 2012, Kevin Darcy wrote:
> 
> [...snip...]
>> I know of at least 2 commerically-available DNS maintenance systems
>> that, by default, do not allow what they call "dotted hostnames", by
>> which they mean a name which is at least 2 labels below a zone cut, e.g.
>> "foo.bar" in the "example.com" zone. Their underlying assumption seems
>> to be that *every* level of the hierarchy will, in the
>> usual/typical/default case, be delegated.
>>
>> I don't agree with this assumption in the slightest, but some people are
>> afraid of changing default behaviors...
> 
> What "default behavior"? The default behavior of (seriously) defective
> DNS maintenance systems? (You wouldn't like to name-and-shame, I suppose?)
> 
> The end-point of that sort of logic is that, for example, the SRV record
> for _someservice._tcp.somename.example.com has to have separate zones
> for somename.example.com and _tcp.somename.example.com, probably
> containing nothing but the names mentioned.  I've seen people actually
> do this, and it's painful to watch.

Chris, I specifically asked the OP if they wanted a zone cut at the
higher level, or if they were just looking for multi-dot names. So this
particular argumentum ad absurdum is particularly inappropriate.

We used to say that you didn't need to do a delegation if the subzone
was going to be hosted on the same auth. name server either, and then
along came DNSSEC and lots of people with systems that weren't breaking
any rules are suddenly dealing with strange error messages.

So sure, the OP could probably "get away with it" even without doing a
zone cut at the middle level. But I stand by my assertion that for
maximum future-proofing they're safer with it than without. Doing the
zone cut costs them almost nothing now, and may save time/effort/energy
down the road.

Doug
___
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: Delegations

[Chris Thompson]

On Oct 31 2012, Kevin Darcy wrote:

[...snip...]

I know of at least 2 commerically-available DNS maintenance systems
that, by default, do not allow what they call "dotted hostnames", by
which they mean a name which is at least 2 labels below a zone cut, e.g.
"foo.bar" in the "example.com" zone. Their underlying assumption seems
to be that *every* level of the hierarchy will, in the
usual/typical/default case, be delegated.

I don't agree with this assumption in the slightest, but some people are
afraid of changing default behaviors...


What "default behavior"? The default behavior of (seriously) defective
DNS maintenance systems? (You wouldn't like to name-and-shame, I suppose?)

The end-point of that sort of logic is that, for example, the SRV record
for _someservice._tcp.somename.example.com has to have separate zones
for somename.example.com and _tcp.somename.example.com, probably
containing nothing but the names mentioned.  I've seen people actually
do this, and it's painful to watch.

We were never in that mess as regards the DNS itself, but we did have
an IP registration database that delegated control over names on the basis
of a "domain part" taken to be all but the first label. It was hard work
to change it to allow the "domain part" for authorisation purposes to be
any trailing set of labels, but by ${DEITY?} it was necessary!

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Delegations

[Chris Thompson]

On Oct 31 2012, Phil Mayers wrote:


On 10/31/2012 06:51 PM, Doug Barton wrote:


It may or may not be strictly necessary to do this depending on
everything else you have in the zone, but it's safer in the long term to
do it this way.


Are you suggesting it's best of the OP creates "l2.example.com" as a 
sub-zone?


Why it this necessary / safer?


It certainly isn't necessary. We have plenty of zone cuts more than one
label deep into the parent zone. And of course such delegations are
*extremely* common in the reverse lookup trees, with the IPv6 one
probably providing records for the number of labels between cuts.

I don't see how "safer" would apply, either.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Delegations

[Kevin Darcy]

On 10/31/2012 5:15 PM, Phil Mayers wrote:

On 10/31/2012 06:51 PM, Doug Barton wrote:


It may or may not be strictly necessary to do this depending on
everything else you have in the zone, but it's safer in the long term to
do it this way.


Are you suggesting it's best of the OP creates "l2.example.com" as a 
sub-zone?


Why it this necessary / safer?
I know of at least 2 commerically-available DNS maintenance systems 
that, by default, do not allow what they call "dotted hostnames", by 
which they mean a name which is at least 2 labels below a zone cut, e.g. 
"foo.bar" in the "example.com" zone. Their underlying assumption seems 
to be that *every* level of the hierarchy will, in the 
usual/typical/default case, be delegated.


I don't agree with this assumption in the slightest, but some people are 
afraid of changing default behaviors...


- Kevin
___
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: Delegations

[Phil Mayers]

On 10/31/2012 06:51 PM, Doug Barton wrote:


It may or may not be strictly necessary to do this depending on
everything else you have in the zone, but it's safer in the long term to
do it this way.


Are you suggesting it's best of the OP creates "l2.example.com" as a 
sub-zone?


Why it this necessary / safer?
___
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: Spotty Lookups on One of Our Networks

[Martin McCormick]

The system hung long enough to have timed out on every
possible DNS that it could have tried so it should have gotten
to one.

Barry Margolin writes:
> Did the problem coincide with Hurricane Sandy? That would explain
> inability to reach many east coast servers. Resolvers should work around
> this by failing over to other servers (assuming the organization has
> them geographically distributed, as NOAA.GOV does), but dig +trace
> doesn't.

Thank you very much for your suggestions. 
We are more or less in a waiting mode right now as the
network staff on our remote campus check some settings on their
firewall. We know now this is almost certainly not a bind issue
as we have discovered many remote networks that seem to have no
TCP/IP connectivity from the remote campus but are perfectly
reachable from here. 

We started receiving complaints about a week ago so the
hurricane is not to blame.

I will let the group know what happened as soon as we
find out, ourselves.

Martin McCormick
___
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: Delegations

[Doug Barton]

On 10/31/2012 10:12 AM, wbr...@e1b.org wrote:
> I have a zone file for example.org that has entries for a subdomain 
> l2.example.org like this:
> 
> vpn.l2 IN A10.1.2.3
> 
> Now they want to add a subdomain below l2, ie. ad.l2.eboces.org with hosts 
> such as dc.ad.l2.eboces.org

As someone else pointed out, you're confusing different terms here. If
all you want is to add new host names that have "l2.eboces.org" in them,
you can do that without creating a zone cut.

OTOH, if what you want to do is create a new zone at ad.l2.eboces.org
because you want to delegate it to _different_ name servers than those
authoritative for eboces.org, then yes; your safest bet is to do proper
zone cuts at each level. It's perfectly Ok to have the name servers for
l2.eboces.org be the same as those for eboces.org, just make sure you
move any related records (such as your vpn.l2 above) into the new zone
file.

It may or may not be strictly necessary to do this depending on
everything else you have in the zone, but it's safer in the long term to
do it this way.

hope this helps,

Doug


> In the zone file for example.org, I can add NS and glue records for 
> ad.l2.example.org as this:
> dc.ad.l2  IN A 10.2.3.4
> dr.ad.l2  IN A 10.4.5.6
> ad.l2 IN NS dc.ad.l2.example.org.
> ad.l2 IN NS  dr.ad.l2.eboces.org.
> 
> Will this work, or do I need to delegate l2.example.org before I can 
> delegate ad.l2.example.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: Delegations

[WBrown]

Phil wrote on 10/31/2012 02:15:16 PM:

> You terminology is a bit confusing here. "subdomain" is imprecise. 

Sorry, I meant it as a piece of the FQDN.

> Specify what *zones* you want, and where you want the delegations, and 
> it should be easy to see what will work and not.


> Yes, if I've understood what you want.

I think you got it.
 
> > or do I need to delegate l2.example.org before I can delegate 
> ad.l2.example.org?
> 
> No. Zone cuts can be at any label inside a zone.

Thanks.  Waiting for firewall changes tonight to test.



Confidentiality Notice: 
This electronic message and any attachments may contain confidential or 
privileged information, and is intended only for the individual or entity 
identified above as the addressee. If you are not the addressee (or the 
employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that 
you may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or 
telephone and delete this message from your system.
___
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: Delegations

[Tony Finch]

Phil Mayers  wrote:
>
> No. Zone cuts can be at any label inside a zone.

Provided "inside" does not include the zone apex :-)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
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: Spotty Lookups on One of Our Networks

[John Miller]

Martin, what do you see if you do a packet capture on the host where you're
running dig?  How 'bout at the border of your network?  Obviously traffic's
not making it through, but where?  Any sort of split routing paths that
might be involved?

John

On Wed, Oct 31, 2012 at 8:54 AM, Martin McCormick  wrote:

> I described a case where one of our remote campuses can't
> resolve a number of remote domains. One example is noaa.gov. It
> also successfully resolves random remote domains without
> seemingly any rime or reason.
>
> Here is a bad dig trace for noaa.gov
>
>
> ; <<>> DiG 9.7.7 <<>> @localhost +trace noaa.gov
> ; (2 servers found)
> ;; global options: +cmd
> .   453464  IN  NS  b.root-servers.net.
> .   453464  IN  NS  l.root-servers.net.
> .   453464  IN  NS  a.root-servers.net.
> .   453464  IN  NS  i.root-servers.net.
> .   453464  IN  NS  j.root-servers.net.
> .   453464  IN  NS  f.root-servers.net.
> .   453464  IN  NS  g.root-servers.net.
> .   453464  IN  NS  e.root-servers.net.
> .   453464  IN  NS  h.root-servers.net.
> .   453464  IN  NS  d.root-servers.net.
> .   453464  IN  NS  c.root-servers.net.
> .   453464  IN  NS  k.root-servers.net.
> .   453464  IN  NS  m.root-servers.net.
> ;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 320 ms
>
> gov.172800  IN  NS  b.gov-servers.net.
> gov.172800  IN  NS  a.gov-servers.net.
> ;; Received 133 bytes from 192.58.128.30#53(192.58.128.30) in 210 ms
>
> noaa.gov.   86400   IN  NS  ns-e.noaa.gov.
> noaa.gov.   86400   IN  NS  ns-mw.noaa.gov.
> noaa.gov.   86400   IN  NS  ns-nw.noaa.gov.
>
> This trace took several minutes since no successful
> resolution was made.
>
> Here is a good trace using our DNS.
>
>
> ; <<>> DiG 9.8.1-P1 <<>> +trace @localhost noaa.gov
> ; (2 servers found)
> ;; global options: +cmd
> .   369104  IN  NS  d.root-servers.net.
> .   369104  IN  NS  j.root-servers.net.
> .   369104  IN  NS  b.root-servers.net.
> .   369104  IN  NS  g.root-servers.net.
> .   369104  IN  NS  i.root-servers.net.
> .   369104  IN  NS  e.root-servers.net.
> .   369104  IN  NS  l.root-servers.net.
> .   369104  IN  NS  m.root-servers.net.
> .   369104  IN  NS  h.root-servers.net.
> .   369104  IN  NS  f.root-servers.net.
> .   369104  IN  NS  c.root-servers.net.
> .   369104  IN  NS  a.root-servers.net.
> .   369104  IN  NS  k.root-servers.net.
> ;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 497 ms
>
> gov.172800  IN  NS  a.gov-servers.net.
> gov.172800  IN  NS  b.gov-servers.net.
> ;; Received 133 bytes from 192.112.36.4#53(192.112.36.4) in 439 ms
>
> noaa.gov.   86400   IN  NS  ns-e.noaa.gov.
> noaa.gov.   86400   IN  NS  ns-mw.noaa.gov.
> noaa.gov.   86400   IN  NS  ns-nw.noaa.gov.
> ;; Received 133 bytes from 69.36.157.30#53(69.36.157.30) in 224 ms
>
> noaa.gov.   86400   IN  A   140.90.200.21
> noaa.gov.   86400   IN  A   140.172.17.21
> noaa.gov.   86400   IN  A   129.15.96.21
> noaa.gov.   86400   IN  NS  ns-e.noaa.gov.
> noaa.gov.   86400   IN  NS  ns-mw.noaa.gov.
> noaa.gov.   86400   IN  NS  ns-nw.noaa.gov.
> ;; Received 181 bytes from 140.90.33.237#53(140.90.33.237) in 37 ms
>
> Barry Margolin writes:
> > I'm not sure what you mean by that sentence about getting authoritative
> > DNSs from X when it sbould be from Y. Can you post the actual dig?
> >
> > BTW, @servername doesn't mean much when using +trace, since +trace
> > queries the servers listed in NS records, not a resolver.
> ___
> 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
>



-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 

Re: Delegations

[Phil Mayers]

On 31/10/12 17:12, wbr...@e1b.org wrote:

I have a zone file for example.org that has entries for a subdomain
l2.example.org like this:

 vpn.l2 IN A10.1.2.3

Now they want to add a subdomain below l2, ie. ad.l2.eboces.org with hosts
such as dc.ad.l2.eboces.org


You terminology is a bit confusing here. "subdomain" is imprecise. 
Specify what *zones* you want, and where you want the delegations, and 
it should be easy to see what will work and not.


example.org SOA
www.example.org A  <- hostname, in example.org zone
vpn.l2.example.org  A  <- hostname, still in example.org zone

ad.l2.example.org   NS <- delegation point in example.org zone
xx.ad.l2example.org A  <- glue, *still* in example.org zone

...and of course then the SOA & zone contents for "ad.l2.example.org"



In the zone file for example.org, I can add NS and glue records for
ad.l2.example.org as this:
dc.ad.l2  IN A 10.2.3.4
dr.ad.l2  IN A 10.4.5.6
ad.l2 IN NS dc.ad.l2.example.org.
ad.l2 IN NS  dr.ad.l2.eboces.org.

Will this work,


Yes, if I've understood what you want.


or do I need to delegate l2.example.org before I can delegate ad.l2.example.org?


No. Zone cuts can be at any label inside a 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: Spotty Lookups on One of Our Networks

[Barry Margolin]

In article ,
 Carsten Strotmann  wrote:

> Hello Martin,
> 
> Martin McCormick  writes:
> 
> > I described a case where one of our remote campuses can't
> > resolve a number of remote domains. One example is noaa.gov. It
> > also successfully resolves random remote domains without
> > seemingly any rime or reason.
> >
> > Here is a bad dig trace for noaa.gov
> >
> [...]
> 
>  shows that
> nameserver ns-e.noaa.gov is not responding
> 
> The dig +trace might "hang" if that authoritative DNS server is selected
> for the query. 
> 
> "ns-mw.noaa.gov" and "ns-nw.noaa.gov" operate fine. "ns-e" could mean
> "east coast".

Did the problem coincide with Hurricane Sandy? That would explain 
inability to reach many east coast servers. Resolvers should work around 
this by failing over to other servers (assuming the organization has 
them geographically distributed, as NOAA.GOV does), but dig +trace 
doesn't.

-- 
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: limitations of dig +nssearch

[Tony Finch]

M. Meadows  wrote:
>
> Does anyone know why dig brownmackie.com +nssearch only returns 5 auth
> nameserver soa records? A check of whois shows they have 7 auth
> nameservers.

Two of them do not respond to queries for brownmackie.com.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at
first. Rough, becoming slight or moderate. Showers, rain at first.
Moderate or good, occasionally poor at first.
___
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

Delegations

[WBrown]

I have a zone file for example.org that has entries for a subdomain 
l2.example.org like this:

vpn.l2 IN A10.1.2.3

Now they want to add a subdomain below l2, ie. ad.l2.eboces.org with hosts 
such as dc.ad.l2.eboces.org

In the zone file for example.org, I can add NS and glue records for 
ad.l2.example.org as this:
dc.ad.l2  IN A 10.2.3.4
dr.ad.l2  IN A 10.4.5.6
ad.l2 IN NS dc.ad.l2.example.org.
ad.l2 IN NS  dr.ad.l2.eboces.org.

Will this work, or do I need to delegate l2.example.org before I can 
delegate ad.l2.example.org?


-- 

William Brown
Core Hosted Application Technical Team and Messaging Team
Technology Services, WNYRIC, Erie 1 BOCES





Confidentiality Notice: 
This electronic message and any attachments may contain confidential or 
privileged information, and is intended only for the individual or entity 
identified above as the addressee. If you are not the addressee (or the 
employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that 
you may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or 
telephone and delete this message from your system.
___
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

BIND and DNSSEC

[Kobus Bensch]

Hi 

Can anybody point me in the direction of a good guide on setting up BIND split 
horizon DNS and DNSSEC? 

Thanks in advance 

Kobus 

-- 


___
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

limitations of dig +nssearch

[M. Meadows]

Does anyone know why dig brownmackie.com +nssearch only returns 5 auth 
nameserver soa records? 
A check of whois shows they have 7 auth nameservers. 
A dig -t NS brownmackie.com @ shows 7 
nameservers are delegated authority for the domain. 
Is this a limitation of +nssearch? 
Can +nssearch only return up to 5 soa records?

Thanks!
Marty in Indianapolis

  ___
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: Spotty Lookups on One of Our Networks

[Carsten Strotmann]

Hello Martin,

Martin McCormick  writes:

> I described a case where one of our remote campuses can't
> resolve a number of remote domains. One example is noaa.gov. It
> also successfully resolves random remote domains without
> seemingly any rime or reason.
>
>   Here is a bad dig trace for noaa.gov
>
[...]

 shows that
nameserver ns-e.noaa.gov is not responding

The dig +trace might "hang" if that authoritative DNS server is selected
for the query. 

"ns-mw.noaa.gov" and "ns-nw.noaa.gov" operate fine. "ns-e" could mean
"east coast".

-- Carsten
___
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: Spotty Lookups on One of Our Networks

[Martin McCormick]

I described a case where one of our remote campuses can't
resolve a number of remote domains. One example is noaa.gov. It
also successfully resolves random remote domains without
seemingly any rime or reason.

Here is a bad dig trace for noaa.gov


; <<>> DiG 9.7.7 <<>> @localhost +trace noaa.gov
; (2 servers found)
;; global options: +cmd
.   453464  IN  NS  b.root-servers.net.
.   453464  IN  NS  l.root-servers.net.
.   453464  IN  NS  a.root-servers.net.
.   453464  IN  NS  i.root-servers.net.
.   453464  IN  NS  j.root-servers.net.
.   453464  IN  NS  f.root-servers.net.
.   453464  IN  NS  g.root-servers.net.
.   453464  IN  NS  e.root-servers.net.
.   453464  IN  NS  h.root-servers.net.
.   453464  IN  NS  d.root-servers.net.
.   453464  IN  NS  c.root-servers.net.
.   453464  IN  NS  k.root-servers.net.
.   453464  IN  NS  m.root-servers.net.
;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 320 ms

gov.172800  IN  NS  b.gov-servers.net.
gov.172800  IN  NS  a.gov-servers.net.
;; Received 133 bytes from 192.58.128.30#53(192.58.128.30) in 210 ms

noaa.gov.   86400   IN  NS  ns-e.noaa.gov.
noaa.gov.   86400   IN  NS  ns-mw.noaa.gov.
noaa.gov.   86400   IN  NS  ns-nw.noaa.gov.

This trace took several minutes since no successful
resolution was made.

Here is a good trace using our DNS.


; <<>> DiG 9.8.1-P1 <<>> +trace @localhost noaa.gov
; (2 servers found)
;; global options: +cmd
.   369104  IN  NS  d.root-servers.net.
.   369104  IN  NS  j.root-servers.net.
.   369104  IN  NS  b.root-servers.net.
.   369104  IN  NS  g.root-servers.net.
.   369104  IN  NS  i.root-servers.net.
.   369104  IN  NS  e.root-servers.net.
.   369104  IN  NS  l.root-servers.net.
.   369104  IN  NS  m.root-servers.net.
.   369104  IN  NS  h.root-servers.net.
.   369104  IN  NS  f.root-servers.net.
.   369104  IN  NS  c.root-servers.net.
.   369104  IN  NS  a.root-servers.net.
.   369104  IN  NS  k.root-servers.net.
;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 497 ms

gov.172800  IN  NS  a.gov-servers.net.
gov.172800  IN  NS  b.gov-servers.net.
;; Received 133 bytes from 192.112.36.4#53(192.112.36.4) in 439 ms

noaa.gov.   86400   IN  NS  ns-e.noaa.gov.
noaa.gov.   86400   IN  NS  ns-mw.noaa.gov.
noaa.gov.   86400   IN  NS  ns-nw.noaa.gov.
;; Received 133 bytes from 69.36.157.30#53(69.36.157.30) in 224 ms

noaa.gov.   86400   IN  A   140.90.200.21
noaa.gov.   86400   IN  A   140.172.17.21
noaa.gov.   86400   IN  A   129.15.96.21
noaa.gov.   86400   IN  NS  ns-e.noaa.gov.
noaa.gov.   86400   IN  NS  ns-mw.noaa.gov.
noaa.gov.   86400   IN  NS  ns-nw.noaa.gov.
;; Received 181 bytes from 140.90.33.237#53(140.90.33.237) in 37 ms

Barry Margolin writes:
> I'm not sure what you mean by that sentence about getting authoritative
> DNSs from X when it sbould be from Y. Can you post the actual dig?
> 
> BTW, @servername doesn't mean much when using +trace, since +trace
> queries the servers listed in NS records, not a resolver.
___
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