Re: isc domain lookup

[Phil Mayers]

On 16/05/14 05:38, Yossi Eskenazi wrote:


but there are many domains which cannot get through. The problem
appeared rather recently, so I suspect that an update in a firewall
brand, or a dns server update is causing this.


Almost certainly not. It's very likely your network provider or one of 
their upstreams put this block in, in response to a reflection attack; 
many attackers sems to use queries for isc.org (and others) for some reason.


Ask your provider what they've done, and to exclude you from it (better 
yet, fix their broken filter)

___
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

DNSSEC: recover from missing keys

[Klaus Darilion]

Hi!

During rollover testing I quite often delete keys without properly
settings the timestamps in the keys - it is testing only.

This leads to such errors:

error reading private key file example.com/NSEC3RSASHA1/64337: file not
found

To recover and restart my testing I:
- remove the zone from the config
- rndc reconfig
- delete the signed zone and journal files
- ad the zone to the config
- rndc reconfig

This works but is cumbersome. Is there a method to instruct Bind to just
remove all references to the missing keys and start a fresh signing with
the existing keys?

Thanks
Klaus
___
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: Point domain name of my zone to name in somebody else's zone?

[Sam Wilson]

In article ,
 Kevin Darcy  wrote:

> On 5/9/2014 6:59 AM, Tony Finch wrote:
> > Dave Warren  wrote:
> >> I actually think that MX records were a boneheaded thing to do, had email
> >> started using SRV records in the first place we might be in a position now
> >> where using SRV records is the defacto standard if not the actual standard 
> >> for
> >> all services. (No offense to the folks that made MX records happen, I 
> >> realize
> >> that in historical context it was the correct decision and it solved the 
> >> very
> >> immediate problem -- I'm just saying that in an ideal world, SRV records
> >> instead of MX records would solved the same problem in a more generic 
> >> fashion,
> >> and would have pushed us to a better place for other protocols)
> > It is interesting to look at the old RFCs and see how many false starts it
> > took to get to the MX design. Mail was the first heavily virtualized
> > application so I think their failure to generalize was forgivable,
> > especially since they were also dealing with the massive problem of
> > gatewaying between dozens of balkanized mail networks.
> >
> > http://stuff.mit.edu/afs/athena/reference/net-directory/documents/JANET-Mail
> > -Gateways.ps
> >
> Indeed. Hindsight is 20/20. Mail was the "killer app" for the early 
> Internet, and providing a way to route it over the Internet, with 
> automatic load-balancing and failover, was a major achievement. Sure, 
> the IETF could have spent a few more years coming up with a "generic" 
> way to do things, throwing in -- as SRV eventually did -- port 
> reassignment, weighting and namespace semantics, but how much would that 
> delay have stunted the growth of the nascent technology? Maybe it would 
> have resulted in OSI/X.400 surpassing SMTP as the predominant mail 
> transport, and we'd all be *miserable*.

Actually some of us who were already using a more sophisticated naming 
scheme[1] were disappointed that the DNS was really only a replacement 
for HOSTS.TXT.  That was one of the few downsides of joining the 
Internet.

Sam

[1]  3rd paragraph

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

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