Re: Reverse address entries

[Sam Wilson]

In article ,
 Charles Swiger  wrote:

> On Jun 28, 2013, at 10:54 AM, "Ward, Mike S"  wrote:
> > Hello all, is there any reason to setup reverse address entries for a zone?
> 
> Certainly.  Various software performs what's called a double-reverse lookup
> to confirm that the A and PTR records match.

Isn't that paranoid reverse lookup?  Since reverse lookups can be faked 
(I'll spare the details here) some uses of in-addr.arpa also require a 
subsequent forward lookup.  If there is no PTR record then the double 
lookup doesn't happen.  I don't know of anything to be gained by 
requiring a reverse lookup after a forward lookup.

> > I have asked some of the admins here and the consensus from them is that 
> > only A records are necessary. Is this true?
> 
> I suppose that depends on how wide (or limited) one's view of "necessary" is.
> 
> Many mail systems choose not to grant much trust towards IPs without good 
> DNS.
> Java's SSL on some platform performs a double-reverse check and declines to 
> proceed if there is a mismatch.

It's nice for humans too.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Reverse address entries

[Matus UHLAR - fantomas]

On Jun 28, 2013, at 10:54 AM, "Ward, Mike S"  wrote:
> Hello all, is there any reason to setup reverse address entries for a zone?



In article ,
Charles Swiger  wrote:

Certainly.  Various software performs what's called a double-reverse lookup
to confirm that the A and PTR records match.


On 01.07.13 10:48, Sam Wilson wrote:

Isn't that paranoid reverse lookup?  Since reverse lookups can be faked
(I'll spare the details here) some uses of in-addr.arpa also require a
subsequent forward lookup.  If there is no PTR record then the double
lookup doesn't happen.  I don't know of anything to be gained by
requiring a reverse lookup after a forward lookup.


He apparently meant exactly the same. Also calles FcRDNS - "forward
confirmed" or "full circle" reverse DNS.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
LSD will make your ECS screen display 16.7 million colors
___
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: How to suppress ADDITIONAL SECTION per zone

[blrmaani]

We are noticing that a handful of our domains are being used for amplification 
attacks and we would like to reduce outgoing (DNS response) packet size. 

One solution is to reduce the additional sections in the response for these 
handful zones and I would like to know if there is any way to add something 
similar to "additional-from-auth no" per zone basis and achieve what I want.


On Monday, June 24, 2013 1:13:24 AM UTC-7, Steven Carr wrote:
> On 24 June 2013 08:14, Matus UHLAR - fantomas  wrote:
> 
> > You still have not answered my question, so I repeat it:
> 
> >
> 
> >>> > What is the point of your question?
> 
> >
> 
> 
> 
> I think what Matus wants to know is your reasoning/problem/issue about
> 
> not returning records from the cache for those zones?
> 
> 
> 
> The answer is no you can't restrict it to zones only to global or a
> 
> view, but if you can give us some more information on what/why then we
> 
> may be able to help come up with some other solution that would help.
> 
> 
> 
> Steve
___
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

Discover Unreferenced Zones/Records

[Bryan Harris]

Hi all,I have discovered that we have an excessive amount of old zones not being used.  Is there a trick, or a simple way to determine which zones have not been referenced in a long time?My best guess is to simply log queries and read the log files.  Would that be the recommended way?Our intent is to delete everything we don't need.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: How to suppress ADDITIONAL SECTION per zone

[Steven Carr]

If these are authoritative DNS servers then just enable
minimal-responses, so clients will only ever get the records that they
requested.

Steve

On 1 July 2013 12:02, blrmaani  wrote:
> We are noticing that a handful of our domains are being used for 
> amplification attacks and we would like to reduce outgoing (DNS response) 
> packet size.
>
> One solution is to reduce the additional sections in the response for these 
> handful zones and I would like to know if there is any way to add something 
> similar to "additional-from-auth no" per zone basis and achieve what I want.
>
>
> On Monday, June 24, 2013 1:13:24 AM UTC-7, Steven Carr wrote:
>> On 24 June 2013 08:14, Matus UHLAR - fantomas  wrote:
>>
>> > You still have not answered my question, so I repeat it:
>>
>> >
>>
>> >>> > What is the point of your question?
>>
>> >
>>
>>
>>
>> I think what Matus wants to know is your reasoning/problem/issue about
>>
>> not returning records from the cache for those zones?
>>
>>
>>
>> The answer is no you can't restrict it to zones only to global or a
>>
>> view, but if you can give us some more information on what/why then we
>>
>> may be able to help come up with some other solution that would help.
>>
>>
>>
>> Steve
> ___
> 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: Discover Unreferenced Zones/Records

[Sten Carlsen]

There might be some zones that are rarely used, you may see those as
dead using that method.

I was thinking of a script that would take your list of zones
(essentially the .conf file) and for each zone do something like a "dig
+trace" and look for whether your servers are listed as name servers for
that zone.

Those you are no longer listed in can be removed immediately, those
where you are listed but has no or very little traffic, you can make
inquiries about and act accordiingly.

Just my 0.02EUR

On 01/07/13 13:04, Bryan Harris wrote:
> Hi all,
>
> I have discovered that we have an excessive amount of old zones not
> being used.  Is there a trick, or a simple way to determine which
> zones have not been referenced in a long time?
>
> My best guess is to simply log queries and read the log files.  Would
> that be the recommended way?
>
> Our intent is to delete everything we don't need.
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
   "MALE BOVINE MANURE!!!"

___
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: Discover Unreferenced Zones/Records

[Tony Finch]

Bryan Harris  wrote:
>
> I have discovered that we have an excessive amount of old zones not being
> used.  Is there a trick, or a simple way to determine which zones have not
> been referenced in a long time?

BIND can keep per-zone counts of response codes (success, various kinds of
failure, etc.).

ftp://ftp.isc.org/isc/bind9/9.9.3-P1/doc/arm/Bv9ARM.ch06.html#statistics

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: Discover Unreferenced Zones/Records

[Bryan Harris]

Hi Tony,On Jul 01, 2013, at 06:19 AM, Tony Finch  wrote:Bryan Harris  wrote: > > I have discovered that we have an excessive amount of old zones not being > used.  Is there a trick, or a simple way to determine which zones have not > been referenced in a long time?  BIND can keep per-zone counts of response codes (success, various kinds of failure, etc.).  ftp://ftp.isc.org/isc/bind9/9.9.3-P1/doc/arm/Bv9ARM.ch06.html#statistics I think this is just what we are looking for.  Thanks for your help.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: How to suppress ADDITIONAL SECTION per zone

[Phil Mayers]

On 01/07/13 12:02, blrmaani wrote:

We are noticing that a handful of our domains are being used for
amplification attacks and we would like to reduce outgoing (DNS
response) packet size.

One solution is to reduce the additional sections in the response for
these handful zones and I would like to know if there is any way to
add something similar to "additional-from-auth no" per zone basis and
achieve what I want.


Well, the bind ARM contains all valid per-zone options. If you look at 
it, you'll see there are no per-zone options to control response 
content. So no, sorry, you can't do this. You'll need to do it globally, 
or use RRL patches (or both).

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Reverse address entries

[Sam Wilson]

In article ,
 Matus UHLAR - fantomas  wrote:

> >> On Jun 28, 2013, at 10:54 AM, "Ward, Mike S"  wrote:
> >> > Hello all, is there any reason to setup reverse address entries for a 
> >> > zone?
> 
> >In article ,
> > Charles Swiger  wrote:
> >> Certainly.  Various software performs what's called a double-reverse 
> >> lookup
> >> to confirm that the A and PTR records match.
> 
> On 01.07.13 10:48, Sam Wilson wrote:
> >Isn't that paranoid reverse lookup?  Since reverse lookups can be faked
> >(I'll spare the details here) some uses of in-addr.arpa also require a
> >subsequent forward lookup.  If there is no PTR record then the double
> >lookup doesn't happen.  I don't know of anything to be gained by
> >requiring a reverse lookup after a forward lookup.
> 
> He apparently meant exactly the same. Also calles FcRDNS - "forward
> confirmed" or "full circle" reverse DNS.

OK.  So what Mr. Swiger refers to is not relevant - it's no reason to 
add PTR records.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Reverse address entries

[Matus UHLAR - fantomas]

>In article ,
> Charles Swiger  wrote:
>> Certainly.  Various software performs what's called a double-reverse
>> lookup
>> to confirm that the A and PTR records match.



In article ,
Matus UHLAR - fantomas  wrote:

He apparently meant exactly the same. Also calles FcRDNS - "forward
confirmed" or "full circle" reverse DNS.


On 01.07.13 14:11, Sam Wilson wrote:

OK.  So what Mr. Swiger refers to is not relevant - it's no reason to
add PTR records.


Yes, it is.

"Various software performs what's called a double-reverse lookup to confirm
that the A and PTR records match."

It means that various software checks your PTR and then A (or maybe
) records, and can fail if eny of them is not found ot rhe latter result
doesn't match the original IP address.

Now that IS a reason to add PTR for IP address, and they must point to
hostnames that point to the same IP.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Christian Science Programming: "Let God Debug It!".
___
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: How to suppress ADDITIONAL SECTION per zone

[Matus UHLAR - fantomas]

On 01.07.13 04:02, blrmaani wrote:

We are noticing that a handful of our domains are being used for
amplification attacks and we would like to reduce outgoing (DNS response)
packet size.

One solution is to reduce the additional sections in the response for these
handful zones and I would like to know if there is any way to add
something similar to "additional-from-auth no" per zone basis and achieve


It would be much better if you presented your problem in the beginning, not
just tell us what you want to do. 


In this case you should set "minimal-responses yes" globally, otherwise all
your other domains can get used for such attacks too.

Do you have separate servers for resolving and for domains?
Resolving servers could send all possible info to your own clients, while
authoritative servers would provide as low informations as needed.

Other possibility is to implement packet rate limiting - a patch was
discussed here a few days/weeks ago.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
(R)etry, (A)bort, (C)ancer
___
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