Re: dig -- only RRSIG present.

[Phil Mayers]

On 13/02/12 12:28, dE . wrote:

On 02/13/12 11:00, Spain, Dr. Jeffry A. wrote:

Using this DNS server, I'm still not getting the DNSKEY for any
DNSSEC capable domain; infact this server has issues -
dig +dnssec -t A dnssec.net @bind.odvr.dns-oarc.net.
I'd be really happy if I could get some domains which are signed.

Try this one: dig @bind.odvr.dns-oarc.net. isc.org +dnssec
You should get an AD flag returned and a variety of RRSIG records. Jeff.


I hope I'm not missing any concepts here, but there should be a public
key to verify the RRSIG, where's that? Shouldn't the server return
additional DNSKEY records?


No.

The RRSIG records are signatures of the name you did the query for, so 
are included in the same response.


The DNSKEY records are common to thousands of signatures, and it would 
therefore be a waste of bandwidth to include them in every response. 
They are separate records, which have to be fetched separately.

___
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: DNS RPZ and different answers for IPv6 vs IPv4

[Phil Mayers]

On 13/02/12 12:42, John Hascall wrote:


What I would like to have happen is for the IPv6 () query
for "evil-domain.com" to return "no data", but for the IPv4 (A)
query for "evil-domain.com" to return "CNAME".

Is this possible?  If so, how?


Maybe alias the name to a local name, then insert records for the local 
name with only an A record:


evil-domain.com. CNAME evil-domain-local.

evil-domain-local. IN A 192.0.2.1
; no 
___
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: dig -- only RRSIG present.

[Phil Mayers]

On 13/02/12 13:03, dE . wrote:


Ok, thanks a lot. I thought it was a client process. Now I can query for
the DS, DNSKEY records from isc.org.

Final question -- bind.odvr.dns-oarc.net is a cache right? Does bind has
such a caching program? Do we have a DNSSEC capable resolver in BIND?


Bind *is* a caching program.

Yes, bind is a DNSSEC-capable 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

Re: Logging issue with bind

[Phil Mayers]

On 02/16/2012 09:48 AM, Raven wrote:

Hi guys.
I am currently trying to setup query logging with bind on a debian
server, but I seem unable to.
I have the exact same setup on another debian box and it works
flawlessly. I've been scratching my head all morning..

My configuration:
/etc/bind/named.conf:

logging {
   channel munin_log {
 file "/var/log/bind9/query.log" versions 30 size 15m;
 severity dynamic;


"severity dynamic" starts at 0 i.e. off.

Just remove the "severity" line.
___
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: Logging issue with bind

[Phil Mayers]

On 02/16/2012 06:02 PM, Chris Thompson wrote:


"severity dynamic" starts at 0 i.e. off.


No 0 is equivalent to "info", except in one case:


Ah, my mistake. I took a quick look at the posters config and saw this 
as the only difference from our standard one, hence called it out.


Sorry for the confusion.
___
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: A few conceptual question about dnssec.

[Phil Mayers]

On 02/18/2012 04:35 PM, dE . wrote:

  On 02/18/12 00:36, Gaurav kansal wrote:


Firstly, where do we get the public key for the DS records?

Can you clarify your question???




The DS record is a signature right?


Wrong.

You're asking a lot of basic questions here. Maybe you could go off and 
read the applicable RFCs - they're quite well written - rather than 
asking us to explain them for you?

___
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: Anycast DNS

[Phil Mayers]

On 01/03/12 03:40, Beavis wrote:

Just want to piggy back on this topic is there any documentation
available online that shows a deployment guideline for Anycast?


There's not much to it:

 1. Create the anycast IP on your servers
 2. Route the anycast IP to your servers
 3. Make bind listen on the anycast IP

1 & 3 are easy.

2 can be accomplished using a very wide variety of methods. We use BGP, 
with a locally-created BGP speaker that checks port 53 for a reply and 
advertises/withdraws the route dynamically, but exabgp would be my 
recommendation, since it has a built-in facility to announce/withdraw 
routes via a "watchdog" script - see pages 5 & 6 of:


http://thomas.mangin.com/data/pdf/Linx%2074%20-%20Mangin%20-%20BGP.pdf

Alternatively you could use OSPF with Zebra/Quagga/Whatever. For example:

http://www.digriz.org.uk/ha-ospf-anycast

Cisco IP SLA probes, with "track" static routes are another option.

Or, if you don't care about dynamically withdrawing the route when bind 
goes away, just plain static routes.



___
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: Anycast DNS

[Phil Mayers]

On 29/02/12 03:55, ju wusuo wrote:

Have seen some anycast DNS implementations using more than one address,
some times even on the same subnet, any considerations or reasons for
doing that?


We do that.

We use two different, indepentent methods to route traffic to the IPs. 
We feel this provides a greater degree of resilience.

___
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 9.9.0 is now available

[Phil Mayers]

On 02/03/12 10:13, Matus UHLAR - fantomas wrote:

On 29.02.12 17:53, Michael McNally wrote:

NXDOMAIN redirection is now possible. This enables a resolver
to respond to a client with locally-configured information
when a query would otherwise have gotten an answer of "no
such domain". This allows a recursive nameserver to provide
alternate suggestions for misspelled domain names. Note that
names that are in DNSSEC-signed domains are exempted from
this when validation is in use. [RT #23146]


just by signing? so I can spare all our domains from being misused by
such shit just by signing them?



For the "bind" implementation, yes.

For the zillions of other crappy DNS servers and providers that to 
NXDOMAIN redirection, probably not.


(If the *clients* did DNSSEC-checking, then yes)
___
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 9.9.0 Inline-Signing Out of Control

[Phil Mayers]

On 05/03/12 17:46, David Kreindler wrote:


Are there guidelines or suggestions for setting the values of
sig-signing-nodes and sig-signing-signatures?


For what it's worth, we do "auto-dnssec maintain" with dynamic zones, 
and have left them at their default. It's a big zone, and the constant 
trickle of signing doesn't seem to be so bad.


Is there some reason the defaults don't suit you?
___
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: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)

[Phil Mayers]

On 03/07/2012 08:50 AM, Marco Davids (SIDN) wrote:


I also find it a bit strange that BIND decides to go for NSEC, even when
the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1).



AS I understand it, NSEC3 incurs overhead at validating resolvers. That 
being the case, it is unfriendly to use it unless you really need it, 
because you're increasing the load on everyone else.


It's unclear to me how many people have genuine concerns with zone 
walking that NSEC3 is an appropriate response to; putting sensitive 
names in a private subdomain or using split DNS would seems to be 
"safer" if you're concerned about tex hax0rs getting a list of all your 
machines (and don't forget to remove them all from reverse DNS, which 
takes minutes to walk given a target /16)

___
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: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)

[Phil Mayers]

On 03/07/2012 09:38 AM, Marco Davids (SIDN) wrote:


AS I understand it, NSEC3 incurs overhead at validating resolvers. That
being the case, it is unfriendly to use it unless you really need it


I don't have a problem with that. It's just that I find the current way
BIND works a bit tricky. I would feel more comfortable with an explicit
configuration-option in named.conf, rather than a seperate action (being
'rndc signing -nsec3param').

(In the case I *really* want NSEC3 that is, naturally)



Ah sorry, I misunderstood you.

Can't comment on the NSEC3 usability side of things; it's not something 
I've ever used outside the lab, and I didn't find it particularly onerous.

___
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: Master/slave configuration

[Phil Mayers]

On 03/08/2012 06:26 PM, michoski wrote:


Meant to add one thing...  In our configuration, we actually have two
recursive VIPs per site, and even considered three (internal IPs are cheap).


We do this.

We also make the two different VIPs use different underlying tech - one 
is an anycast route advertised with eBGP, the other is via 
load-balancing. The diversity of tech gives us a bit more resilience and 
flexibility - taking out the load-balancer no longer destroys DNS, for 
example.

___
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: Cisco ACE config for internal DNS load balancing

[Phil Mayers]

On 09/03/12 16:23, Matthew Huff wrote:

Anyone have any suggestions/best practices/config examples for DNS load
balancing for internal use on CISCO ACE blades?

I’ve got the standard example working, but wondered about keepalive
frequency, timeouts, fragments, etc…

Anyone got any examples they use that they could share?


We do transparent LB; the servers all have the service VIP as a /32 on 
their loopback interface. The packet flow is:


Req: client -> ace -> dns server
Rsp: dns server -> client

This has the advantage that the DNS servers don't have to sit "behind" 
the ACE.


We then use this config:

probe tcp TCP_53_RECDNS
  ip address 
  port 53
  interval 10
serverfarm host INTERNAL-DNS
  transparent
  predictor leastconns
  probe TCP_53_RECDNS
  rserver RSERVER1 53
inservice
  rserver RSERVER2 53
inservice
  rserver RSERVER3 53
inservice
  rserver RSERVER4 53
inservice

class-map match-any VIP_RECURSIVE-DNS
  2 match virtual-address  udp eq domain
  3 match virtual-address  tcp eq domain
policy-map type loadbalance first-match SLB_INTERNAL-DNS
  class class-default
serverfarm INTERNAL-DNS

policy-map multi-match VIPS_VLANXX
  class VIP_RECURSIVE-DNS
loadbalance vip inservice
loadbalance policy SLB_INTERNAL-DNS
loadbalance vip icmp-reply
loadbalance vip advertise

We didn't fiddle with the keepalive, probes, or anything else. It's been 
very well behaved in this config.

___
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: journal rollforward failed: journal out of sync with zone

[Phil Mayers]

On 12/04/12 11:50, Bryton wrote:

Hi,

I have observer a SERVFAIL error in one of my zone.On checking the logs
I realized there is this error

/journal rollforward failed: journal out of sync with zone/

I tried to learn more about it and I found out the solution is to delete
the journal file and restart bind.I tried that and it works.Now I wonder
what is the reason for such error and what the permanent solution to
mitigate it.


Did you or someone else edit the zone file by hand, without 
"freeze"/"thaw" the zone 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: re-bind named to all interfaces

[Phil Mayers]

On 12/04/12 15:32, Mihai Moldovan wrote:


Is there any way to tell bind9 to re-evaluate the network situation and bind to
all new interfaces (if allowed, see listen-on)?

I have tried firing up rndc reload and rndc reconfig via the pppd if-up/if-down
scripts, but neither try was successful.


"rndc reconfig" has worked when I've tried it in the past; are you sure 
you're running it in the right place? You want to run it in the "ip-up" 
/ "ip-down" scripts, because IP might not be up when LCP is.


There was some discussion on the list about setting the timer for 
re-discovery to zero; see the archives.

___
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: re-bind named to all interfaces

[Phil Mayers]

On 12/04/12 16:44, Mihai Moldovan wrote:


Hmm, permission denied while binding to ppp0? Maybe that's because my named is
running as the non-privileged system user "named" and binding to the privileged
port 53? Makes sense... but... hm. I guess in this case there's no other way but
running named as root?


I vaguely seem to recall this has come up on the list before.

However: at our site:

 1. Bind runs as user "named"
 2. "rndc reconfig" works with a new IP, e.g.

# rndc reconfig
# lsof -n -i :53 | fgrep 192.168.
# ip addr add 192.168.230.230/32 dev lo
# rndc reconfig
# lsof -n -i :53 | fgrep 192.168.
named   17052 named   32u  IPv4 1395639422   TCP 
192.168.230.230:domain (LISTEN)

named   17052 named  531u  IPv4 1395639421   UDP 192.168.230.230:domain

This is on RHEL5, with SELinux enabled.

So, it's definitely possible to do this as non-root. As above, I'm sure 
this has been discussed, but I can't remember what we decided the 
mechanism that allowed this was.

___
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: Configuring CNAME for nosslsearch.google.com

[Phil Mayers]

On 04/15/2012 11:40 PM, Tobias Krais wrote:

Hi Ben,

hmm. How can I manage what google suggests:
"Information for school network administrators about the No-SSL option

To utilize the no SSL option for your network, configure the DNS entry
for www.google.com to be a CNAME for nosslsearch.google.com."
Source:
http://support.google.com/websearch/bin/answer.py?hl=en&hlrm=en&answer=186669.
You can find this quite at the end of the document.

How can I realize such a configuration in bind?


As you've been told, you can't. CNAMEs can't live at zone apex, so you 
can't a CNAME at the zone apex of "www.google.com". And if you create 
"google.com" as a zone, all other hostnames will be blackholed, 
including "nosslsearch.google.com".


I don't know why Google have made that suggestion; it's a bad 
suggestion, that's not supported by many nameservers.


I personally think it's a bad idea to try and disable SSL search for 
your users too, but that's your decision.


"unbound" might be able to to this, with a transparent local-zone and 
local-data override for "www.google.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: How to stop ANY zone transfer

[Phil Mayers]

On 16/04/12 10:35, Chiesa Stefano wrote:

Hello all.
I'm developing a web application to apply massive dns changes
automatically.
I have a master dns server and three slaves. To test the application I'm
going to create an identical copy of the master server (in the same
network too).
What is scaring me is the update of the slaves. If I don't change
anything in the Bind configuration on the test server at the first zone
change it will replicate the zone to the slaves, and I, obviously, don't
want it.


No it won't.

The master does not "replicate" to the slaves. Rather, the slaves query 
the master.


As long as you don't change the config on the slaves, they will ignore 
your "test master", since it isn't a configured master.

___
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: Split DNS and zone transfers

[Phil Mayers]

On 16/04/12 16:36, Eric Chandler wrote:


Now, what I would like to have are slave servers that would zone-xfer
both the internal and external-flavored files for example.com and serve


You need to use TSIG keys, and match on key rather than IP address. This 
comes up on the list from time to time, and is in a/the FAQ.


(Or don't do this, and solve the problem another way ;o)

See:

http://www.isc.org/software/bind/faq

"My slave server for both an internal and an external view has both 
views transferred from the same master view - how to resolve?"

___
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: Configuring CNAME for nosslsearch.google.com

[Phil Mayers]

On 17/04/12 13:24, Tobias Krais wrote:

Hi all together,

very interesting this discussion. For I am a newbie I understood only
half.

Thus I detected 2 ways to continue:


I believe you can use response policy (RPZ) to achieve this. Or you
can use just about any non-BIND resolver (e.g. unbound) to achieve
this.


1. Don't use bind but e.g. unbound instead.

2. Ask Google.

Any other ideas I missed?


3. Use RPZ, as per Chris' suggestion

4. Create a zone for "www.google.com" and instead of CNAME, put an A 
record at the apex with the same IP as "nosslsearch.google.com". Run a 
script FREQUENTLY to re-resolve the host, as Google do short-TTL 
DNS-based loadbalancing.


5. Don't do this at all, since interfering with SSL is bad.
___
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: Question about KSK

[Phil Mayers]

On 27/04/12 13:40, wbr...@e1b.org wrote:

We are authoritative for a few dozen small zones.  Is it possible to use
the same KSK for all of them?  I can see where if it gets compromised we
would need to resign all zones using the KSK at once.  How much effort
would I be saving sharing the KSK?


That depends entirely on how you are signing and managing the zones.

IMO you might be creating more work for yourself, since it's a less 
common configuration.




I'm sure there are plenty of other good reasons not to do this...
Enlighten me!




It means you can't change the ZSK independent of the KSK, so any key 
changes involve parent DS changes too.


It means you have to keep the ZSK and KSK online; if you use a separate 
KSK, you could in theory keep that stored offline and only bring it 
online when the ZSK needs re-signing.


Known plaintext attacks. ZSK signs relatively larger amounts of data. 
Hence, if you buy this argument, ZSK should be rotated more frequently 
than KSK, implying separate keys.


etc. etc.
___
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: dynamic update to SOA records

[Phil Mayers]

On 04/27/2012 02:37 AM, cloud cache wrote:

Hello,

How to use nsupdate to dynamic update the SOA records?
For example, I want to update the zone's contact email and main NS


As others have pointed out, you just need to use "nsupdate" and send a 
valid SOA.


NOTE: "valid" means "must have a serial number > current". Bind won't do 
this for you - you need to choose an appropriate, higher, SOA serial in 
the new record you send. Adding 1 is fine.

___
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: Convice Bind to listen on IP alias with a range of IPs.

[Phil Mayers]

On 04/30/2012 10:56 PM, Augie Schwer wrote:

I must be doing something wrong, because what I want to do doesn't
seem that difficult.

I have a range of IPs bound to a local interface:

lo:1  Link encap:Local Loopback
   inet addr:10.0.0.1  Mask:255.255.255.224

And I want to convince Bind to listen on sub-set of the given range (
10.0.0.2 for example ), yet when I configure that IP:


Which operating system are you running?

Contrary to what a lot of other people have suggested, it is in fact 
possible using the socket API to bind() to IPs which aren't explicitly 
created, due to special handling on the loopback interface. This can 
certainly be done under Linux, for example., and I have just 
re-confirmed that to myself.


I assume, because of the phrasing of your question, that your OS does 
indeed have this feature, and you've tested it working with other 
applications (even if as simple as netcat)?


Unfortunately, it seems likely that named is using the normal socket 
APIs to first enumerate the list of IPs on the box, and then filter 
those through listen-on statements to get the final list of IPs to pass 
to a bind() socket call - this would be a sensible way to implement the 
CIDR listen functionality.


If so, then if the IP isn't *explicitly* on an interface, it won't 
appear in the final output set, regardless of the fact a bind() call 
will succeed.


So you might be being a bit too clever, and foxing the named socket code 
I'm afraid.


Cheers,
Phil
___
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: Convice Bind to listen on IP alias with a range of IPs.

[Phil Mayers]

On 05/01/2012 10:00 AM, Phil Mayers wrote:


So you might be being a bit too clever, and foxing the named socket code
I'm afraid.


That should of course be "the named socket code is foxing you". Sigh.
___
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: dynamic update to SOA records

[Phil Mayers]

On 01/05/12 11:20, cloud cache wrote:


But, how will I know the current serial number of the zone, if the zone
has been changing frequently?


In the past, I've used a script that queries the SOA just before doing 
the update (which is safe, because in a race condition you'll be "too 
low" and fail)


e.g.

#!/bin/sh

ZONE="example.com"
SERVER="192.0.2.1"
TTL=3600
SOA_SERIAL=`dig @$SERVER +short $ZONE SOA | awk '{ print $3 }'

BUF=`mktemp`
trap "rm -f $BUF" EXIT

cat <$BUF
server $SERVER
zone $ZONE
update add $ZONE $TTL SOA your.values. go.here. $(( SOA_SERIAL+1 )) ...
show
send
answer
EOF
___
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: erros in logs

[Phil Mayers]

On 10/05/12 09:47, Ben wrote:

Hi,

I just enable bind as caching name server and when watching logs i got
below erros.


It looks like you have broken IPv6 connectivity - your machine believes 
it has an IPv6 address and possibly a default route, but it doesn't work.


Check your networking config.
___
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: named validating @0x...: ... SOA: no valid signature found

[Phil Mayers]

On 15/05/12 13:22, Brian J. Murrell wrote:

On 12-05-02 09:29 AM, Mark Andrews wrote:


* a firewall blocking EDNS queries.
* using a non DNSSEC enabled forwarder so you don't get signatures.
* a firewall blocking fragmented UDP and named falling back to
   plain DNS.
* other packet loss causing named to fallback to plain DNS.


Given that I have confirmed EDNS works with:

dig edns-v4-ok.isc.org TXT
dig edns-v6-ok.isc.org TXT

and that I don't have a firewall that would/should be dropping
(properly) fragmented UDP[1] and I have no other indications of packet
loss, are we looking at a bug in BIND9 to explain this (mis-)behavior?


Isn't it more likely it's a local problem?

Which version of bind are you running? Does *any* zone validate e.g. try:

dig +dnssec @localhost www.ic.ac.uk

...and you should see:

; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18199
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 11

Note the "ad" flag - "authenticated data".
___
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: DNS64 - multiple mapping

[Phil Mayers]

On 05/24/2012 07:36 AM, Rock July wrote:

Hi All,
Is it possible for me to add multiple dns64 in options? I want to have


Yes.


different IPv6 prefix for each IPv4 network address.


I don't know what the means, but the dns64 option takes a quite 
comprehensive set of ACLs to match client and original packet A 
address(es) as well as other options. Perhaps you should read the ARM?

___
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: Partial forwarding.

[Phil Mayers]

On 30/05/12 12:03, Stephen James wrote:

We have a lab setup where we are testing a customer configuration but do
not have all of the same equipment.
Is it possible to have a bind server that resolves certain FQDNs in a
zone, while forwarding the remaining to another DNS?


Not easily. You could create a zone per FQDN you want to resolve, or use 
RPZ to re-write query responses in bind 9.8.


It sounds like you want something similar to "local-data" in unbound
___
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 handle zones that need to be the same in all views?

[Phil Mayers]

On 06/12/2012 01:03 AM, Max Bowsher wrote:

That won't help me for slave zones:

* the zones get needlessly re-transferred once for each view


If you actually want a copy of each zone in each view, you can't avoid this.



* the files on disk will be repeatedly overwritten as bind tries to save
the zone data separately for each zone, to the same filename


This does rule out includes; they only work for static zones.



* bind will only act on a notify for the view that receives it, leaving
all the other views serving stale data for the zone


Again, this is hard to avoid unless you burn a lot of IPs.


Have you considered a single view containing all the common zones, then 
a view per "different" zone that forwards to 127.0.0.1? Provided you 
arrange your "match-clients" correctly this should work.


You may wish to investigate the attach-cache option, so that all the 
forwarding views can share cache results.


Bear in mind that the forwarding views will not see changes in the 
common view immediately, but will have to wait for TTL expiry. There's 
not much you can do about this.


Basically, there's no trick to do what you want; bind isn't designed to 
share non-static zone data between zones.

___
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 handle zones that need to be the same in all views?

[Phil Mayers]

On 12/06/12 15:31, Barry Margolin wrote:

In article,
  Phil Mayers  wrote:


Have you considered a single view containing all the common zones, then
a view per "different" zone that forwards to 127.0.0.1? Provided you
arrange your "match-clients" correctly this should work.


Forwarding only works for recursive queries.  I think he's dealing with
an auth server.



That's not apparent to me, but if so, then he's just going to have to 
tolerate multiple copies of the zones, and deal with the NOTIFY issue 
somehow (burn a lot of IPs?).

___
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

Delegation bit-rot detection?

[Phil Mayers]

All,

Over the years, we have offered DNS secondary services to various 
organisations. Some of those organisations are (ahem) fairly small, and 
lots of the delegations and zone transfers have suffered bit-rot - there 
are zones delegated to us that I have no records on, and certainly can't 
AXFR from the masters (in some cases, the masters answer REFUSED as well).


I'm wondering if anyone knows of a script that will process our logs 
looking for "refused" queries, and then post-process these by tracing 
the delegations and telling me what the nearest enclosing zone is, the 
NS records that led inbound queries to us, and (if any of the other NS 
records are responding) the SOA.


I could write something, but there are a lot of corner cases, and I'm 
feeling lazy!


OTOH if anyone has any suggestions (other than "ignore the refused", 
which is what we're currently doing) for dealing with these kinds of 
things...


Cheers,
Phil
___
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: Moving DNS out of non-cooperative provider

[Phil Mayers]

On 18/06/12 16:49, Alexander Gurvitz wrote:


with each query gets new NS record, and... refreshes the NS TTL ?


No, that's not how TTLs work. They always count down.



Will ns.isp.com  EVER query ns.NEWprovider.net
 ?


Yes, when the TTL has expired.



I'd be happy to know how BIND behaves, but also
how other servers may behave in this case.



This isn't server-specific; every DNS server should behave this way.

The only way a recursive server will continue to see the old record is 
if the recursive server either forwards to the "old" provider, or slaves 
the old provider zone - this might happen if the recursive server is 
owned by the same ISP as the "old" authoritative server.

___
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: Moving DNS out of non-cooperative provider

[Phil Mayers]

On 06/19/2012 04:18 AM, Barry Margolin wrote:


Didn't this used to be a problem?  When the caching server queries the
cached nameservers, the response would include the old NS records in the
Authority section.  The caching server would then replaced the cached NS
records with these records, resetting the TTL to its full time.  As long
as it continued performing queries against the old servers before the NS
records timed out, the TTLs would keep getting reset, and never expire.


Interesting. I was unaware of this issue, thanks for pointing it out. As 
Mark mentions in his follow-up, it seems like there are other corner 
cases where a broken or malicious nameserver can futz up delegations.

___
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: Compiling and testing on Fedora

[Phil Mayers]

On 21/06/12 15:21, Lightner, Jeff wrote:

Turning off SELinux also requires a reboot after changing mode.


"setenforce 0" does not require a reboot.
___
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 zones best practices

[Phil Mayers]

On 26/06/12 16:42, nex6 wrote:

* Brad Bendily  [2012-06-25 16:35:28 -0500]:


wouldn't it be more confusing, in a big IP space with servers,
desktops etc all mashed together into one zone?


If you have enough hosts for this to be confusing, you have enough hosts 
to store the data in some master data-source and automatically generate 
the zone files (or dynamic updates).


Don't edit zone files manually unless they're trivially small.

Don't read zone files unless you're debugging.

Basically: don't do this.

FWIW we use one large 10.in-addr.arpa file. Likewise for our "real" /16 
subnets. We don't use a different reverse zone per actual subnet - it's 
pointless, and limits you to byte-aligned subnets or horrible delegation 
tricks.

___
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 zones best practices

[Phil Mayers]

On 26/06/12 17:25, nex6 wrote:

* Phil Mayers  [2012-06-26 16:54:55 +0100]:


I am not going to be editing files by hand, we actually have a tool. I am more
concerned about best practices, and how to fix the mess.

eg, say we have about 500 vlans (/24s) and say only 350 have reverse zones.
from what I understand its best to just create the missing zones and fix the 
tools
so new networks always get reverse zones created.

becuase I dont think i can just create a larger /16 or /8. becuase they will
overlap and create a bigger mess.


Do what works for you. If you would rather create the full range of 
x.y.10.in-addr.arpa from your tools, that's fine.


I'm not sure the "best practice" you are asking about exists in that form.

One final point though - you *should* have an enclosing 10.in-addr.arpa 
zone or "fill the holes", so that you don't leak reverse lookups to the 
DNS root servers. You might even find that, unless you disable it, your 
nameserver creates the empty zone for you.

___
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 zones best practices

[Phil Mayers]

On 27/06/12 15:30, nex6 wrote:


so, you *should* have a larger 10.x.x.x zone? *and* smaller
10.x.x.0/24 zones? so i am assuming the workflow would be in this
case, records go in the smaller zones, and the larger zone is the
catchall to prevent leakage?


It is good practice, and polite, to prevent leakage of reverse DNS 
queries for the private IP ranges.


You can accomplish this two ways:

 1. Have a "zone" statement for every /24 inside 10/8 e.g.

0.0.10.in-addr-arpa
1.0.10.in-addr.arpa
...
255.255.in-addr.arpa

You could use empty/dummy zones (maybe even the same zone file) for 
zones which don't have actual contents defined.



 2. Have a "10.in-addr.arpa" zone *and* the smaller zones. If you do 
this, you might want to take the time to insert the proper delegations 
inside the 10.in-addr.arpa zone to the smaller zones, even if they're on 
the same servers. It might work without that, but there might be 
circumstances where it won't - I'm not sure.

___
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: prevent DNS attack

[Phil Mayers]

On 06/28/2012 02:36 AM, pangj wrote:



There is also a patch for BIND which can help:

http://www.redbarn.org/dns/ratelimits


Thank you.
The traffic is incoming, and the incoming IPs are fake, how will the
patch work to stop them?



Read the archives that Tony pointed you at. There is much discussion, 
and no point in repeating it here.


Basically, stopping it is impossible. You can alleviate it to a greater 
or lesser degree. Rate limiting reduces the bandwidth of the DoS.

___
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: CNAME+A record in response

[Phil Mayers]

On 06/29/2012 07:50 AM, Srinivas Krishnan wrote:

A lot of times we get responses that look like:

FOO.BAR CNAME EXAMPLE.BAR
EXAMPLE.BAR A 1.1.1.1


BIND currently (atleast with the default settings) when it encounters
a CNAME stops processing and checks if EXAMPLE.BAR is in cache or else
sends out another query to resolve it even though the A record in the
packet completes the chain.

Now, is there a setting in BIND to accept the A record or do providers


I'm curious why you want to change this behaviour.
___
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 dies with assertion failure

[Phil Mayers]

On 07/03/2012 01:16 AM, Oscar Ricardo Silva wrote:

I *THINK* I found the reason for why we're exposed to this bug ... It
would appear that Redhat based their BIND package on 9.8.2rc1.  Guess
where the patch for this bug was applied?  9.8.2rc2.


Are you sure about this?

From what I can see in our local yum repo of the RHEL6 ISOs, it shipped 
with bind 9.7.


Sure that isn't a local package, or you're joined into a non-production 
channel?

___
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 can I set the interface used to transfer zones?

[Phil Mayers]

On 05/07/12 15:34, Carlos Ribas wrote:

I tried transfer-source before, but this is what happened:


You still need to set "masters { 10.x.x.x; };" on the zone.

Transfer source controls the source IP. Masters controls the destination IP.
___
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: Resolve only authoritative domain for internet/public addresses

[Phil Mayers]

On 07/08/2012 07:15 AM, Mr BeEye wrote:

Hello all.

Let's have a finite list of IPv4 (private and public) addresses, e.g.
{A, B, C, ... N}.

It is possible to configure BIND in the way:
1) BIND resolves EVERYTHING for {A, B, C, ... N}.
2) BIND resolves ONLY its authoritative domain for internet excluding
{A, B, C, ..., N}.



Yes. Use a view:

view internal {
  match-clients { a; b; c; ... n; };
  recursion yes;
  zone ... {
  }:
};

view external {
  zone ... {
  };
};

However, views are tedious in many ways. You need a copy of your 
authoritative zones in each view, and have to arrange the AXFR/NOTIFY to 
go to the right place. It's much easier IMO to run two different copies 
of bind on two different IPs (or machines).

___
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: Resolve only authoritative domain for internet/public addresses

[Phil Mayers]

On 07/08/2012 09:32 AM, Jukka Pakkanen wrote:

Why not just:

acl "X" {A; B, C; ...; };

options {
...
 allow-query { "any"; };
 allow-recursion { "X"; };
...};


Doh, of course. This is a better idea, 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: BIND CPU load problems

[Phil Mayers]

On 10/07/12 12:56, Shon Stephens wrote:

Dear Mike,

 I am not being hit with a Denial of Service attack and the query
logging doesn't appear to be any different from other hosts in the DNS
complex. There are no errors in logs or messages files either. I have
not installed a previous version from source.


Does "strace" indicate what the bind process is doing?
___
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: disabling "Any" requests

[Phil Mayers]

On 12/07/12 14:38, Chuck Swiger wrote:

On Jul 12, 2012, at 2:27 AM, Dns Administrator wrote:

Hi  bind-users,
please excuse my ignorance being a novice to dns, but is there some way of disabling 
or choking "Any" type requests?


This has been discussed on the list recently - see the archives.
___
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: disabling "Any" requests

[Phil Mayers]

On 12/07/12 15:16, Lightner, Jeff wrote:


Personally I don't know why "dig -t any" would be a problem.   It's
not exactly the same as doing an axfr transfer of the zone - it still
only gets limited information.


They're the current query type du jour for DDoS amplification attacks, 
which I assume the OP is experiencing.


Personally I feel it's a mistake to focus on the query type; as others 
have pointed out, DNSSEC-signed TXT/SPF records are large, and 
plentiful. Best just focus on query rate.

___
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: disabling "Any" requests

[Phil Mayers]

On 12/07/12 16:48, sth...@nethelp.no wrote:

Personally I don't know why "dig -t any" would be a problem.   It's
not exactly the same as doing an axfr transfer of the zone - it still
only gets limited information.


They're the current query type du jour for DDoS amplification attacks,
which I assume the OP is experiencing.


The attackers have already diversified. TXT queries work just as well,
e.g. against wroe.com. Blocking ANY queries is going to a rather short
term "fix".


Not unexpected. They are, sadly, not idiots, and are probably reading 
the same mailing lists we are.

___
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: named validating @0x...: ... SOA: no valid signature found

[Phil Mayers]

On 20/07/12 14:03, Brian J. Murrell wrote:


# dig +dnssec @localhost 119.in-addr.arpa SOA

; <<>> DiG 9.9.1-P1 <<>> +dnssec @localhost 119.in-addr.arpa SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49713
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 14


What do you see if you:

 1. Clear the cache
 2. Start tcpdump
 3. Do this query

Presumably there is a failing DNS query somewhere underlying this.

Or, what happens if you start bind up in debug mode and run the query? 
There will be a lot of output, but I've found most problems to be fairly 
obvious if you read through 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: named validating @0x...: ... SOA: no valid signature found

[Phil Mayers]

On 20/07/12 15:33, Brian J. Murrell wrote:

On 12-07-20 09:11 AM, Phil Mayers wrote:


Or, what happens if you start bind up in debug mode and run the query?
There will be a lot of output, but I've found most problems to be fairly
obvious if you read through it.


Yeah, there is a lot of output.  Too big of a haystack for me to find
the needle I'm afraid.  I probably had way too much debug enabled.  I'd
be happy to trim it back if desired.  Just tell me which categories
you'd want to see and what severity to set.

In any case, the log is at
http://brian.interlinx.bc.ca/119.in-addr.arpa.debug and the query I did was:




A quick skim suggests that you aren't able to validate the root, but are 
able to validate DLV, which is why a subset of sites are working - those 
still with DLV entries.


If you can validate www.ic.ac.uk but not www.cam.ac.uk (who have now 
left DLV) then this might confirm it.


No idea why the root isn't valid for you, given you are running a recent 
bind - presumably the managed-keys config is messed up somehow.


Have you tried a clean install; blow away the entire /var/named and 
config hierarchy and start 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: named validating @0x...: ... SOA: no valid signature found

[Phil Mayers]

On 20/07/12 16:21, Mark Andrews wrote:


In message <50096c2b.1080...@interlinx.bc.ca>, "Brian J. Murrell" writes:

Just for good measure, since I think I have posted this before, but here
are the options I have set in my bind configuration with regard to dnssec=
:

 dnssec-enable yes;
 dnssec-validation yes;
 dnssec-lookaside auto;


FWIW, on 9.8 the only other line we have (for reasons of permissions) is:

  managed-keys-directory "/var/named/data/dynamic";

I don't see why those 3 lines aren't sufficient for him?



Turn on validation using the root's DNSKEY.

auto-dnssec maintian;


I thought that was for master zones, not recursion/validation? Or am I 
missing something?

___
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: lot of 'ripe.net IN ANY +ED' queries

[Phil Mayers]

On 23/07/12 13:07, Marek Salwerowicz wrote:

Hi all,

I am new subscriber of your list.
I browsed the archive but didn't find answer/hint for my problem.

I am running (at FreeBSD 9.1-PRERELEASE) public caching DNS server.
Since about 2 months I've been receiving lot of (DNS flood attack?)
queries like:

23-Jul-2012 14:03:28.813 queries: info: client 96.44.152.125#53: view
external: query: ripe.net IN ANY +ED (my.dns.server.ip)

What I made now, is just to parse logs and block IPs that ask for
ripe.net via ipfw.

But is there any other solutions for that permanent attacks?


This is getting to be an FAQ.

It's a source-spoofed amplification attacks. See the list archives for 
discussion, including links to a patch for bind with per-client 
rate-limiting.

___
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: "Nintendo"('s NSes) are asking my IP for it's rdns

[Phil Mayers]

On 24/07/12 12:05, Brian J. Murrell wrote:



Is this just broken NS software or are they (Nintendo, FWIW) doing


Looks broken to me.

I note that IP doesn't have a reverse. This suggests to me it's not any 
kind of nameserver, but rather part of their general pool - perhaps a 
random desktop.


However, this page:

http://vega.sra-tohoku.co.jp/~kabe/misc/dnsprober.html

...suggests it is part of some kind of probing/exploration 
infrastructure, although the page author seems a bit, erm... how to put 
this?... intense, about unexpected DNS traffic ;o)



something interesting, like giving everyone an opportunity to provide
an rdns for their own IP address without everyone having to make
classless in-addr.arpa delegation arrangements with their ISP (which
mine refused to do)?


Change ISP?



It's kind of a neat concept if it's not just an accident of broken NS
software.


I don't think that's what is going on. But even if it were, I think that 
would be a bad idea, personally. DNS is well-specified in the RFCs. 
Violating those to work around lazy ISPs is not a good solution.




Has anyone else seen anything like this before?  Is there some
(proposed even) standard for doing this that I'm not aware of?


We see all kinds of weird nonsense come into our DNS servers. We see 
LOTS AND LOTS of these two zones, continually:


75.97.111.76#27300: view main: query (cache) 
'mx241.emailfiltering.com/A/IN' denied


41.218.219.221#26895: view main: query (cache) 
'service17.mimecast.com/A/IN' denied



But we also see a trickle of other crap that is nothing to do with us, 
for example:


190.26.0.2#16074: view main: query (cache) 'ns1.webservices.net/A/IN' denied

59.90.143.134#48824: view main: query (cache) 'a20.g.akamai.net/A/IN' denied


I've never established why this happens, whether it's some kind of 
attempt at cache poisoning from botnets or just broken software. But 
frankly I don't care - I just ignore 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: "Nintendo"('s NSes) are asking my IP for it's rdns

[Phil Mayers]

On 24/07/12 14:30, Brian J. Murrell wrote:


Why?  I mean other than a knee-jerk reaction to that behavior not (yet)
being documented in an RFC somewhere?  I mean for practical purposes why
is what they are (or rather, could be, assuming my suggestion about what
they could be doing is correct) doing necessarily bad?


The obvious implication of that behaviour is lots of DNS packets to IPs 
around the world that may not be (probably *are* not) running a DNS server.


Based on the numbers coming in and out of my own resolvers (which aren't 
even that busy), suffice to say I think that traffic would be at best 
problematic, and at worst harmful.


I can think of a bunch of ways this might cause problems, but frankly I 
lack the energy to get into a discussion about it. Maybe others are more 
interested ;o)





DNS is well-specified in the RFCs.


Sure.  So there is no room for expansion?


Absolutely. I look forward to the internet draft ;o)

In all seriousness, I don't dismiss that the behaviour *could* be 
useful. I just think that, in general, sending unsolicited requests to 
unknown IP addresses, on a well-known protocol/port is sub-optimal.

___
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: getaddrinfo and TTL

[Phil Mayers]

On 08/03/2012 05:48 PM, Martin McCormick wrote:

Can one read the TTL for a given lookup in
getaddrinfo?


I don't believe so.



Better yet, is there a listing of the entire range of
values one can read from all the structures?


The getaddrinfo() interface is specified in RFC 3493.

Specific platforms might extend the "struct addrinfo" (maybe?) but AFAIK 
most / all implementations just conform to the basic RFC.




I wrote an application years ago to let us change the
name of a host. The old code uses zone transfer to pull in the
whole zone, actually several zones in to a pile of A records. We
look for the old name, replace it with the new name and then do
a delete and add.


I don't understand this I'm afraid.



If getaddrinfo contains this value, the replace
application can run much faster, just doing one lookup, and the
new record we write back will keep whatever value we originally
had.


If you want TTL, you will need to use DNS-specific functions like the 
res_* API. You need to be sure you are querying the master, otherwise 
the TTL will be the one from cache, not the "real" value.

___
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: Delayed Zone Transfers?

[Phil Mayers]

On 06/08/12 17:03, Jiann-Ming Su wrote:


Here's an example of the zone file being updated, but BIND not serving out the 
new data.

Running dig locally:
# dig @localhost myhost.uts-sa.mydomain.ddns


I note from your other email that you are using views.

Are you sure you are querying the right view? It seems that you may be 
querying the view in which the zone is not slaved, hence you get old, 
cached data.

___
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: Delayed Zone Transfers?

[Phil Mayers]

On 08/06/2012 05:33 PM, Jiann-Ming Su wrote:


Yeah, I've wondered about views.  We went to views to work around a
MTA config issue.  The weird zone transfer performance seem to have
coincided with our transition to views.  Here's my named.conf, FWIW:

view hc { include "/etc/named.zones";

view all { include "/etc/named.zones";


You are "include"ing a set of zone defintions in two different views
here. Since your example zone doesn't appear to be in the main file, I
assume it's in the included file?

If so, this won't work, and will cause the problem you're seeing.
Basically you've got two views trying to write two different zones to
the same file and journal, but with distinct ideas of the in-memory 
contents. Only one receives a notify and does IXFRs.


If you want a zone in two views, it must either be:

 1. A simple "type master" with no DDNS allowed, or
 2. Written to different files

In addition, NOTIFY is like any other DNS packet, and specifically it 
goes into a "view". This makes slaving a zone twice tricky - there is a 
recipie in the FAQ using TSIG keys for this.





For the particular case I demonstrated in the previous email, I don't
think views should have affected it as the default "all" view should


Yes. But as per your *other* message, the notify (and therefore the 
IXFR) happened in the "hc" view, so it's the one up-to-date:


06-Aug-2012 11:20:36.575 notify: client 192.168.8.8#33456: view hc: 
received notify for zone 'uts-sa.mydomain.ddns': TSIG 'dns1.mydomain.org'


The "all" view will have to wait until the SOA refresh timer expires, 
which explains your delay in the zone updating.



have been hit.  And even the "hc" view, the data would be the same as
we're only "spoofing" for the specific psmtp.com mail hosts.


No. As above, this is not how views works with changing zone contents. 
You can't write to the same file from two zones I'm afraid.

___
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: SRV query with no domain?

[Phil Mayers]

On 15/08/12 15:42, Thomas Secula wrote:

Hello,

I hope this is the right list.. I am using bind 9.8.2on centos 6 with a
system called openims. I am trying to get my bind server to respond to
an SRV query of _sip._udp where the query has no domain.


Yuck. That's horrible. Are you *sure* that's what you want? You can't 
set the "search" path on the client(s)?



the openims folks that I should be able to get my bind to respond but I
have been unable to.


DNS query names are all full-qualified.

If you *really* want to respond to the name "_sip._udp." (note the 
trailing dot) you'll need a create a zone to contain the name. You can't 
make bind qualify the name for you.


For example:

zone "_udp" {
  type master;
  file "_udp.zone";
};

...and in the zone:

_udp.  IN SOA ...
_sip._udp. IN SRV ...

But this is a bad thing to do; it might cause problems in a number of 
ways down the road, and I strongly recommend you don't do it.


Get your clients to issue fully-qualified DNS name - preferably by 
actually querying a fully-qualified name, alternatively by putting:


search your.domain.com

...in /etc/resolv.conf or the system equivalent.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Zone Transfer issue on BIND9

[Phil Mayers]

On 24/08/12 12:09, sn...@email.it wrote:

Hi there,
I have an issue related to zone transfer which I couldn't fix. I've found a
"presumable" fix googling a lot but it doesn't seem to work.


You haven't said *how* it isn't working. Be specific.

Note that the FAQ link you reference puts the "server {}" block INSIDE 
the view. You have it in the global config. That seems like something to 
investigate.

___
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: Question related to domain names and less to bind straight.

[Phil Mayers]

On 09/05/2012 07:31 AM, Doron Shikmoni wrote:

Hello Eliezer,

Not an RFC, but you may find this list helpful:
http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1


See also:

http://publicsuffix.org/
http://www.dkim-reputation.org/regdom-libs/

...which are more generalised versions.
___
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: RHEL, Centos, Fedora rpm 9.9.1-P3

[Phil Mayers]

On 13/09/12 17:21, Carl Byington wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


http://www.five-ten-sg.com/util/bind-9.9.1-0.1.P3.fc18.src.rpm


Are you sure the "useradd" command in %pre is valid on RHEL4/5? 
Specifically the "-N" argument? We had to change that in our local .spec 
file when basing off the Fedora one.


(I always thought it was a shame that RPM didn't provide some 
higher-level wrappers for common operations in %pre and %post)

___
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: Moving from "type forward" to "type static-stub"

[Phil Mayers]

>
>It's time to back in again (front in?).  Now that Comcast is
>validating,
>any mistakes that people make will get fixed right quick.  1.7 million
>people doing validation is good incentive to get things right and fix
>them quickly.  At UC Berkeley, validation has been turned on for four
>years now and only a handful of domains have required "special
>handling."
>
>All of the emphasis on signing for DNSSEC is great, but DNSSEC can't
>really work without validation.
>

+a lot
-- 
Sent from my phone. 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: about DNS RRL

[Phil Mayers]

On 10/17/2012 09:17 AM, pangj wrote:

I have read the document of redbarn RRL for BIND and this NSD RRL:
https://www.nlnetlabs.nl/blog/2012/10/11/nsd-ratelimit/

I have a question that, since the DDoS to DNS are coming from spoofed
IPs. But RRL is working based on source IP. So how can it stop the real
life attack?


It doesn't stop it (indeed, can't). It mitigates the impact.

The DDoS tend to come from a fixed set of spoofed source at any one 
time. RRL helps, in that it:


 1. punts early in the path, lowering resolver CPU use, and
 2. returns a minimal response, which prevents amplification.

Remember the DDoS is actually directed at the spoofed source, not the 
DNS server. The DNS server is merely an unwilling participant. RRL helps 
prevent that participation.


There is, as I understand it, some spotty evidence that the attackers 
will move to a different server if RRL seems to be in use. How this 
happens I don't know - maybe they probe with real IPs? - but I've heard 
others emphatically claim this is not the case, and attackers will 
continue to blindly flail at you until the attacking node goes down.


The only solution to these kinds of attacks is for providers to 
implement BCP 38, and for upstream providers to start de-peering 
providers who don't. I rate this about as likely as... a very unlikely 
thing.


S/RTBH can help the DNS provider, if they're being overwhelmed and their 
upstream supports 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: Possible DDoS?

[Phil Mayers]

On 10/17/2012 07:39 PM, Dennis Clarke wrote:


I have the exact same problem with an ip inside State of Colorado
General Government Computer subnet :

http://whois.arin.net/rest/org/SCGGC


That's not exactly a fly-by-night organisation; have you contacted them?



Some server there has been pounding queries at me at a rate of
48,000+ a day :


Some packets are arriving with that source IP. Big difference.

It's possible (likely?) the sources are spoofed, and someone is inducing 
*you* to bombard that IP with replies (or trying to).




Queries show up in bunches, while the average is every 1.7 secs I see
dozens of queries all arrive nearly at the same time, then a ten
second pause, then again another burst.

Makes no sense to me what is going on there.


Attacker sends 1 million DNS queries of 100 bytes each, with a spoofed 
source. DNS server sends 1 million DNS replies of 1000 bytes each to the 
spoofed IP. 10x amplification, means the attacker can use lower-spec 
machines to overload a target.


Or something is just broken, and the source IPs are real - in which 
case, contact 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: 答复： Re: Possible DDoS?

[Phil Mayers]

On 10/18/2012 12:12 AM, Tony Xue wrote:



I am pretty sure the sources were hacked because one of my another


What makes you think the source IPs were real?
___
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: ISC Bind in Active Directory

[Phil Mayers]

Nicholas F Miller  wrote:

>DDNS record scavenging is the only feature I'm aware of that MS DNS has
>that Bind doesn't . On the flip side, ISC Bind can ACL who can add
>certain record types to a dynamic zone using GSS-TSIG as well as
>supports views and ACLs for recursion. Everything else should be
>standard DNS.
>

Yeah, that would be nice to have actually. More generally, metadata on ddns 
records would be useful.
-- 
Sent from my phone. 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: ISC Bind in Active Directory

[Phil Mayers]

b...@bitrate.net wrote:

eful.
>
>
>to be honest, this doesn't seem to me to be something that would fall
>within bind's purview.  comparing bind to "microsoft dns" isn't really
>apples to apples.  microsoft dns is more than just a dns server.  it's
>also a dns management system [whereas bind is not], which is where
>things like scavenging dns data or publishing metadata would belong. 
>one partial example of this would be dhcpd's use of ddns, which uses
>txt records to include some metadata in dns.as it is, bind can
>fully support probably any such mechanism, with the benefit of being
>agnostic.  i like that modularity, and would be disappointed if it
>changed.
>
>-b
Perhaps I have not made myself clear.

In the case where ddns updates are made directly to bind, it would be handy if 
bind were to gather metadata about the source and time of the update, so that 
it is *possible* for external systems to scavenge or whatever.

I don't believe the current update logging is up to it.

Fairly obviously, external systems can't publish metadata they don't know.
-- 
Sent from my phone. 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: ISC Bind in Active Directory

[Phil Mayers]

On 24/10/12 16:54, Kevin Darcy wrote:


Why do you feel the need to register clients in your AD domain at all?
We register our clients outside of the AD domain via the DHCP server;


Our experience is that this can cause (minor) problems.

The basic issue is that, if you have an AD realm:

EXAMPLE.COM

...and a machine:

foo

...then windows tries very hard to stick its fingers in its ears, shout 
"la la I am not listening" and assume its hostname is:


foo.example.com

You have to fiddle around extensively to make the client *think* it's 
name is what it really is, and it has never been clear to me what the 
implications of doing so are.


This can matter if you have systems that trust the clients own idea of 
the hostname (e.g. vPro/AMT enterprise provisioning) or if you have 
support staff who want to be able to right-click on a machine from the 
"AD users & computers" snap-in and click "manage".


If people have any insight into an easy way of updating clients with the 
correct idea of their own DNS hostnames, and can explain how this 
interacts with the per-connection DNS suffix stuff in the IP stack, I 
would be very grateful!

___
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: ISC Bind in Active Directory

[Phil Mayers]

On 10/24/2012 10:17 PM, Carsten Strotmann wrote:


my experience is that it is safe to place clients in either a DNS domain
with the same name as the AD domain, or in a subdomain of the AD
domain.


What does "place" mean, exactly?

Bear in mind that, unfortunately, Microsoft chose to embed DNS names in 
a lot of places when they retrofitted Kerberos, DNS and LDAP to the NT 
domain protocols.


You've got:

 1. The clients own idea of its "main" hostname
 2. Global DNS search suffixes
 3. Connection-specific DNS suffixes
 4. The value of the "dNSHostName" AD attribute
 5. The suffixes to qualified servicePrincipalNAme AD attribute(s)
 6. The value of msDS-AllowedDNSSuffixes on the domain OU
 7. Finally, DNS names which point to the clients addresses

...and that's just off the top of my head. Telling me it's "safe to put 
the client in another DNS zone" doesn't really tell me anything about 
the interaction of those things, I'm afraid ;o)



Using a subdomain has the benefit of seperating infrastructure


Yes, obviously it's desirable. The question is, how do you appropriately 
configure all of the above (and anything else besides) in a safe, 
scalable and supported way, that won't cause odd things to break, in 
such a way as to achieve that?


This is largely a dead issue to me - we just live with the massive 
inconsistency of clients believing they're one thing, and DNS saying 
another - so my knowledge is a bit rusty, but from what I recall, it's a 
huge pain configuring clients into sub-domains of the AD domain, because 
there are so many places you have to get it right. And *renaming* is 
even harder.


So we just stopped trying. All clients think they live in "example.com", 
and we use DNS names as we like e.g. "dept.example.com", 
"building.example.com". The problems it causes are less hassle than a 
mass reconfiguration of 20k machines...



AD-Domain DNS-Zone. Putting AD-Clients into a DNS-Suffix (aka "local
domain") that is a different branch of the DNS namespace than the
AD-Domain DNS name creates problems and is not
recommended.


Why? And again, "putting" means what here?


Using connection-specific DNS-Suffixes to my knowledge are used in the
case that one machine has network connections into mutliple AD-networks
(a gateway machine, or a common server that servers multiple, disjoint
AD domains).


I don't think this is everything. IIRC, connection-specfic DNS suffixes 
are candidates for the client to perform DDNS updates, depending on your 
configuration. And this, of course, is where the thread has spent much 
of it's time.



AD network. There should be only one DNS namespace.


Yes. We have independent research groups who run their own private AD 
who painted themselves into this corner. It's extremely difficult to get 
out of.



A general observation:
If find a high number of DNS admins in AD networks that have the
preception that the earth, pardon DNS, is flat. It is not, it is a
hierarchy :). And every attempt too make it appear flat creates problems.


I don't think this accurately describes the issue, though I think I know 
what you mean.


I think the issue is that AD servers and clients make it EXTREMELY 
DIFFICULT to run what you and I would describe as a best-practice DNS, 
due to the above mentioned plethora of things you have to get "just 
right", and the extremely awkward ways of doing so.


In addition, having adopted Kerberos and DNS in Windows 2000, Microsoft 
then went and ignored it in lots of places, so having broken DNS isn't 
the showstopper it would be. Example: Windows does *not* use the DNS 
name of a CIFS server to obtain a kerberos ticket. It uses the name the 
CIFS server claims in the SMB connection setup. Which is horribly insecure.


Hell, if you've got WINS running and broadcast netbios, I think it's 
still possible to log in with *no* working DNS at all.


So the pressure on AD admins to "get it right" just isn't there, and 
thus the knowledge base isn't either :o(


If someone can give pointers to comprehensible docs about how to make 
all this work in *all* the places it needs to, I'd be really interested. 
Because it'd be great to have a subdomain at our site that clients just 
register themselves into, and it all just work.


Cheers,
Phil
___
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: transparent DNS load-balancing with a Cisco ACE

[Phil Mayers]

On 10/19/2012 07:25 PM, John Miller wrote:


Here's a question, however: how does one get probes working for a
transparent LB setup?  If an rserver listens for connections on all
interfaces, then probes work fine, but return traffic from the uses the
machine's default IP (not the VIP that was originally queried) for the
source address of the return traffic.


I'm not sure I understand this.

If a DNS request comes in on a particular IP, bind should reply from 
that IP, always. If it doesn't, something is going seriously wrong.



What have people done to get probes working with transparent LB?  Are
any of you using NAT to handle your dns traffic?  Not tying up NAT
tables seems like the way to go, but lack of probes is a deal-breaker on
this end.


We didn't have to do anything special, and I'm not sure why you have 
either. Our probes are just:


probe tcp TCP_53_RECDNS
  ip address 
  port 53
  interval 10

serverfarm host INTERNAL-DNS
  transparent
  predictor leastconns
  probe TCP_53_RECDNS
  rserver  53
inservice

The ACE uses ARP to discover the destination MAC of the private IP, but 
sends an IP packet to that MAC with a destination of the public IP. The 
DNS reply comes back from that, and all is well.


I get the feeling I'm not understanding what isn't working for you; can 
you describe the failure in more detail? What server OS are you running, 
and can you describe the network config?


Cheers,
Phil
___
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: ISC Bind in Active Directory

[Phil Mayers]

On 10/25/2012 08:44 PM, Kevin Darcy wrote:

On 10/24/2012 6:02 PM, Phil Mayers wrote:



Hell, if you've got WINS running and broadcast netbios, I think it's
still possible to log in with *no* working DNS at all.


At the risk of getting *totally* off-topic, no-one who cares about
security or about broadcast traffic on their LANs would even consider
allowing WINS to function in their enterprise. It can (and should) be
disabled via registry key and/or DHCP options, and left in the dustbin
of ancient IT history.


Do you mean WINS, or broadcast netbios? Because the two are different.

I don't disagree that broadcast netbios probably should be disabled 
(though it's not at our site, for historical reasons, and I'm not sure 
I'm willing to take on the monumental task of disabling it).


WINS is slightly different, and the main reason to disable it is that it 
hides misconfigurations by allowing non-DNS hostname lookups on windows 
machines.

___
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: ISC Bind in Active Directory

[Phil Mayers]

On 10/27/2012 04:28 PM, Chuck Anderson wrote:

I don't disagree that broadcast netbios probably should be disabled
(though it's not at our site, for historical reasons, and I'm not
sure I'm willing to take on the monumental task of disabling it).

WINS is slightly different, and the main reason to disable it is
that it hides misconfigurations by allowing non-DNS hostname lookups
on windows machines.


Easy to disable both of those, just set these DHCP options in your
server:

option netbios-node-type 2;
option netbios-name-servers 0.0.0.0;


It is easy, but whether it's safe is another matter.

There are, sadly, still current-generation 3rd party applications that 
rely on NetBIOS. I'm assured by my colleagues in our OS Admin group that 
applications exist which will only take old-style, downlevel domain 
names, and not DNS-style realms. These apps can therefore *only* find 
domain controllers by NBNS.

___
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 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: 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: Need to improve named performance

[Phil Mayers]

On 12/11/12 15:23, Ed LaFrance wrote:


I really don't need this kind of logging in the messages log. I can turn
on query logging in the named.conf if I need more detail on named. I
think the simplest thing would just be to have an exclusion in the
syslog config for named. I confess some general ignorance, so perhaps


Don't do that. Instead, configure named to not syslog if you don't want 
it to. Maybe log to files from within named, which is quicker.



you know the directive for that?


As per the ARM:

http://www.isc.org/files/arm94_0.html#id2574861

...the defaults are:

"""
Only one logging statement is used to define as many channels and 
categories as are wanted. If there is no logging statement, the logging 
configuration will be:


logging {
 category default { default_syslog; default_debug; };
 category unmatched { null; };
};
"""

You can easily change this so that queries aren't logged to syslog. For 
example:


logging {
 channel query_log { file "logs/query.log"; versions 4; size 10m; };
 category queries { query_log; };
 category default { default_syslog; default_debug; };
 category unmatched { null; };
};

I would recommend tuning this further, as other log categories can 
generate a lot of output too. In fact, unless you need to, I would not 
use syslog for named at *all* e.g.


logging {
 channel query_log { file "logs/query.log"; versions 4; size 10m; };
 channel named_log { file "logs/named.log"; versions 4; size 10m; };
 category queries { query_log; };
 category default { named_log; };
};
___
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: User wanting to use a .local domain to host DNS

[Phil Mayers]

On 14/11/12 15:39, Kevin Darcy wrote:


I stopped reading as soon as I saw the requirement to add a NetBIOS
name, being overpowered by the stench of obsolescence. Does anyone


As per our recent thread, there's load of (recent, modern) stuff that 
still uses NetBIOS. Sadly.



actually run "2000" or "2003" versions of Microsoft products any more?


Yes.


Does Microsoft even support those versions?


No. But other vendors support products which only run on those versions.
___
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: User wanting to use a .local domain to host DNS

[Phil Mayers]

On 14/11/12 15:02, King, Harold Clyde (Hal) wrote:

I'm a bit confused by a user request. I think he is trying to keep some
hosts on the private side of DNS, but he wants to use a DNS name like
host.sub.local. I do not know of the use of the .local TLD except in
bonjure. Can anyone shed some light on the use of the .local TLD?


Yes - going down this route is a mistake. Don't do it. I speak from 
personal experience.


First, it conflicts with a possible future standardisation of mDNS.

Second, if you ever need to bring the hosts into your "real" DNS at a 
future date, you'll find you've made your life really hard, needing 
DNSSEc trust anchors, forwarders/stub statements, and so on.


Pick a private sub-domain of a *real* domain that *you* own e.g. if you 
are "example.com", pick:


sub.private.example.com

...and sidestep this at the planning stage. You can easily make that 
zone hidden by delegating it to nameservers which are only reachable 
from the appropriate places, or by using "allow-query" ACLs or similar.

___
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: rsa_sign.c:263

[Phil Mayers]

On 14/11/12 16:19, Daniel Ryšlink wrote:

Hello,

I started to see a flood of these errors after upgrading to the latest
BIND 9.9.2:

14-Nov-2012 17:14:15.304 general: warning: RSA_verify failed
14-Nov-2012 17:14:15.304 general: info: error:04077068:rsa
routines:RSA_verify:bad
signature:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/rsa/rsa_sign.c:263:


It's on FreeBSD 8.3-RELEASE-p4.

It's probably related to DNSSec validation (the server has validation
enabled), but I thought someone here might have a better idea about the
exact cause.


This has been discussed on the list. It's a log message they made too 
noisy, and will be fixed in the next version IIRC.

___
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: Change in statistics format

[Phil Mayers]

On 15/11/12 16:44, John Miller wrote:

Hello everyone,

When did BIND 9 switch over from the older



I think that was *years* ago?


I'm getting ready to file a bug for our monitoring software (Hyperic
HQ), because it only reads the older format, and wanted to be sure I had
my ducks in a row.


You might want to ask them to parse the XML statistics channel, rather 
than the human-readable stuff. It's obviously machine-readable, and 
contains a *lot* more granular stuff.

___
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: First usage of BIND9

[Phil Mayers]

On 11/25/2012 04:12 PM, Daniele Imbrogino wrote:

Using Wireshark I can see that there are queries from my IP to a
root-server and replies in the reverse way, but then dig always fails
with a SERVFAIL. Why?


iptables?
___
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: First usage of BIND9

[Phil Mayers]

On 11/25/2012 04:38 PM, Daniele Imbrogino wrote:

There are no rules in iptables, and they accept everything by default.



To debug this further you may need to look in the bind logs and/or run 
it under debug mode. Ensure the packet is actually being received by the 
bind process.


You should also follow the advice others have given in the thread of 
reading the ARM for your version and using a valid minimally-caching 
named.conf. Don't run without a config - it's not a good idea, you're 
dependent on compiled-in defaults which may not be consistent across 
systems, distributions and package versions.

___
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: First usage of BIND9

[Phil Mayers]

On 11/25/2012 04:33 PM, Phil Mayers wrote:

On 11/25/2012 04:12 PM, Daniele Imbrogino wrote:

Using Wireshark I can see that there are queries from my IP to a
root-server and replies in the reverse way, but then dig always fails
with a SERVFAIL. Why?


iptables?



It has been pointed out to me off-list that iptables should not cause 
SERVFAIL - my mistake.


So, advice to OP stands: use a known-good caching nameserver config 
appropriate for your version of bind, as previously recommended in the 
thread. If that still fails, search the logs or run in debug mode e.g. 
"named -g -d 10" and see if the cause is obvious. If not, come back with 
the named.conf.

___
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

"rndc sign", "auto-dnssec maintain" and TYPE65534 record "stickyness"?

[Phil Mayers]

All,

Up front, I should note that this was on a hidden master server which 
was running 9.7.0 (since updated). So it may not work this way on 
current versions of bind.


We (well, I) had a little accident recently when rolling a ZSK. We use 
"auto-dnssec maintain" like so:


zone "blah" {
  file "zones/blah/zone";
  auto-dnssec maintain;
  key-directory "zones/blah";
  allow-update { ... };
  type master;
};

The zones are initially signed offline using "dnssec-signzone" using the 
"-j" option so that incremental re-signing is evenly spread over time.


My normal system for doing a ZSK rollover is as follows:

cd /var/named/data/zones/blah
dnssec-keygen ...
dnssec-settime -P now -A none K

...then wait until the new DNSKEY has propagated, and:

dnssec-settime -A now K && dnssec-settime -I now K

...then wait 30 days until bind has incrementally re-signed the entire 
zone and the old key is not in use + TTLs, then:


dnssec-settime -D now K


Unfortunately this time, I made a mistake. After swapping the active 
keys, I foolishly ran:


rndc sign THEZONE

Somehow the notion had occurred that this would make it load the new 
keys, despite me knowing this is not the case. Instead, this immediately 
signed every record in the zone with the new key, which doubled the size 
of the zone and blew away any signing jitter I had.


[Obviously what I wanted was "rndc loadkeys"]


After recovering by reverting the active/inactive keys and running "rndc 
sign" again, two problems emerged:


 1. Despite the old key having a create/publish/active time in the 
past, and no other times, bind stopped incremental re-signing, which I 
only noticed close to the disaster point. It would sign new records 
added via DDNS, but not regenerate signatures. The daemon had been 
completely restarted, so it wasn't a stuck internal state - it must have 
been an attribute of the zone. I assume it had stopped signing because 
it was waiting on the next item...


 2. When I tried to resume the process a few days later using the same 
"new" key, the "full resign" started again, straight away, despite me 
not having made the error of doing "rndc sign".



I assume both problems are related, and were caused by the TYPE65534 
records, plural, which persisted in the zone after the original mistake:


  TYPE65534 \# 5 ( 0512870001 ) => old key id# 4743
  TYPE65534 \# 5 ( 05B98E ) => new key id# 47502

My question is this: how could I have avoided the two problems that 
occurred the *second* time I tried this?


Presumably I needed to make the zone completely forget about the new key 
ID, which would have removed the relevant TYPE65534 record - but would 
that have re-started the incremental re-signing with the old key?


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

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

Re: "rndc sign", "auto-dnssec maintain" and TYPE65534 record "stickyness"?

[Phil Mayers]

On 27/11/12 09:13, Cathy Almond wrote:


It's tricky to answer your questions since this was on BIND 9.7.0 which
has been substantially updated between 9.7.0 and 9.7.7 (the CHANGES log
of 9.7.7 might give you some clues).  But also of particular relevance
to this would be the change in how automatic resigning is done when
there's a key rollover.  It was blogged about here:

https://www.isc.org/community/blog/201006/bind-972-and-and-automatic-dnssec-signing

Hope this helps.



Thanks - that's a very helpful and relevant document.

It sounds like what I ran into was actually the *expected* behaviour for 
that version. That being the case, I'm puzzled why it didn't happen with 
previous two ZSK rollover I did.


However, given there have been extensive changes, I'll just re-test on 
the bench and write it off to experience.


Cheers,
Phil
___
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: Can't find named_dump.db

[Phil Mayers]

On 03/12/12 15:41, Daniele Imbrogino wrote:

Using BIND 9.8.1 on Ubuntu 12.04, I try to save the server cache using
the command "sudo rndc dumpdb -cache" (without quotes, obviously), but
then I can't find the file "/etc/bind/named_dump.db" being "/etc/bind/"
the working directory of the server.


Check that named has permissions to write to that file. It would be 
unusual for it to have write on /etc in my experience.

___
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: DNS Blackholing

[Phil Mayers]

On 12/04/2012 02:44 AM, John Hascall wrote:


We have found that RPZ works quite well for us.
We have 366825 names in our RPZ zone at present
and scaling thus far has been a non-issue.ot (


Likewise. We have 675k entries in an RPZ zone, and performance is fine.

It's genuinely surprising how many hits we get on the "Badness" host (we 
rewrite the RPZ result to a CNAME aimed at an internal host) even from 
machines which are clean, with sensible users at the keyboard. There's a 
lot of slime on the internet that you can step in and track into the 
house...


It also amazes me how many people will install spyware in exchange for a 
web browser "search toolbar". Sigh...

___
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: DNS Blackholing

[Phil Mayers]

On 12/05/2012 06:10 AM, Nick Edwards wrote:

Hi All,

Is there a way for RPZ zone file to act on  domain AND subdomains
without using two separate entries?

At present I can only get them to match on one or the other unless I do
example.comblah
*.example.com  blah

I'm sure I've missed the obvious, but thought I'd ask


I don't think so. I think you need two entries.

AFAICT the expectation is that (much) higher-level tooling will be used 
to generate and update the RPZ zonefile, and handle the expansion of 
"name-or-suffix" into two entries.

___
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: DNS Blackholing

[Phil Mayers]

On 12/04/2012 06:35 PM, Barry S. Finkel wrote:


A question from the OP that has not yet been answered -
Make the zones masters on all servers.


Surely not for RPZ? The whole point with RPZ is that you have one zone 
containing all the blacklists, master in one place, and slave it in all 
the others.


For traditional DNS blacklisting (one zone per blacklisted name/suffix) 
sure, but I'm honestly not sure why anyone would start out down that 
road today with RPZ available.

___
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: DNS Blackholing

[Phil Mayers]

On 12/05/2012 11:45 AM, Noel Butler wrote:


RPZ:
dig bobi.at
;; Query time: 996 msec


You're correct that blackhole zones and RPZ have different performance 
characteristics. For others reading, this is because with RPZ, the real 
name is queried first, then RPZ applies to the answers, so if the real 
name is slow, you'll see slowness until it's in-cache.


However, once the real name is cached, 2nd and subsequent queries are 
fast. So, querying an RPZ-blocked name is at worst as slow as the 
unblocked name, and fast once it's in-cache.


Clearly a blackhole zone won't trigger a recursive query and will always 
answer immediately.



(avg response time it seems for RPZ'd zones)

So it sure as hell doesnt work the same as a forged "empty" zones


Sure.



RPZ is awesome if you want to wallgarden a hostname, but for just speedy
dropping, empty zone beats it hands down even if it is messier requiring
its own zone.


I gues this depends on your query pattern. I observe fast queries on 2nd 
access to RPZ blocked names, and we see a lot of hits to a small 
percentage of the names.


Obviously if people want to use blackholed zones, they can. In our case, 
the value of RPZ is that we can slave a feed from a trusted provider, 
which is far harder to manage if you're having to generate 675,000 
blackhole zones and run "rndc reconfig" every few minutes to catch 
fast-flux DNS for botnet control channels.


But I take your point - people need to understand the characteristics of 
the feature before deciding what's 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: how t orestrict nsupdate to a single A or PTR record ?

[Phil Mayers]

On 12/05/2012 07:29 PM, fddi wrote:

Hello, I have a domain called mydomain.org

I would need a way to allow access with nsupdate not to the entire
domain mydomain.org
but only to specific hosts and specific IP Address do be modified using
nsupdate.


here is my config

zone "mydomain.org" IN {
 type master;
 allow-query { any; };
 file "mydomain.org.db";
 update-policy {
 grant mykey. subdomain mydomain.org. A TXT CNAME;
 };
};

but in this way anyone can modify any hosts in the domain.


No - people with "mykey." can update any A/TXT/CNAME records at or under 
mydomain.org. Subtle difference.



How can I restrict and allow to modify only specific hosts ?


Name them in the policy.



for example I would like to restrict to modify only host1.mydomain.org
with a given key.

is it possibile ?


Erm, yes. Just use "name" rather than subdomain, and specify the name 
you want. Have you *read* the section on "update-policy" in the ARM?

___
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: RHEL, Centos, Fedora rpm 9.9.2-p1

[Phil Mayers]

On 12/05/2012 04:46 AM, Carl Byington wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

http://www.five-ten-sg.com/util/bind-9.9.2-0.2.P1.fc18.src.rpm


Carl,

Thanks for this. One minor thing - the -P1 is missing from the embedded 
tarball. I think there might be something going on with the %{VERSION} 
macro?

___
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: Getting RPZ statistics

[Phil Mayers]

We do much the same.

If you have a pointer to the technique you're using to distinguish images and 
serve up replies, i'd be interested to see it.

John Hascall  wrote:

>
>We point our DNS-RPZ records at a server ("here-be-dragons")
>that records connections at that point.  Also the webserver
>listening there sends back either and image or javascript+html
>which explains to the user the reason they are not seeing the
>webpage they expect.
>

-- 
Sent from my mobile device, 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: Requesting tips on setting TTLs so that expired RRSIG data doesn't stay in the zone

[Phil Mayers]

On 12/14/2012 10:48 AM, GS Bryan wrote:

Reference: http://dnssec-debugger.verisignlabs.com/imouto.my

How to configure named (version BIND 9.9.2-P1-RedHat-9.9.2-2.P1.el5)
so that expired RRSIG data doesn't stay in the zone? I heard it has
omething to do with the TTL of the zone (the expiry timer in that
zone's SOA). The named.conf has the 'sig-validity-interval 21 8;' line
it in, so how then I can change the expire timer so that stale RRSIG
data doesn't stay in the zone?


If everything is working right, you shouldn't need to do anything; what 
does the config for the zone look like?

___
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: Disabling A records for IPv6?

[Phil Mayers]

Robin Lee Powell  wrote:

>
>So I've got some IPv6-only VMs set up that need to talk to the
>general internet for things like downloading packages.  As you can
>imagine, this requires that they have NAT64 and DNS64, because lots
>and lots of things are IPv4 only.
>
>The problem is that many things do *stupid shit* when given both A
>and  records for the same request on an IPv6 host.  In
>particular, the issue I'm hitting now is that node.js simply fails
>to try anything but the A record.
>
>I've actually got a workaround for this (puppet the  in
>/etc/hosts with the FQDN of the npm host), but it's kind of
>unfortunate, and it would be nice to fix this at the BIND end if
>possible.
>
>-Robin
>
>___
>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

Really? It is normally the other way round.

One solution that springs to mind - a view that uses rpz to filter 0.0.0.0/0 to 
NODATA but leaves v6 untouched.
-- 
Sent from my phone. 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: Disabling A records for IPv6?

[Phil Mayers]

Not hard - rpz zone with a single record will do it. I'm not typing on an ideal 
device to give an example right now, I'm afraid ...

Mark is of course correct that v6-only is a struggle right now and that fixing 
the apps is the proper solution.  But I'm

Robin Lee Powell  wrote:

>On Fri, Dec 28, 2012 at 07:57:24PM +, Phil Mayers wrote:
>> Robin Lee Powell  wrote:
>>
>> >
>> >So I've got some IPv6-only VMs set up that need to talk to the
>> >general internet for things like downloading packages.  As you
>> >can imagine, this requires that they have NAT64 and DNS64,
>> >because lots and lots of things are IPv4 only.
>> >
>> >The problem is that many things do *stupid shit* when given both
>> >A and  records for the same request on an IPv6 host.  In
>> >particular, the issue I'm hitting now is that node.js simply
>> >fails to try anything but the A record.
>> >
>> >I've actually got a workaround for this (puppet the  in
>> >/etc/hosts with the FQDN of the npm host), but it's kind of
>> >unfortunate, and it would be nice to fix this at the BIND end if
>> >possible.
>>
>> Really? It is normally the other way round.
>
>Yeah, but pure IPv6 hosts are still relatively uncommon.
>
>> One solution that springs to mind - a view that uses rpz to filter
>> 0.0.0.0/0 to NODATA but leaves v6 untouched.
>
>How hard is that to set up?
>
>-Robin

--
Sent from my mobile device, 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: Disabling A records for IPv6?

[Phil Mayers]

[Grumble stupid mobile devices ...]

...I'm assuming you're deliberately engaging in a learning exercise and don't 
want the rest of your experiments to be held up waiting for this one issue to 
be fixed. But please do hassle the app vendor/devs to fix their broken stuff.

Tbh I'm still a bit dubious - node is pretty new and it seems crazy such a new 
framework would spoon up getaddrinfo() - are you sure it isn't an os or stack 
config issue?

Phil Mayers  wrote:

>Not hard - rpz zone with a single record will do it. I'm not typing on
>an ideal device to give an example right now, I'm afraid ...
>
>Mark is of course correct that v6-only is a struggle right now and that
>fixing the apps is the proper solution.  But I'm
>

-- 
Sent from my mobile device, 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: rndc reconfig does not work

[Phil Mayers]

On 12/29/2012 11:09 AM, Carsten Strotmann wrote:


For some configuration changes (for example change of IP addresses to
listen on, change of fundamental operations, new log-file entries) the
BIND nameserver requires a full restart, esp. if BIND is running as an
non-privileged user (not "root"), as some configuration steps require
root access (like opening network sockets on port 53).


Just to note, this specific change (new IPs) can be done with just 
reconfig on some platforms (e.g. Linux) as bind uses underlying OS 
mechanisms to listen on ports < 1024 as an unprivileged user.


But the general point stands that "reconfig" only does a subset of tasks.
___
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: query about EDNS UDP Packet

[Phil Mayers]

On 12/31/2012 10:54 AM, Gaurav Kansal wrote:

I just want to test whether this limit is within my organization.

Is any method available by which I can check this?




https://www.dns-oarc.net/oarc/services/replysizetest


___
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: Distribute named.conf

[Phil Mayers]

On 03/01/13 11:06, Joerg Stephan wrote:

Hi all,


we are currently using PowerDNS on our 12 Nameservers. Now we are
thinking about a migration to bind.

So we are seeking a way to distribute the named.conf.x for the
several zonfiles. Currently this is solved by powerdns via mysql
replication. Is there any tool in bind we could use. Generating the
conf file and syncing via ssh/rsync is discussed on our side, and we
hoped that there is a "nicer" way.


There are innumerable options for doing this. As written, the question 
is way too vague - "how do I copy a file".


FWIW we use a cron job on the nameservers to pull a .csv file from a 
master server, which builds the named.conf and does and "rndc reconfig" 
(if it has changed). But there are many, many ways to do this...




Many registrys are testing the dns server if the zone is available
during the registration. Genrating the new files via cron would cause
the registration to fail.


So don't use cron. Push the creation from a central server and then 
register the domain.


You may also want to investigate "rndc addzone" in the new version of 
bind. Something like:


# add the zone locally
rndc addzone ... "{ type master; allow-transfer ...; ...};"

# add zone on all slaves
for slave in server1 server2
do
  ssh root@$slave 'rndc addzone .. "{ type slave; master x.x.x.x; ...};'
done

# contact registrar
./do_register
___
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