listen-to clusterIP address

[paul]

Hi. I have a two node active passive cluster serving webpages. When a
failover occurs, I have to restart named on the now active node because
the cluster Ip was not available when named originally started even
though I have listen-to the cluster ip listed in my named.conf. Is there
a way to make named listen-to an ip address that is not yet available?
Thanks. Paul

___
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: listen-to clusterIP address

[Phil Mayers]

On 06/05/2013 07:37 PM, paul wrote:

Hi. I have a two node active passive cluster serving webpages. When a
failover occurs, I have to restart named on the now active node because


You don't have to restart it. "rndc reconfig" will re-check the IPs on 
the machine and re-listen.



the cluster Ip was not available when named originally started even
though I have listen-to the cluster ip listed in my named.conf. Is there
a way to make named listen-to an ip address that is not yet available?


No. This has come up before - the bind listen-on statement is an ACL 
which is matched against the list of IPs on the box, not a list of IPs 
passed to the bind() syscall. There are various solutions, but "rndc 
reconfig" is the right one IMO.

___
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: listen-to clusterIP address

[paul]

Thanks for the quick reply. rndc reconfig has the same problem as a
restart. I need to automatically listen to the new ip address without
manual intervention. On Wed, 2013-06-05 at 09:14 +0100, Phil Mayers
wrote:
> On 06/05/2013 07:37 PM, paul wrote:
> > Hi. I have a two node active passive cluster serving webpages. When a
> > failover occurs, I have to restart named on the now active node because
> 
> You don't have to restart it. "rndc reconfig" will re-check the IPs on 
> the machine and re-listen.
> 
> > the cluster Ip was not available when named originally started even
> > though I have listen-to the cluster ip listed in my named.conf. Is there
> > a way to make named listen-to an ip address that is not yet available?
> 
> No. This has come up before - the bind listen-on statement is an ACL 
> which is matched against the list of IPs on the box, not a list of IPs 
> passed to the bind() syscall. There are various solutions, but "rndc 
> reconfig" is the right one IMO.
> ___
> 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: listen-to clusterIP address

[Peter Andreev]

2013/6/5 Phil Mayers 

> On 06/05/2013 07:37 PM, paul wrote:
>
>> Hi. I have a two node active passive cluster serving webpages. When a
>> failover occurs, I have to restart named on the now active node because
>>
>
> You don't have to restart it. "rndc reconfig" will re-check the IPs on the
> machine and re-listen.
>
>
This definitely will not work if BIND dropped privileges after start.


>
>  the cluster Ip was not available when named originally started even
>> though I have listen-to the cluster ip listed in my named.conf. Is there
>> a way to make named listen-to an ip address that is not yet available?
>>
>
The cimplest way, I think is to configure cluster IP on loopback interfaces
and set up routing


>
> No. This has come up before - the bind listen-on statement is an ACL which
> is matched against the list of IPs on the box, not a list of IPs passed to
> the bind() syscall. There are various solutions, but "rndc reconfig" is the
> right one IMO.
>
> __**_
> Please visit 
> https://lists.isc.org/mailman/**listinfo/bind-usersto
>  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: listen-to clusterIP address

[Mitchell Warden]

Hi Paul,

BIND will rescan the interfaces automatically - I think by default every 60 
minutes. If a listen-on address becomes available it should be used.

It would probably be better to automatically trigger a reconfig, but you can 
lower the scan time with the "interface-interval" option. I haven't had any 
problems setting it to 1 minute in situations that require it.

Cheers.
Mitchell

  _  

From: paul [mailto:p...@actionlans.com]
To: bind-users@lists.isc.org
Sent: Thu, 06 Jun 2013 04:37:52 +1000
Subject: listen-to clusterIP address

Hi. I have a two node active passive cluster serving webpages. When a
  failover occurs, I have to restart named on the now active node because
  the cluster Ip was not available when named originally started even
  though I have listen-to the cluster ip listed in my named.conf. Is there
  a way to make named listen-to an ip address that is not yet available?
  Thanks. Paul
  
  ___
  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: listen-to clusterIP address

[Phil Mayers]

Peter Andreev  wrote:

>2013/6/5 Phil Mayers 
>
>> On 06/05/2013 07:37 PM, paul wrote:
>>
>>> Hi. I have a two node active passive cluster serving webpages. When
>a
>>> failover occurs, I have to restart named on the now active node
>because
>>>
>>
>> You don't have to restart it. "rndc reconfig" will re-check the IPs
>on the
>> machine and re-listen.
>>
>>
>This definitely will not work if BIND dropped privileges after start.
>
>
>>
>>  the cluster Ip was not available when named originally started even
>>> though I have listen-to the cluster ip listed in my named.conf. Is
>there
>>> a way to make named listen-to an ip address that is not yet
>available?
>>>
>>
>The cimplest way, I think is to configure cluster IP on loopback
>interfaces
>and set up routing
>
>
>>
>> No. This has come up before - the bind listen-on statement is an ACL
>which
>> is matched against the list of IPs on the box, not a list of IPs
>passed to
>> the bind() syscall. There are various solutions, but "rndc reconfig"
>is the
>> right one IMO.
>>
>> __**_
>> Please visit
>https://lists.isc.org/mailman/**listinfo/bind-usersto
>unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>>
>https://lists.isc.org/mailman/**listinfo/bind-users
>>

As has been pointed out to me off list, this depends on your os. It definitely 
*does* work under Linux. But apologies for assuming!
-- 
Sent from my phone with, please excuse brevity and typos
___
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: listen-to clusterIP address

[paul]

Thanks again. I am using linux fedora17. I have tested changing
interface-interval to i min and that seems to work. I am also looking on
the cluster mailing list to see if I can include named in my cluster
configuration. Paul
On Wed, 2013-06-05 at 10:02 +0100, Phil Mayers wrote:
> Peter Andreev  wrote:
> 
> >2013/6/5 Phil Mayers 
> >
> >> On 06/05/2013 07:37 PM, paul wrote:
> >>
> >>> Hi. I have a two node active passive cluster serving webpages. When
> >a
> >>> failover occurs, I have to restart named on the now active node
> >because
> >>>
> >>
> >> You don't have to restart it. "rndc reconfig" will re-check the IPs
> >on the
> >> machine and re-listen.
> >>
> >>
> >This definitely will not work if BIND dropped privileges after start.
> >
> >
> >>
> >>  the cluster Ip was not available when named originally started even
> >>> though I have listen-to the cluster ip listed in my named.conf. Is
> >there
> >>> a way to make named listen-to an ip address that is not yet
> >available?
> >>>
> >>
> >The cimplest way, I think is to configure cluster IP on loopback
> >interfaces
> >and set up routing
> >
> >
> >>
> >> No. This has come up before - the bind listen-on statement is an ACL
> >which
> >> is matched against the list of IPs on the box, not a list of IPs
> >passed to
> >> the bind() syscall. There are various solutions, but "rndc reconfig"
> >is the
> >> right one IMO.
> >>
> >> __**_
> >> Please visit
> >https://lists.isc.org/mailman/**listinfo/bind-usersto
> >unsubscribe from this list
> >>
> >> bind-users mailing list
> >> bind-users@lists.isc.org
> >>
> >https://lists.isc.org/mailman/**listinfo/bind-users
> >>
> 
> As has been pointed out to me off list, this depends on your os. It 
> definitely *does* work under Linux. But apologies for assuming!


___
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: listen-to clusterIP address

[Phil Mayers]

On 05/06/13 20:06, paul wrote:

Thanks for the quick reply. rndc reconfig has the same problem as a
restart. I need to automatically listen to the new ip address without
manual intervention.


"rndc reconfig" need not be manual - surely your cluster software can 
execute a script on IP failover?


Anyway, as you've spotted, lowering the listen interval can emulate 
this. Personally I'd want bind to respond a bit quicker than 0-60 
seconds when a failover occurs.


The other alternative under Linux would be a long-running process 
listening to a netlink socket for address changes and exec'ing a 
reconfig. I wonder if there is such a beast?

___
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: listen-to clusterIP address

[G.W. Haywood]

Hi there,

On Wed, 5 Jun 2013, paul wrote:


I need to automatically listen to the new ip address without manual
intervention.


Listen on a virtual/alias whatever interface amnd forward ports from
the real one(s)?

--

73,
Ged.
___
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: listen-to clusterIP address

[Abdul Khader]

Better to write a script which would first check the availability of 
Virtual IP before doing "rndc reconfig" during a failover. In case the 
script does not find the VIP in the first run, you can put in a loop to 
check for VIP for N number of times with N number of seconds interval.
The failover time depends mostly on the resources being transferred. If 
VIP is the only resource, then the script should pick up the VIP in 
about 60-80 seconds.


Regards

Abdul Khader

On 05/06/2013 1:57 PM, Phil Mayers wrote:

On 05/06/13 20:06, paul wrote:

Thanks for the quick reply. rndc reconfig has the same problem as a
restart. I need to automatically listen to the new ip address without
manual intervention.


"rndc reconfig" need not be manual - surely your cluster software can 
execute a script on IP failover?


Anyway, as you've spotted, lowering the listen interval can emulate 
this. Personally I'd want bind to respond a bit quicker than 0-60 
seconds when a failover occurs.


The other alternative under Linux would be a long-running process 
listening to a netlink socket for address changes and exec'ing a 
reconfig. I wonder if there is such a beast?

___
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: listen-to clusterIP address

[Mark Andrews]

Use IPv6 and listen-on-v6 { any; };.  The IPv4 socket api doesn't have
the hooks to force the UDP replies from the correct address.  The IPv6
socket api has more functionality.

-- 
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: listen-to clusterIP address

[Phil Mayers]

On 05/06/13 12:42, Mark Andrews wrote:


Use IPv6 and listen-on-v6 { any; };.  The IPv4 socket api doesn't have
the hooks to force the UDP replies from the correct address.  The IPv6
socket api has more functionality.


For what it's worth, there is code to do this in other projects:

https://github.com/FreeRADIUS/freeradius-server/blob/master/src/lib/udpfromto.c

It's a bit hacky and uses various platform-specific APIs, but does seem 
to work reasonably well.

___
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

Confused about a basic concept

[Bryan Harris]

Hi all,I think I may be confused about a very basic DNS concept.  Sorry if this has been asked before.1. I have a master and two slaves.2. The master server is the SOA for my zone.  The SOA record points to the master server.3. Each of the two slaves are authoritative for my zone.4. There are 2 NS records for my zone.  The first NS = slave1 and the second NS = slave2.5. The Master server is not listed in the NS records for my zone.6. The master does not receive any queries from the clients.7. The slaves receive queries from the clients.8. The master -> slaves relationship is via tcp/53 (notifies & zone transfers)9. The slaves -> clients relationship is via udp/53 (queries)Is this correct so far?  I'm being told "our authoritative DNS servers should not receive any queries", as well as "DNS slaves respond to queries".  These statements seem like a conflict to me, but maybe I'm simply confused?I don't see how a slave could respond to a query unless it's authoritative.  The only thing I can imagine is adding some more caching servers just for queries and have them forward+recurse to the authoritative slave servers (but they're not slaves themselves).  But even in that case, the authoritative servers would still need to respond to queries, no?  Otherwise how would the caching servers get any answers in the first place?Bryan___
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: Confused about a basic concept

[Ben Croswell]

Everything you listed is pretty close to accurate.
A couple points of clarification.

8) The master needs UDP/TCP 53 open to the slaves.  Before a zone transfer
can happen the slave needs to get the SOA RR from the master to see if the
serial number has changed.  This normally happens over UDP 53(see my point
on 9).  So The slaves need to also be in the allow-query ACL on the master,
if they cant query for SOA they can never determine the serial number and
cant transfer.
9) You should always have UDP/TCP 53 open to DNS servers.  "Normal" queries
happen on UDP 53, but if an answer is too large to fit in a single packet
the answer will be truncated and the TC bit will be set.  This bit tells
the client they didnt get the "full" answer and that they may want to try
the same query via TCP.

On you last points you are pretty much spot on the answer but are wondering
the mechanics. Most best practices state that you should not have recursion
and authoritative on the same DNS server. That is a should, but not a must.
 What you said is the normal answer you run DNS servers that host zones,
and you run DNS servers that serve direct client queries. The client
caching DNS servers would need to know where your authoritative servers are
via NS records or forwarding.

One big reason for the split is DNSSEC. An authoritative DNS server cant
validate DNSSEC for a query sent directly to it from a client.  There has
to be another step in between.  For instance if I ask you if you are Bryan
and you say yes, why should I believe you.  However, if I ask a trusted
friend if you are Bryan I will believe you because there is third party
verification.



On Wed, Jun 5, 2013 at 10:02 AM, Bryan Harris  wrote:

> Hi all,
>
> I think I may be confused about a very basic DNS concept.  Sorry if this
> has been asked before.
>
> 1. I have a master and two slaves.
> 2. The master server is the SOA for my zone.  The SOA record points to the
> master server.
> 3. Each of the two slaves are authoritative for my zone.
> 4. There are 2 NS records for my zone.  The first NS = slave1 and the
> second NS = slave2.
> 5. The Master server is not listed in the NS records for my zone.
> 6. The master does not receive any queries from the clients.
> 7. The slaves receive queries from the clients.
> 8. The master -> slaves relationship is via tcp/53 (notifies & zone
> transfers)
> 9. The slaves -> clients relationship is via udp/53 (queries)
>
> Is this correct so far?  I'm being told "our authoritative DNS servers
> should not receive any queries", as well as "DNS slaves respond to
> queries".  These statements seem like a conflict to me, but maybe I'm
> simply confused?
>
>
> I don't see how a slave could respond to a query unless it's
> authoritative.  The only thing I can imagine is adding some more caching
> servers just for queries and have them forward+recurse to the authoritative
> slave servers (but they're not slaves themselves).  But even in that case,
> the authoritative servers would still need to respond to queries, no?
>  Otherwise how would the caching servers get any answers in the first place?
>
> Bryan
>
>
> ___
> 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
>



-- 
-Ben Croswell
___
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: Confused about a basic concept

[Warren Kumari]

On Jun 5, 2013, at 9:02 AM, Bryan Harris  wrote:

> Hi all,
> 
> I think I may be confused about a very basic DNS concept.  

Many people are, but most don't a: know or B: admit it :-P

> Sorry if this has been asked before.
> 
> 1. I have a master and two slaves.
> 2. The master server is the SOA for my zone.  The SOA record points to the 
> master server.
> 3. Each of the two slaves are authoritative for my zone.
> 4. There are 2 NS records for my zone.  The first NS = slave1 and the second 
> NS = slave2.
> 5. The Master server is not listed in the NS records for my zone.
> 6. The master does not receive any queries from the clients.

Yup, this sounds right -- this is usually called a "hidden master" setup.
Some folk do this, some simply publish all of the servers in the NS set. 
Entirely up to you.

> 7. The slaves receive queries from the clients.
> 8. The master -> slaves relationship is via tcp/53 (notifies & zone transfers)
> 9. The slaves -> clients relationship is via udp/53 (queries)
> 
> Is this correct so far?

Yup, mostly.

You should probably allow both TCP and UDP between master and slave, and also 
between slaves and clients.
While most of the client <-> slave traffic is UDP, some responses may be too 
big for UDP and fail back to TCP  (especially with DNSSEC, or RRL dos 
protection)


>  I'm being told "our authoritative DNS servers should not receive any 
> queries",

Er, this is where it all goes screwy. Maybe whoever said that actually meant:

1: The hidden master should not receive any queries (which is kinda what you 
said in 6).

2: Authoritative DNS servers should not also be recursive servers. This is a 
best common practice (for security reasons, manageability, etc.)
Maybe he meant "our authoritative DNS servers should not receive any 
***recursive*** queries" -- that's a fairly valid view.

3: A duck (also know as, he's a nut).


> as well as "DNS slaves respond to queries".  These statements seem like a 
> conflict to me, but maybe I'm simply confused?

Or he is...

> 
> 
> 
> I don't see how a slave could respond to a query unless it's authoritative.  
> The only thing I can imagine is adding some more caching servers just for 
> queries and have them forward+recurse to the authoritative slave servers (but 
> they're not slaves themselves).  But even in that case, the authoritative 
> servers would still need to respond to queries, no?  Otherwise how would the 
> caching servers get any answers in the first place?

It sounds like he's muddled. Your slaves are authoritative (actually, DNS 
doesn't really know the difference between master and space), they answer 
queries. I think there is a miscommunication here, or he's just wrong.

W

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

--
There were such things as dwarf gods. Dwarfs were not a naturally religious 
species, but in a world where pit props could crack without warning and pockets 
of fire damp could suddenly explode they'd seen the need for gods as the sort 
of supernatural equivalent of a hard hat. Besides, when you hit your thumb with 
an eight-pound hammer it's nice to be able to blaspheme. It takes a very 
special and straong-minded kind of atheist to jump up and down with their hand 
clasped under their other armpit and shout, "Oh, 
random-fluctuations-in-the-space-time-continuum!" or "Aaargh, 
primitive-and-outmoded-concept on a crutch!"
  -- Terry Pratchett


___
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: Confused about a basic concept

[Carlos M. Martinez]

The 'hidden master' setup is a very good strategy for a number of reasons.

I think the original description only derails a bit when using the term
'authoritative':

> I'm being told "our authoritative DNS
>> servers should not receive any queries", as well as "DNS slaves
>> respond to queries".  These statements seem like a conflict to me,
>> but maybe I'm simply confused?

Many people confuse authority with master/slave. Slaves will also
respond authoritatively. In fact, by just looking at a DNS response is
hard to tell which NS points to the actual master, if any (in the case
of the hidden master, no NS actually points to a master).

cheers!

~Carlos

On 6/5/13 11:18 AM, Ben Croswell wrote:
> Everything you listed is pretty close to accurate.
> A couple points of clarification.
> 
> 8) The master needs UDP/TCP 53 open to the slaves.  Before a zone
> transfer can happen the slave needs to get the SOA RR from the master to
> see if the serial number has changed.  This normally happens over UDP
> 53(see my point on 9).  So The slaves need to also be in the allow-query
> ACL on the master, if they cant query for SOA they can never determine
> the serial number and cant transfer.
> 9) You should always have UDP/TCP 53 open to DNS servers.  "Normal"
> queries happen on UDP 53, but if an answer is too large to fit in a
> single packet the answer will be truncated and the TC bit will be set.
>  This bit tells the client they didnt get the "full" answer and that
> they may want to try the same query via TCP.
> 
> On you last points you are pretty much spot on the answer but are
> wondering the mechanics. Most best practices state that you should not
> have recursion and authoritative on the same DNS server. That is a
> should, but not a must.  What you said is the normal answer you run DNS
> servers that host zones, and you run DNS servers that serve direct
> client queries. The client caching DNS servers would need to know where
> your authoritative servers are via NS records or forwarding.
> 
> One big reason for the split is DNSSEC. An authoritative DNS server cant
> validate DNSSEC for a query sent directly to it from a client.  There
> has to be another step in between.  For instance if I ask you if you are
> Bryan and you say yes, why should I believe you.  However, if I ask a
> trusted friend if you are Bryan I will believe you because there is
> third party verification.
> 
> 
> 
> On Wed, Jun 5, 2013 at 10:02 AM, Bryan Harris  > wrote:
> 
> Hi all,
> 
> I think I may be confused about a very basic DNS concept.  Sorry if
> this has been asked before.
> 
> 1. I have a master and two slaves.
> 2. The master server is the SOA for my zone.  The SOA record points
> to the master server.
> 3. Each of the two slaves are authoritative for my zone.
> 4. There are 2 NS records for my zone.  The first NS = slave1 and
> the second NS = slave2.
> 5. The Master server is not listed in the NS records for my zone.
> 6. The master does not receive any queries from the clients.
> 7. The slaves receive queries from the clients.
> 8. The master -> slaves relationship is via tcp/53 (notifies & zone
> transfers)
> 9. The slaves -> clients relationship is via udp/53 (queries)
> 
> Is this correct so far?  I'm being told "our authoritative DNS
> servers should not receive any queries", as well as "DNS slaves
> respond to queries".  These statements seem like a conflict to me,
> but maybe I'm simply confused?
> 
> 
> I don't see how a slave could respond to a query unless it's
> authoritative.  The only thing I can imagine is adding some more
> caching servers just for queries and have them forward+recurse to
> the authoritative slave servers (but they're not slaves themselves).
>  But even in that case, the authoritative servers would still need
> to respond to queries, no?  Otherwise how would the caching servers
> get any answers in the first place?
> 
> Bryan
> 
> 
> ___
> 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
> 
> 
> 
> 
> -- 
> -Ben Croswell
> 
> 
> ___
> 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: any requests

[Tony Finch]

Leonard Mills  wrote:

> If your some of your clients are SMTP relays, then ANY is the default
> lookup for an MX and is perfectly normal. Much better from the point of
> view of the mail servers to do one lookup instead of several.

You are not quite correct. See http://fanf.livejournal.com/10.html for
details.

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

This list's prefix

[Narcis Garcia]

It's not the only mailing list where I'm subscribed.
Could please the administrator setup a prefix for messages' subject?

For example:
[bind-u]


Thanks.
___
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: This list's prefix

[Mike Hoskins (michoski)]

-Original Message-

From: Narcis Garcia 
Date: Wednesday, June 5, 2013 12:43 PM
To: "bind-users@lists.isc.org" 
Subject: This list's prefix

>It's not the only mailing list where I'm subscribed.
>Could please the administrator setup a prefix for messages' subject?
>
>For example:
>[bind-u]

Or do your own dirty work, and filter yourself.

List-Id: BIND Users Mailing List 


If you are on many mailing lists, folders vs an inbox full of subjects
will be easier to read...

___
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: This list's prefix

[Jeremy C. Reed]

On Wed, 5 Jun 2013, Narcis Garcia wrote:

> It's not the only mailing list where I'm subscribed.
> Could please the administrator setup a prefix for messages' subject?
> 
> For example:
> [bind-u]

Please just have your MUA or your mail filtering client look at the 
following header (and add the subject line prefix as you like):

  List-Id: BIND Users Mailing List 
___
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: This list's prefix

[Phil Mayers]

On 05/06/13 17:43, Narcis Garcia wrote:

It's not the only mailing list where I'm subscribed.
Could please the administrator setup a prefix for messages' subject?


This is getting to be an FAQ. Please read this entire (recent) thread:

https://lists.isc.org/pipermail/bind-users/2013-May/090574.html

...in which is is made clear that people have differing views on both 
Reply-To and subject line tagging. Let's not have that discussion again.

___
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: Confused about a basic concept

[Bryan Harris]

Hi everyone,Thanks for all the detailed responses, I think I have a better understanding of things now.  I was completely and totally confused about UDP/TCP.  I am just going to take a wild guess that doing iptables the way I described would've caused a bunch of problems...After reading everything it looks to me like our hidden master configuration is basically okay, but by some of the best practices described, it could be better and easier to work with if we had a separate caching layer.Also per Ben's description of DNSSEC we are going to need need different servers (caching/recursion servers) validating the DNSSEC keys (or whatever they're called).  I suppose we need to implement the caching layer if we intend to implement DNSSEC for our zone properly.Regarding if we need a hidden master in the first place, I wish I could remember. :-)  It's been that way since I came here and I suspect it's a requirement we will simply have to keep using.Thanks again for all the responses!BryanOn Jun 05, 2013, at 09:36 AM, "Carlos M. Martinez"  wrote:The 'hidden master' setup is a very good strategy for a number of reasons.  I think the original description only derails a bit when using the term 'authoritative':  > I'm being told "our authoritative DNS >> servers should not receive any queries", as well as "DNS slaves >> respond to queries". These statements seem like a conflict to me, >> but maybe I'm simply confused?  Many people confuse authority with master/slave. Slaves will also respond authoritatively. In fact, by just looking at a DNS response is hard to tell which NS points to the actual master, if any (in the case of the hidden master, no NS actually points to a master).  cheers!  ~Carlos  On 6/5/13 11:18 AM, Ben Croswell wrote: > Everything you listed is pretty close to accurate. > A couple points of clarification. >  > 8) The master needs UDP/TCP 53 open to the slaves. Before a zone > transfer can happen the slave needs to get the SOA RR from the master to > see if the serial number has changed. This normally happens over UDP > 53(see my point on 9). So The slaves need to also be in the allow-query > ACL on the master, if they cant query for SOA they can never determine > the serial number and cant transfer. > 9) You should always have UDP/TCP 53 open to DNS servers. "Normal" > queries happen on UDP 53, but if an answer is too large to fit in a > single packet the answer will be truncated and the TC bit will be set. > This bit tells the client they didnt get the "full" answer and that > they may want to try the same query via TCP. >  > On you last points you are pretty much spot on the answer but are > wondering the mechanics. Most best practices state that you should not > have recursion and authoritative on the same DNS server. That is a > should, but not a must. What you said is the normal answer you run DNS > servers that host zones, and you run DNS servers that serve direct > client queries. The client caching DNS servers would need to know where > your authoritative servers are via NS records or forwarding. >  > One big reason for the split is DNSSEC. An authoritative DNS server cant > validate DNSSEC for a query sent directly to it from a client. There > has to be another step in between. For instance if I ask you if you are > Bryan and you say yes, why should I believe you. However, if I ask a > trusted friend if you are Bryan I will believe you because there is > third party verification. >  >  >  > On Wed, Jun 5, 2013 at 10:02 AM, Bryan Harris  bryanlhar...@me.com>> wrote: >  > Hi all, >  > I think I may be confused about a very basic DNS concept. Sorry if > this has been asked before. >  > 1. I have a master and two slaves. > 2. The master server is the SOA for my zone. The SOA record points > to the master server. > 3. Each of the two slaves are authoritative for my zone. > 4. There are 2 NS records for my zone. The first NS = slave1 and > the second NS = slave2. > 5. The Master server is not listed in the NS records for my zone. > 6. The master does not receive any queries from the clients. > 7. The slaves receive queries from the clients. > 8. The master -> slaves relationship is via tcp/53 (notifies & zone > transfers) > 9. The slaves -> clients relationship is via udp/53 (queries) >  > Is this correct so far? I'm being told "our authoritative DNS > servers should not receive any queries", as well as "DNS slaves > respond to queries". These statements seem like a conflict to me, > but maybe I'm simply confused? >  >  > I don't see how a slave could respond to a query unless it's > authoritative. The only thing I can imagine is adding some more > caching servers just for queries and have them forward+recurse to > the authoritative slave servers (but they're not slaves themselves). > But even in that case, the authoritative servers would still need > to respond to queries, no? Otherwise how would the caching servers > get any answers in the first place? >  > Bryan >  >  > _

Re: This list's prefix

[Narcis Garcia]

Somebody has answered me privately and didn't realized until I've
checked all details of each message. I've been near to respond to the
list about that message, unknown for the whole list.

There are some Mailman's features that help a lot to usability for
users, both subject prefix and Reply-To list.
It's a small step for the single administrator, and a big+multiple steps
for the rest of people.


Al 05/06/13 18:54, En/na Phil Mayers ha escrit:
> On 05/06/13 17:43, Narcis Garcia wrote:
>> It's not the only mailing list where I'm subscribed.
>> Could please the administrator setup a prefix for messages' subject?
> 
> This is getting to be an FAQ. Please read this entire (recent) thread:
> 
> https://lists.isc.org/pipermail/bind-users/2013-May/090574.html
> 
> ...in which is is made clear that people have differing views on both
> Reply-To and subject line tagging. Let's not have that discussion again.
> ___
> 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: This list's prefix

[Mike Hoskins (michoski)]

-Original Message-

From: Narcis Garcia 
Date: Wednesday, June 5, 2013 1:02 PM
To: "bind-users@lists.isc.org" 
Subject: Re: This list's prefix

>Somebody has answered me privately and didn't realized until I've
>checked all details of each message. I've been near to respond to the
>list about that message, unknown for the whole list.
>
>There are some Mailman's features that help a lot to usability for
>users, both subject prefix and Reply-To list.
>It's a small step for the single administrator, and a big+multiple steps
>for the rest of people.

I'm fairly certain the list maintainers understand Mailman's features, and
probably have understood similar features since before Mailman existed
(majordomo *gasp*).  That said, we're debating a personal preference.
Opinions are like...  for those who don't want the default behavior, you
can do whatever you prefer (support yourself vs relying on others -- it's
not a hard task to setup filters).  Others are fine with it.  Life goes on.

___
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: Confused about a basic concept

[SM]

Hi Bryan,
At 09:52 05-06-2013, Bryan Harris wrote:
Regarding if we need a hidden master in the first place, I wish I 
could remember. :-)  It's been that way since I came here and I 
suspect it's a requirement we will simply have to keep using.


Sometimes it is better to ask or else you can end up with problematic 
requirements.


Regards,
-sm 


___
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: any requests

[Vernon Schryver]

> From: Tony Finch 

> You are not quite correct. See http://fanf.livejournal.com/10.html for
> details.

It is obvious to anyone willing to spend a few seconds experimenting that 
is true of current BIND9 code (and as far as I know old versions):

}  If a DNS cache already has any records (usually an A record) for
}  a domain, an ANY query won't make its resolver fetch the other types


However, it is also obvious to anyone to spend almost as little time
that is not true about Google, OpenDNS, and some intentionally other
open DNS resolvers.

If you have a domain to which you can can add records for a subdomain
with differing 5-30 second TTLs and can spend not just 5 seconds but
a few minutes playing around, you might come to my conclusion.  I think
they treat ANY as if it were psuedo-rdataset containing some of the
RRs for the domain with a TTL equal to the minimum of all of the TTLs
of the contained rdatasets.  (I thought I sometimes get only some of
the record types for my Christmas tree test domain from 8.8.8.8, but
now I seem to always get all of them.)

That means that if
  - you assume (in my view unwisely) that those open DNS resolvers
  won't change how they handle ANY
  - your SMTP client (mail sender) uses one of those DNS resolvers,
then it can get the MX, A, and  records (or their absences) with
a single ANY request.  

5 years ago that might have been a good hack, because it would reduce
the number of DNS round trips for SMTP clients.  In the future it won't
be a good hack and probably is not good today, because the ANY
psuedo-rdataset can be enormous and can require the truncated-UDP/TCP-retry
dance as well as the CPU costs of parsing and discarding almost all
of a giant response.  When you ask for ANY, you should not only get
MX, A, and , but also TXT, SRV, SPF, DNSKEY, and any others as
well as RRSIGs for everything.


Vernon Schryverv...@rhyolite.com
___
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: This list's prefix

[Warren Kumari]

On Jun 5, 2013, at 11:43 AM, Narcis Garcia  wrote:

> It's not the only mailing list where I'm subscribed.
> Could please the administrator setup a prefix for messages' subject?

You have unwittingly walked into a religious argument.

If, like me, you really like list prefixes,  *and* you use procmial, you can 
add them yourself:

# Add an [6MAN] to messages to the "IPv6 Maintenance Working Group \(6man\)" 

:0 fw
* ^List-Id:[ ].*\
|/bin/sed -e 's/^Subject:[ ]*/Subject: [6MAN] /'

Nice to meet another member of the Church of Prefixes. We meet on Saturdays, 
and wear tricorn hats. Sure, folk laugh at the hats, but at least it draws 
attention away from our list prefix kink.

Warren

> 
> For example:
> [bind-u]
> 
> 
> Thanks.
> ___
> 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
> 

--
Curse the dark, or light a match. You decide, it's your dark.
-- Valdis Kletnieks


___
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: This list's prefix

[Carlos M. Martinez]

That's a neat trick, thanks Warren! I also do like prefixes, BTW (as can
be seen in the other thread referenced).

cheers!

~Carlos


On 6/5/13 2:46 PM, Warren Kumari wrote:
> 
> On Jun 5, 2013, at 11:43 AM, Narcis Garcia  wrote:
> 
>> It's not the only mailing list where I'm subscribed.
>> Could please the administrator setup a prefix for messages' subject?
> 
> You have unwittingly walked into a religious argument.
> 
> If, like me, you really like list prefixes,  *and* you use procmial, you can 
> add them yourself:
> 
> # Add an [6MAN] to messages to the "IPv6 Maintenance Working Group \(6man\)" 
> 
> :0 fw
> * ^List-Id:[ ].*\
> |/bin/sed -e 's/^Subject:[ ]*/Subject: [6MAN] /'
> 
> Nice to meet another member of the Church of Prefixes. We meet on Saturdays, 
> and wear tricorn hats. Sure, folk laugh at the hats, but at least it draws 
> attention away from our list prefix kink.
> 
> Warren
> 
>>
>> For example:
>> [bind-u]
>>
>>
>> Thanks.
>> ___
>> 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
>>
> 
> --
> Curse the dark, or light a match. You decide, it's your dark.
> -- Valdis Kletnieks
> 
> 
> ___
> 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: This list's prefix

[Mike Hoskins (michoski)]

-Original Message-

From: Warren Kumari 
Date: Wednesday, June 5, 2013 1:46 PM
To: Narcis Garcia 
Cc: "bind-users@lists.isc.org" 
Subject: Re: This list's prefix

>--
>Curse the dark, or light a match. You decide, it's your dark.
>-- Valdis Kletnieks

Very appropriate!

___
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: Confused about a basic concept

[Tony Finch]

Bryan Harris  wrote:
>
> After reading everything it looks to me like our hidden master configuration
> is basically okay, but by some of the best practices described, it could be
> better and easier to work with if we had a separate caching layer.

Note that the caches live on the client side of DNS. The authority server
side is cacheless - it uses replication (slaving) rather than caches. In
particular you should not point an NS record at a recursive cache server.
DNS authority servers are usually much faster than recursive caches.

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

[Tony Finch]

Vernon Schryver  wrote:
>
> If you have a domain to which you can can add records for a subdomain
> with differing 5-30 second TTLs and can spend not just 5 seconds but
> a few minutes playing around, you might come to my conclusion.  I think
> they treat ANY as if it were psuedo-rdataset containing some of the
> RRs for the domain with a TTL equal to the minimum of all of the TTLs
> of the contained rdatasets.  (I thought I sometimes get only some of
> the record types for my Christmas tree test domain from 8.8.8.8, but
> now I seem to always get all of them.)

I thought Google Public DNS re-fetched RRsets as they were expiring in
order to keep the cache populated, which would explain what you see, but
they don't mention it on
https://developers.google.com/speed/public-dns/docs/performance

> 5 years ago that might have been a good hack,

I believe the ANY hack on mail servers was a Sendmailism 20ish years ago.
It was a bad hack then and it has remained a bad hack :-)

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

[Doug Barton]

On 06/05/2013 11:33 AM, Tony Finch wrote:

I believe the ANY hack on mail servers was a Sendmailism 20ish years ago.


s/Send/q/


___
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: any requests

[Chris Buxton]

On Jun 5, 2013, at 11:59 AM, Doug Barton  wrote:
> On 06/05/2013 11:33 AM, Tony Finch wrote:
>> I believe the ANY hack on mail servers was a Sendmailism 20ish years ago.
> 
> s/Send/q/

That makes even more sense. DJB always thinks he knows best.
___
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: any requests

[Vernon Schryver]

> From: Tony Finch 

> > a few minutes playing around, you might come to my conclusion.  I think
> > they treat ANY as if it were psuedo-rdataset containing some of the
> > RRs for the domain with a TTL equal to the minimum of all of the TTLs
> > of the contained rdatasets.  (I thought I sometimes get only some of

> I thought Google Public DNS re-fetched RRsets as they were expiring in
> order to keep the cache populated, which would explain what you see, 

I don't understand how they could pre-fetch the gazillions of RRsets
that are rarely requested.  It certainly doesn't explain what I see
in DNS queries and responses and in my server logs with a test domain
with a dozen fat RRsets with TTLs ranging from 5 to 65 seconds.
(They started SERVFAILing when I added the last RRset; I don't know whether
they don't like bogus DNSKEYs, I tested too much, or I hit a size limit.)

I'd be happy to disclose my test domain name in private mail, but that
wouldn't get my server logs.  Only one of us could play with it at a
time.  You could add to a zone of your own and start testing faster
than I could answer private mail.


> It was a bad hack then and it has remained a bad hack :-)

I would not agree if you could rely on the open resolvers continuing
to do what they're doing, if you didn't care about parsing 3 or 4
KBytes of irrelevant bits to get the RRsets you want, and if you don't
care about spending 9 or 10 IP packets on a truncated UDP responce and
then a full TCP response instead of 6 on 3 separate queries.

With BIND as your DNS server, it could be a win for bursts of mail to
a single SMTP server if your SMTP client is too dumb to do the obvious,
safe caching.  At worst you would need to ask for ANY, MX, A, and ,
but some of the time the ANY would have all of the RRsets.

However, in both cases, the proverb applies.
"If wishes were horses, beggars would ride"


Vernon Schryverv...@rhyolite.com
___
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: This list's prefix

[Elmar K. Bins]

war...@kumari.net (Warren Kumari) wrote:

> If, like me, you really like list prefixes,  *and* you use procmial, you can 
> add them yourself:

[...]

And the 100-dollar-question is: How do you remove them on outgoing mails? ;-)

Elmar.

PS: But thank you for the adding recipe already.
___
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: This list's prefix

[Warren Kumari]

Warren Kumari
--
Please excuse typing, etc -- This was sent from a device with a tiny keyboard.

On Jun 5, 2013, at 2:27 PM, "Elmar K. Bins"  wrote:

> war...@kumari.net (Warren Kumari) wrote:
> 
>> If, like me, you really like list prefixes,  *and* you use procmial, you can 
>> add them yourself:
> 
> [...]
> 
> And the 100-dollar-question is: How do you remove them on outgoing mails? ;-)
> 

You don't -- that's part of the churches evangelism / outreach effort.

(Less flip answer: sorry, don't know if you can...)

W


> Elmar.
> 
> PS: But thank you for the adding recipe already.
> ___
> 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: This list's prefix

[Elmar K. Bins]

war...@kumari.net (Warren Kumari) wrote:

> > And the 100-dollar-question is: How do you remove them on outgoing mails? 
> > ;-)
> You don't -- that's part of the churches evangelism / outreach effort.

;)


> (Less flip answer: sorry, don't know if you can...)

Just wondering, because your responses arrive without them.


___
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: This list's prefix

[SM]

Hi Elmar,
At 12:27 05-06-2013, Elmar K. Bins wrote:

And the 100-dollar-question is: How do you remove them on outgoing mails? ;-)


The answer is to edit the subject line after hitting the reply button. :-)

Regards,
-sm 


___
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: This list's prefix

[Novosielski, Ryan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/05/2013 03:47 PM, Elmar K. Bins wrote:
> war...@kumari.net (Warren Kumari) wrote:
> 
>>> And the 100-dollar-question is: How do you remove them on
>>> outgoing mails? ;-)
>> You don't -- that's part of the churches evangelism / outreach
>> effort.
> 
> ;)
> 
> 
>> (Less flip answer: sorry, don't know if you can...)
> 
> Just wondering, because your responses arrive without them.

My guess is that the personal e-mail directed at you in a reply-all
situation will not have them and the e-mail sent via the list (if the
list has them turned on) will whether you like it or not.

- -- 
-  _  _ _  _ ___  _  _  _
|Y#| |  | |\/| |  \ |\ |  | |Ryan Novosielski - Sr. Systems Programmer
|$&| |__| |  | |__/ | \| _| |novos...@umdnj.edu - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGvnlUACgkQmb+gadEcsb6OgACgpfcPhAsNnsW19OYl9D9S1aCE
b5IAoK7/GnTk3Sk2Xy4IABPyHIa+uZBW
=zFiJ
-END PGP SIGNATURE-

___
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: does zone trump forward?

[Dave Warren]

On 2013-06-04 06:42, Alan Shackelford wrote:
We have 2843 authoritative zones. We run a split brain DNS. The new 
hospitals and other entities need to see our internal zone view once 
they have "joined". So I have them forward queries during the early 
stages of the merger, until I can get control of their DNS and make 
appropriate changes. There are fatherhood issues and all manner of ego 
problems involved in absorbing someone else's DNS. This step provides 
a workable solution in the very first stages. Then I make them slaves, 
with a reasonable expire time, to give them a copy of the data locally.


To me, it sounds like changing these steps by moving directly to using 
slave zones would fix the issue, no? Is there any particular need to 
start with forwarding rather slaving right from the start?


I realize there are egos, but "Connect our network to yours" includes 
things like routing and DNS. You're not taking over their territory just 
yet, just adding yours to theirs.


Politics aside, it solves the technical issues without butchering DNS or 
adding excessive unreliability.


But then I just hate forwards. Burned 1000x times, lesson learned :)

--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

___
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: does zone trump forward?

[Jonathan Reed]

>
> But then I just hate forwards. Burned 1000x times, lesson learned :)


What are you referring to? Why are forwards such a bad idea?


On Wed, Jun 5, 2013 at 4:54 PM, Dave Warren  wrote:

>  On 2013-06-04 06:42, Alan Shackelford wrote:
>
> We have 2843 authoritative zones. We run a split brain DNS. The new
> hospitals and other entities need to see our internal zone view once they
> have “joined”. So I have them forward queries during the early stages of
> the merger, until I can get control of their DNS and make appropriate
> changes. There are fatherhood issues and all manner of ego problems
> involved in absorbing someone else’s DNS. This step provides a workable
> solution in the very first stages. Then I make them slaves, with a
> reasonable expire time, to give them a copy of the data locally.
>
>
> To me, it sounds like changing these steps by moving directly to using
> slave zones would fix the issue, no? Is there any particular need to start
> with forwarding rather slaving right from the start?
>
> I realize there are egos, but "Connect our network to yours" includes
> things like routing and DNS. You're not taking over their territory just
> yet, just adding yours to theirs.
>
> Politics aside, it solves the technical issues without butchering DNS or
> adding excessive unreliability.
>
> But then I just hate forwards. Burned 1000x times, lesson learned :)
>
> --
> Dave Warrenhttp://www.hireahit.com/http://ca.linkedin.com/in/davejwarren
>
>
> ___
> 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: does zone trump forward?

[Dave Warren]

On 2013-06-05 14:27, Jonathan Reed wrote:


But then I just hate forwards. Burned 1000x times, lesson learned :)


What are you referring to? Why are forwards such a bad idea?



They're not automatically a bad idea, but I always prefer having a local 
copy of a zone unless that's not practical.


A couple real world example that I bang my head against daily/weekly:

1) I do some contract work out of a satellite office where we have a 
full time site-to-site VPN to HQ, and as a result, I've forwarded their 
domains to their internal NS over the VPN. Works great, except that when 
the VPN is down, I can't reach their externally hosted resources (which 
don't need the VPN, but do need DNS to work)


2) Even when it works, their office is 200-400ms (or about 16 hours 
door-to-door, including flight times) away from me. The internal DNS 
uses very short TTLs. This means I've got a 200-400ms wait time to 
access their public website (which is CDN hosted and otherwise very 
responsive) to hit the homepage, then a few more 200-400ms waits for 
other resources to start to load, and I do it every $small-TTL seconds 
while I browse their site looking for something because the cache 
expires quickly.


I've never seen a case where slaves are less reliable than forwards, but 
forwards are often less reliable than slaves. When a slave is not 
realistic or practical, forwards get the job done.


Keeping this thread in mind, the situation is a remote office where the 
pipe is neither fat nor reliable. See #1 and #2 above.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

___
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: Confused about a basic concept

[btb]

On 2013.06.05 10.02, Bryan Harris wrote:
> Hi all,
> 
> I think I may be confused about a very basic DNS concept.  Sorry if this has
> been asked before.
> 
> 1. I have a master and two slaves.
> 2. The master server is the SOA for my zone.  The SOA record points to the
> master server.
> 3. Each of the two slaves are authoritative for my zone.
> 4. There are 2 NS records for my zone.  The first NS = slave1 and the second 
> NS
> = slave2.
> 5. The Master server is not listed in the NS records for my zone.
> 6. The master does not receive any queries from the clients.
> 7. The slaves receive queries from the clients.
> 8. The master -> slaves relationship is via tcp/53 (notifies & zone transfers)
> 9. The slaves -> clients relationship is via udp/53 (queries)
> 
> Is this correct so far?  I'm being told "our authoritative DNS servers should
> not receive any queries", as well as "DNS slaves respond to queries".  These
> statements seem like a conflict to me, but maybe I'm simply confused?

whoever said "our authoritative DNS servers should not receive any queries" is 
the confused one, not you.

master/slave has nothing to do with authoritative or not.  the master/slave 
mechanism/relationship is simply one [common] choice for duplicating zone data 
amongst servers, using an "in-band" mechanism.  what makes a nameserver 
authoritative for a zone is if it publishes zone data for that zone. where it 
gets the data it publishes [e.g. from a file, from a database, from some other 
server] has no bearing on that.  in concert with publishing the zone data, to 
be truly accepted as authoritative, the nameservers must of course be listed in 
the zone's ns records as well [and in the parent's delegation], but that's a 
bit of a digression.

what you describe above is typically referred as a "hidden master" 
configuration, and is occasionally used, but is by no means the norm, and 
certainly not any sort of technical requirement in the least.  while there are 
arguably "appropriate" environments/applications for a hidden master, the 
reality is that most people i've encountered using a hidden master don't need 
it, and when pressed, it becomes clear they're doing it because they think that 
the complexity of the implementation directly correlates to their technical 
prowess.  but then, i'm a cynical jerk :)

also, on another note, master/slave relationships are not exclusively tcp, and 
client/server [be it master or slave] are not exclusively udp.  dns uses port 
53, period.  that means both udp and tcp.

> I don't see how a slave could respond to a query unless it's authoritative.  
> The
> only thing I can imagine is adding some more caching servers just for queries
> and have them forward+recurse to the authoritative slave servers (but they're
> not slaves themselves).  But even in that case, the authoritative servers 
> would
> still need to respond to queries, no?  Otherwise how would the caching servers
> get any answers in the first place?

any server can respond to any query.  it just won't be an authoritative 
response unless that server has loaded/is publishing the zone data.  if you put 
caching nameservers in between the internet and your "actual" nameservers, then 
your zone would be plain and simple broken, because the nameservers answering 
queries for everyone on the internet would not be answering authoritatively 
[and yes, they'd still have to get those answers from the "actual" nameservers 
anyway].

-ben
___
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: any requests

[Dave Warren]

On 2013-06-05 12:28, Vernon Schryver wrote:

I thought Google Public DNS re-fetched RRsets as they were expiring in
>order to keep the cache populated, which would explain what you see,

I don't understand how they could pre-fetch the gazillions of RRsets
that are rarely requested.



As far as I recall from some documents they published when they first 
came out, they do so for some percentage of the top domains by number of 
queries, not necessarily every domain that exists.


If you figure that keeping 10% of the data that passes through their 
caches each day current probably covers 80%-90% of DNS queries, and they 
only pre-fetch when the current TTL is getting close to expiry, it 
probably does get their average latency between query and response time 
down.


I'm not convinced they really bother with any of that though, I wonder 
if they don't just have giant shared caches on powerful, well connected 
boxes.


Either way, when you're playing with a single test domain, 
experimentally, they'll absolutely expire just the way anybody else does.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

___
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

[Off-Topic] RE: This list's prefix

[Stuart Browne]

> -Original Message-
> From: bind-users-bounces+stuart.browne=ausregistry.com...@lists.isc.org
> [mailto:bind-users-bounces+stuart.browne=ausregistry.com...@lists.isc.org]
> On Behalf Of Elmar K. Bins
> Sent: Thursday, 6 June 2013 5:46 AM
> To: bind-users@lists.isc.org
> Subject: Re: This list's prefix
> 
> war...@kumari.net (Warren Kumari) wrote:
> 
> > > And the 100-dollar-question is: How do you remove them on outgoing
> mails? ;-)
> > You don't -- that's part of the churches evangelism / outreach effort.
> 
> ;)
> 
> 
> > (Less flip answer: sorry, don't know if you can...)
> 
> Just wondering, because your responses arrive without them.

If you run your own SMTP gateway that supports milters, have-at-it.  Not overly 
difficult, plenty of C and perl examples out there.

Stuart
___
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: Confused about a basic concept

[Mark Andrews]

In message <05883710-136f-4dc2-8079-e29a68fed...@me.com>, Bryan Harris writes:
> Hi everyone,
>
> Thanks for all the detailed responses, I think I have a better
> understanding of things now.  I was completely and totally confused about
> UDP/TCP.  I am just going to take a wild guess that doing iptables the
> way I described would've caused a bunch of problems...

DNS uses both UDP and TCP for every relationship (server<->server
and client<->server).  You don't need to know when, you just need
to leave both transport protocols open to avoid problems.

If you have a auditor or a security "expert" tell you to turn off
TCP for DNS then it is a sure sign that they are incompentent.

Similarly DNS uses fragmented UDP packets.  You need to pass these
through your firewall.

Similarly DNS UDP messages can be bigger than 512 bytes (named does
up to 4046 byte payload UDP packets).

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

Re: any requests

[Vernon Schryver]

> From: Dave Warren 

> >> I thought Google Public DNS re-fetched RRsets as they were expiring in
> >> >order to keep the cache populated, which would explain what you see,

> > I don't understand how they could pre-fetch the gazillions of RRsets
> > that are rarely requested.

> ...
> I'm not convinced they really bother with any of that though, I wonder 
> if they don't just have giant shared caches on powerful, well connected 
> boxes.

I don't know about "shared," but there's no doubt about the rest of that.


> Either way, when you're playing with a single test domain, 
> experimentally, they'll absolutely expire just the way anybody else does.

If I were doing what I might understand them to be doing, and if I
were obsessed with initial page loading speed, then I might play an
easy game with TTLs and extra recursing.
When the remaining TTL of an RRset is positive but small,
answer the DNS request from the cache as usual but also start fetching.
When the remaining TTL is large or <=0, do the usual things.
That would keep popular RRsets in the cache without having needing
to decide explicitly which domains are popular today or for a
particular instance of the recursive server.
If "positive but small" were a small multiple of the RTT to the authority
(including the authority's queue and processing time), such as a constant
0.75 or 1.0 seconds for all RRsets everywhere,
then its ratio to the original TTL would prevent more than 1% on
average of the pre-emptive fetches from being wasted.

It sounds hard to see whether they are playing that sort of game from
outside.  On the other hand, I think too many of the records in their
responses to my ANY requests for my test domain have TTLs of 0.

I think it would not be too hard to hack that early recursion into
BIND, and so perhaps other DNS implementations.  Making an ANY
psuedo-RRset sounds messy, because of maintaining its TTL as the minimum
of the TTLs of the RRsets at the node even as non-ANY requests refresh
individividual RRsets.

The point of all of this that is not mere gossip is:
  - Don't just assume that ANY requests are useless.
  - Don't just assume that no applications have used, use them now, or 
 will use them in the future.
  - Don't just assume all DNS servers treat ANY requests the same.
  - Don't just assume that no significant DNS servers respond to them in
 any way that is not explicitly outlawed by a standards track RFC.
 And you might need to deal with some outlawed responses.

ANY requests are like the SMTP <> sender, missued and abused by attackers
and filtered by operators based on dubious assumptions.
Filtering ANY is not as bad is blocking all ICMP or blocking TCP/53,
but it comes from the same school of security "expertise."


Vernon Schryverv...@rhyolite.com
___
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: [Off-Topic] RE: This list's prefix

[Narcis Garcia]

Not everyone has the same software infrastructure, and not everyone has
the same visual proficiency. For this reason a Subject Prefix helps on
manage much messages on inbox.

I don't understand why the Subject Prefix can be inconvenient for
someone, if it's brief.


Al 06/06/13 01:11, En/na Stuart Browne ha escrit:
>> -Original Message-
>> From: bind-users-bounces+stuart.browne=ausregistry.com...@lists.isc.org
>> [mailto:bind-users-bounces+stuart.browne=ausregistry.com...@lists.isc.org]
>> On Behalf Of Elmar K. Bins
>> Sent: Thursday, 6 June 2013 5:46 AM
>> To: bind-users@lists.isc.org
>> Subject: Re: This list's prefix
>>
>> war...@kumari.net (Warren Kumari) wrote:
>>
 And the 100-dollar-question is: How do you remove them on outgoing
>> mails? ;-)
>>> You don't -- that's part of the churches evangelism / outreach effort.
>>
>> ;)
>>
>>
>>> (Less flip answer: sorry, don't know if you can...)
>>
>> Just wondering, because your responses arrive without them.
> 
> If you run your own SMTP gateway that supports milters, have-at-it.  Not 
> overly difficult, plenty of C and perl examples out there.
> 
> Stuart
> ___
> 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