Re: per record responses based on originating IP

[Angus Clarke]

Hello

I found that knot's geoip module can modify responses to individual records 
based on the source address of the client through the module's "net" directive 
and have successfully tested the modification of NS responses based on the 
client's source subnet - it seems to do exactly what I want.

I had a quick check of the bind geoip module but the example given in the 
documentation suggests presenting an entire zone as an alternative view.

Thanks for taking the time with me on my quest, but I think I'll further 
investigate knot at this time.

knot geoip module overview:
https://blog.apnic.net/2018/11/14/geoip-in-knot-dns-2-7/

Thanks
Angus


From: bind-users  on behalf of Nick Tait via 
bind-users 
Sent: 16 May 2022 13:55
To: BIND Users Mailing List 
Subject: Re: per record responses based on originating IP

On 16/05/22 20:05, Angus Clarke wrote:
As mentioned in a separate reply to Grant, the goal is to have (amongst other 
things) local recursors "find" the locally deployed authoritative servers 
through NS records. What hasn't been mentioned is that I am also looking to 
simplify configuration management by means of a single set of data which can be 
deployed to all authoritative servers - I don't think the RPZ solution proposed 
by Nick achieves that.

That being said, can RPZ-CLIENT-IP be a subnet? I don't think it can.

Hi Angus.

Thanks for clarifying. Based on what you've said, what I proposed probably has 
slightly more merit than I concluded, although admittedly it doesn't quite tick 
all the boxes...

Firstly, yes RPZ-CLIENT-IP can be a subnet. IPv4 addresses are represented as 
prefixlength.B4.B3.B2.B1.rpz-client-ip. In my examples I was specifying a 
single host which is why the RPZ-CLIENT-IP records all started with 32.

Secondly, RPZs are more commonly used on recursive resolvers rather than the 
authoritative nameservers for the zone, although in your case if you are 
wanting to change the answer that an authoritative nameserver gives to the NS 
question from the recursive resolver, then it probably makes the most sense to 
put the RPZ on the authoritative nameserver. In this case you'd also need to 
specify "recursive-only no". (FYI Default behaviour is to apply RPZ rewriting 
to queries with RD=1 and DO=0.)

However this still doesn't meet your requirement for "a single set of data", 
unless you are only talking about zone data, and in that case you could 
replicate all the RPZ zone files to all authoritative nameservers, and then 
configure each server to specify only one of these in its "response-policy" 
configuration?

But the anycast suggestion sounds like it has the most merit? Or at least it 
sounds the coolest to me. :-)

Nick.

P.S. I don't think this will be useful to you, but FWIW... if your goal is 
simply to have the recursive resolvers use a specific subset of nameservers for 
specific zones, then there is yet another option: static-stub zones. 
Static-stub zones allow you to effectively override the authoritative 
nameserver that will be used for a particular zone. So you could configure the 
static-stub zone on the recursive resolver, and that would point to the local 
authoritative nameserver(s). However the main drawback with static-stub zones 
is that you need to create a static-stub zone (on the local resolver) for every 
authoritative zone that you are doing this with, so it probably isn't practical 
if you have many zones or are adding or removing zones frequently?
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: per record responses based on originating IP

[Nick Tait via bind-users]

On 16/05/22 20:05, Angus Clarke wrote:
As mentioned in a separate reply to Grant, the goal is to have 
(amongst other things) local recursors "find" the locally deployed 
authoritative servers through NS records. What hasn't been mentioned 
is that I am also looking to simplify configuration management by 
means of a single set of data which can be deployed to all 
authoritative servers - I don't think the RPZ solution proposed by 
Nick achieves that.


That being said, can RPZ-CLIENT-IP be a subnet? I don't think it can.


Hi Angus.

Thanks for clarifying. Based on what you've said, what I proposed 
probably has slightly more merit than I concluded, although admittedly 
it doesn't quite tick all the boxes...


Firstly, yes RPZ-CLIENT-IP can be a subnet. IPv4 addresses are 
represented as prefixlength.B4.B3.B2.B1.rpz-client-ip. In my examples I 
was specifying a single host which is why the RPZ-CLIENT-IP records all 
started with 32.


Secondly, RPZs are more commonly used on recursive resolvers rather than 
the authoritative nameservers for the zone, although in your case if you 
are wanting to change the answer that an authoritative nameserver gives 
to the NS question from the recursive resolver, then it probably makes 
the most sense to put the RPZ on the authoritative nameserver. In this 
case you'd also need to specify "recursive-only no". (FYI Default 
behaviour is to apply RPZ rewriting to queries with RD=1 and DO=0.)


However this still doesn't meet your requirement for "a single set of 
data", unless you are only talking about zone data, and in that case you 
could replicate all the RPZ zone files to all authoritative nameservers, 
and then configure each server to specify only one of these in its 
"response-policy" configuration?


But the anycast suggestion sounds like it has the most merit? Or at 
least it sounds the coolest to me. :-)


Nick.

P.S. I don't think this will be useful to you, but FWIW... if your goal 
is simply to have the recursive resolvers use a specific subset of 
nameservers for specific zones, then there is yet another option: 
static-stub zones. Static-stub zones allow you to effectively override 
the authoritative nameserver that will be used for a particular zone. So 
you could configure the static-stub zone on the recursive resolver, and 
that would point to the local authoritative nameserver(s). However the 
main drawback with static-stub zones is that you need to create a 
static-stub zone (on the local resolver) for every authoritative zone 
that you are doing this with, so it probably isn't practical if you have 
many zones or are adding or removing zones frequently?
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: per record responses based on originating IP

[Angus Clarke]

Thanks for taking the time Nick and Grant,

As mentioned in a separate reply to Grant, the goal is to have (amongst other 
things) local recursors "find" the locally deployed authoritative servers 
through NS records. What hasn't been mentioned is that I am also looking to 
simplify configuration management by means of a single set of data which can be 
deployed to all authoritative servers - I don't think the RPZ solution proposed 
by Nick achieves that.

That being said, can RPZ-CLIENT-IP be a subnet? I don't think it can.

So aside from the anycast suggestion, is there anything else I can look at with 
bind itself?
 - I didn't find much with respect to limiting a sortlist response to the first 
X responses.
 - Admittedly I don't very well understand the RPZ documentation but I get the 
feeling it is not the way to go.
 - Views seem to require duplications of the whole zonefile (this might be the 
only way to go) - I did find mention of "attach-cache" but this seems to be 
more about performance than anything else. I could create views for all of my 
networks - this is automatable.

Thanks
Angus




From: bind-users  on behalf of Nick Tait via 
bind-users 
Sent: 14 May 2022 02:34
To: bind-users@lists.isc.org 
Subject: Re: per record responses based on originating IP

On 13/05/22 09:02, Grant Taylor via bind-users wrote:
On 5/12/22 2:41 PM, Nick Tait via bind-users wrote:
This sounds like exactly the sort of use case for Response Policy Zones:

How are you going to have RPZ return different addresses for different clients? 
 Are you suggesting use different RPZs with different contents for different 
clients?

Yes, although now that I think through the details it turns out to be much 
messier than I first thought, because there doesn't seem to be a way to specify 
"not" in the RPZ...

Also I should point out that I'm assuming that a PASSTHRU result in one RPZ 
will still result in subsequent RPZs being processed. I haven't actually tested 
this, so its possible I'm misunderstanding the documentation?

Anyway in the interests of following this all the way though, let's assume you 
had 3 clients and you wanted them to each receive a different answer to the 
query 
"www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0>":

Suppose their IP addresses are:

A = 192.0.2.10
B = 192.0.2.20
C = 192.0.2.30

Then, if I'm not mistaken, you could create 3 RPZ zones:

Zone file for "a.rpz.mylocaldomain.com" contains (in addition to SOA, etc):

; Don't overwrite the answer for queries received from clients B & C
32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru.

; Change the answer to the question 
www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0>
www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0>
 IN A 10.0.0.1

Zone file for "b.rpz.mylocaldomain.com" contains (in addition to SOA, etc):

; Don't overwrite the answer for queries received from clients A & C
32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru.

; Change the answer to the question 
www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0>
www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0>
 IN A 10.0.0.2

Zone file for "c.rpz.mylocaldomain.com" contains (in addition to 

Re: per record responses based on originating IP

[Grant Taylor via bind-users]

On 5/15/22 7:28 AM, Angus Clarke wrote:

Hi Grant


Hi Angus,


maybe, I'm reading up ...

poking around the manual, are you alluding to the "sortlist" directive?


Yes, that's what I was referring to.

So the concern with returning an ordered RRset is that the set could be 
large:


Okay.

I assume that's opposed to returning small distinct / unique RR sets 
with per client granularity.


The intention is that each private site/network will have its own DNS 
server pair and that local recursors resolve all private zones from that 
local pair. So things like NS records would be in scope for the ordered 
RRset response. With more sites come more DNS pairs and therefore more 
NS records to be added to the RRset. Maybe I can limit a RRset response 
to the first X number of entries?


Hum.

With this description in mind, I'd be tempted to do something with the 
anycast methodology that was recently discussed.  Return one small RRset 
that references the fixed set of any cast NS IPs.  Then routing at each 
site will get clients to the local instance of those anycasted IPs.


This would probably scale a lot better.


Thanks


:-)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: per record responses based on originating IP

[Angus Clarke]

Hi Grant

> Before stepping up to views I'd stop to ask the question, would
> returning multiple IPs in a preferred sort order suffice?

maybe, I'm reading up ...

> BIND has the ability to sort RRs differently based on different client
> criteria.

poking around the manual, are you alluding to the "sortlist" directive?

> If sorting of replies won't suffice, please provide a hypothetical
> example of a couple of different clients & responses for an example RR.

So the concern with returning an ordered RRset is that the set could be large:
The intention is that each private site/network will have its own DNS server 
pair and that local recursors resolve all private zones from that local pair. 
So things like NS records would be in scope for the ordered RRset response. 
With more sites come more DNS pairs and therefore more NS records to be added 
to the RRset. Maybe I can limit a RRset response to the first X number of 
entries?

Thanks
Angus


From: bind-users  on behalf of Grant Taylor 
via bind-users 
Sent: 12 May 2022 18:11
To: bind-users@lists.isc.org 
Subject: Re: per record responses based on originating IP

On 5/12/22 6:30 AM, Angus Clarke wrote:
> Hello

Hi,

> With bind (and others) it seems that DNS views are the way to go,

Before stepping up to views I'd stop to ask the question, would
returning multiple IPs in a preferred sort order suffice?

BIND has the ability to sort RRs differently based on different client
criteria.

> Does bind have some simple way to respond differently based on source
> address but on a per record basis? Or perhaps include a baseline zone in
> a view and separately include differences for that view - something like
> this perhaps?

If sorting of replies won't suffice, please provide a hypothetical
example of a couple of different clients & responses for an example RR.



--
Grant. . . .
unix || die

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: per record responses based on originating IP

[Nick Tait via bind-users]

On 13/05/22 09:02, Grant Taylor via bind-users wrote:

On 5/12/22 2:41 PM, Nick Tait via bind-users wrote:

This sounds like exactly the sort of use case for Response Policy Zones:


How are you going to have RPZ return different addresses for different 
clients?  Are you suggesting use different RPZs with different 
contents for different clients?


Yes, although now that I think through the details it turns out to be 
much messier than I first thought, because there doesn't seem to be a 
way to specify "not" in the RPZ...


Also I should point out that I'm assuming that a PASSTHRU result in one 
RPZ will still result in subsequent RPZs being processed. I haven't 
actually tested this, so its possible I'm misunderstanding the 
documentation?


Anyway in the interests of following this all the way though, let's 
assume you had 3 clients and you wanted them to each receive a different 
answer to the query "www.example.com":


Suppose their IP addresses are:

   A = 192.0.2.10
   B = 192.0.2.20
   C = 192.0.2.30

Then, if I'm not mistaken, you could create 3 RPZ zones:

Zone file for "a.rpz.mylocaldomain.com" contains (in addition to SOA, etc):

   ; Don't overwrite the answer for queries received from clients B & C
   32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
   32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru.

   ; Change the answer to the question www.example.com
   www.example.com IN A 10.0.0.1

Zone file for "b.rpz.mylocaldomain.com" contains (in addition to SOA, etc):

   ; Don't overwrite the answer for queries received from clients A & C
   32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
   32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru.

   ; Change the answer to the question www.example.com
   www.example.com IN A 10.0.0.2

Zone file for "c.rpz.mylocaldomain.com" contains (in addition to SOA, etc):

   ; Don't overwrite the answer for queries received from clients A & B
   32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
   32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru.

   ; Change the answer to the question www.example.com
   www.example.com IN A 10.0.0.3

And then configure BIND to use all three RPZs:

   response-policy {
    zone "a.rpz.mylocaldomain.com";
    zone "b.rpz.mylocaldomain.com";
    zone "c.rpz.mylocaldomain.com";
   };

Scalability is obviously a challenge with this particular solution! :-(

So on reflection, there are probably better solutions to the problem 
that you are trying to solve. Although I don't personally have 
experience with it, wonder if "dnsmasq" might do what you need?


Thanks,

Nick.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: per record responses based on originating IP

[Grant Taylor via bind-users]

On 5/12/22 2:41 PM, Nick Tait via bind-users wrote:

This sounds like exactly the sort of use case for Response Policy Zones:


How are you going to have RPZ return different addresses for different 
clients?  Are you suggesting use different RPZs with different contents 
for different clients?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: per record responses based on originating IP

[Nick Tait via bind-users]

On 13/05/2022 12:30 am, Angus Clarke wrote:
Does bind have some simple way to respond differently based on source 
address but on a per record basis? Or perhaps include a baseline zone 
in a view and separately include differences for that view - something 
like this perhaps?


Hi Angus.

This sounds like exactly the sort of use case for Response Policy Zones: 
https://bind9.readthedocs.io/en/v9_18_2/reference.html#response-policy-zone-rpz-rewriting


Nick.

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: per record responses based on originating IP

[Grant Taylor via bind-users]

On 5/12/22 6:30 AM, Angus Clarke wrote:

Hello


Hi,


With bind (and others) it seems that DNS views are the way to go,


Before stepping up to views I'd stop to ask the question, would 
returning multiple IPs in a preferred sort order suffice?


BIND has the ability to sort RRs differently based on different client 
criteria.


Does bind have some simple way to respond differently based on source 
address but on a per record basis? Or perhaps include a baseline zone in 
a view and separately include differences for that view - something like 
this perhaps?


If sorting of replies won't suffice, please provide a hypothetical 
example of a couple of different clients & responses for an example RR.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: A record for @?

[Tony Finch]

@lbutlr via bind-users  wrote:

> I have a domain that I hot DNS and email for, but not web. I set the A
> record for www.example.com to the IP of the web server with nsupdate,
> removing the old CNAME the pointed to the local webserver, but the web
> monkey for the new website is saying that www has to be a CNAME and the
> @ record should be the A record pointing to the IP.

You can do that, but it might have weird effects if someone tries to send
email to someth...@www.example.com. I generally think it's neater for both
the zone file origin (aka @) and the www subdomain to have A/ records
pointing at the web server.

> I don't think this is right, and if it is I am not sure how to use
> nsupdate to make this change.

@ is just an abbreviation for (in this case) example.com (it's handy for
writing instructions or zone file that work the same for any domain name).

In cases where there isn't an implicit origin, such as nsupdate, you need
to write the records out in full instead, e.g.

www.example.com. CNAME example.com.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
North Foreland to Selsey Bill: Northwesterly, backing westerly or
southwesterly 3 or 4, increasing 4 to 6 later. Smooth or slight,
occasionally moderate later. Showers later. Good.

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: SRV Record Server Availability

[Mark Andrews]

Well mDNS is not DNS.  It is a multicast request to all devices on the local 
network to respond.

To get the functionality being requested in the DNS it requires something to be 
polling the availability of the server listed in the SRV records and to 
add/remove/adjust them depending upon their load/availability.  In reality this 
should not be needed if people would just write client software to properly 
handle multi-homed servers.  There is nothing that say you must wait for a 
connection to timeout before you attempt to connect to a second address.

Happy Eyeballs RFC 8305 (previously RFC 6555) us about starting multiple 
connections across address families and only proceeding with the first that 
connects but there is NOTHING that says you can’t do the similar for all 
addresses independent of address family.

It isn’t hard to write a TCP client that attempts to connect to multiple 
servers simultaneously.

I will admit that it is slightly harder for UDP clients but in most cases it is 
not impossible.

For both protocols you do not wait seconds to get the initial response before 
trying the alternate addresses.  Most of the world is less that 300ms way 
(round trip).

Mark

> On 7 Jan 2021, at 03:42, Andrew P.  wrote:
> 
> Isn't this sort of dynamic functionality (real-time presence or absence of 
> SRV records) what mDNS and the avahi daemon are for?
> 
> 
> From: bind-users  on behalf of Matus UHLAR 
> - fantomas 
> Sent: Wednesday, January 6, 2021 8:51 AM
> To: bind-users@lists.isc.org
> Subject: Re: SRV Record Server Availability
> 
> On 06.01.21 21:41, Wilfred Sarmiento via bind-users wrote:
>> Your understanding is correct, i just thought that SRV can detect whose
>> server is alive so it can choose and provide an answer with the available
>> Server.
> 
> DNS is not designed to provide this functionality. While technically you can
> change contents of DNS depending on which servers are alive and which are
> not, it's almost never a good idea.
> 
> That means, BIND has nothing like this built in.
> 
>>> On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users
>>>  wrote:
>>>> Is DNS Bind SRV record can detect the Server's availability? If yes, how?
> 
>> On Tue, 5 Jan 2021, 23:53 tale  wrote:
>>> Could you provide more information about your goal?  I don't fully
>>> understand the question.
>>> 
>>> For my reading, the answer is basically no, in that an SRV record just
>>> provides data about where.a particular service can be found.  It's up
>>> to other systems to fetch that data and interpret it, including
>>> whether that service is actually available at the given endpoint.  In
>>> its typical operation, BIND will just take whatever name and port the
>>> zone administrator said to provide for that SRV record, and not do any
>>> sort of availability checks on it.
>>> 
>>> However, if you go deep into a far more complicated, custom use of
>>> BIND, you could set up a process that monitors the availability and
>>> changes the SRV record accordingly.
> 
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Microsoft dick is soft to do no harm
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: SRV Record Server Availability

[Andrew P .]

Isn't this sort of dynamic functionality (real-time presence or absence of SRV 
records) what mDNS and the avahi daemon are for?


From: bind-users  on behalf of Matus UHLAR - 
fantomas 
Sent: Wednesday, January 6, 2021 8:51 AM
To: bind-users@lists.isc.org
Subject: Re: SRV Record Server Availability

On 06.01.21 21:41, Wilfred Sarmiento via bind-users wrote:
>Your understanding is correct, i just thought that SRV can detect whose
>server is alive so it can choose and provide an answer with the available
>Server.

DNS is not designed to provide this functionality. While technically you can
change contents of DNS depending on which servers are alive and which are
not, it's almost never a good idea.

That means, BIND has nothing like this built in.

>> On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users
>>  wrote:
>> > Is DNS Bind SRV record can detect the Server's availability? If yes, how?

>On Tue, 5 Jan 2021, 23:53 tale  wrote:
>> Could you provide more information about your goal?  I don't fully
>> understand the question.
>>
>> For my reading, the answer is basically no, in that an SRV record just
>> provides data about where.a particular service can be found.  It's up
>> to other systems to fetch that data and interpret it, including
>> whether that service is actually available at the given endpoint.  In
>> its typical operation, BIND will just take whatever name and port the
>> zone administrator said to provide for that SRV record, and not do any
>> sort of availability checks on it.
>>
>> However, if you go deep into a far more complicated, custom use of
>> BIND, you could set up a process that monitors the availability and
>> changes the SRV record accordingly.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Microsoft dick is soft to do no harm
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: SRV Record Server Availability

[Matus UHLAR - fantomas]

On 06.01.21 21:41, Wilfred Sarmiento via bind-users wrote:

Your understanding is correct, i just thought that SRV can detect whose
server is alive so it can choose and provide an answer with the available
Server.


DNS is not designed to provide this functionality. While technically you can
change contents of DNS depending on which servers are alive and which are
not, it's almost never a good idea.

That means, BIND has nothing like this built in.


On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users
 wrote:
> Is DNS Bind SRV record can detect the Server's availability? If yes, how?



On Tue, 5 Jan 2021, 23:53 tale  wrote:

Could you provide more information about your goal?  I don't fully
understand the question.

For my reading, the answer is basically no, in that an SRV record just
provides data about where.a particular service can be found.  It's up
to other systems to fetch that data and interpret it, including
whether that service is actually available at the given endpoint.  In
its typical operation, BIND will just take whatever name and port the
zone administrator said to provide for that SRV record, and not do any
sort of availability checks on it.

However, if you go deep into a far more complicated, custom use of
BIND, you could set up a process that monitors the availability and
changes the SRV record accordingly.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Microsoft dick is soft to do no harm
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: SRV Record Server Availability

[Wilfred Sarmiento via bind-users]

Hi Tale, Happy new year!

Your understanding is correct, i just thought that SRV can detect whose
server is alive so it can choose and provide an answer with the available
Server.

Thank you!



On Tue, 5 Jan 2021, 23:53 tale  wrote:

> On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users
>  wrote:
> > Is DNS Bind SRV record can detect the Server's availability? If yes, how?
>
> Could you provide more information about your goal?  I don't fully
> understand the question.
>
> For my reading, the answer is basically no, in that an SRV record just
> provides data about where.a particular service can be found.  It's up
> to other systems to fetch that data and interpret it, including
> whether that service is actually available at the given endpoint.  In
> its typical operation, BIND will just take whatever name and port the
> zone administrator said to provide for that SRV record, and not do any
> sort of availability checks on it.
>
> However, if you go deep into a far more complicated, custom use of
> BIND, you could set up a process that monitors the availability and
> changes the SRV record accordingly.
> --
> tale
>

-- 
This e-mail message (including attachments, if any) is intended for the use 
of the individual or the entity to whom it is addressed and may contain 
information that is privileged, proprietary, confidential and exempt from 
disclosure. If you are not the intended recipient, you are notified that 
any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, 
please notify the sender and delete this E-mail message immediately.


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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: SRV Record Server Availability

[tale via bind-users]

On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users
 wrote:
> Is DNS Bind SRV record can detect the Server's availability? If yes, how?

Could you provide more information about your goal?  I don't fully
understand the question.

For my reading, the answer is basically no, in that an SRV record just
provides data about where.a particular service can be found.  It's up
to other systems to fetch that data and interpret it, including
whether that service is actually available at the given endpoint.  In
its typical operation, BIND will just take whatever name and port the
zone administrator said to provide for that SRV record, and not do any
sort of availability checks on it.

However, if you go deep into a far more complicated, custom use of
BIND, you could set up a process that monitors the availability and
changes the SRV record accordingly.
-- 
tale
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: DS record RRSIG

[Josh Kuo]

Tony,

Thank you for that detailed explanation.

On Wed, Jul 3, 2019 at 2:15 AM Tony Finch  wrote:

> Josh Kuo  wrote:
> >
> > There are 6 DS records total, but only 1 RRSIG. This leads me to believe
> > that the single RRSIG is generated by somehow concatenating all DS
> records
> > together.
>
> Correct.
>
> > This then leads me to believe that the validating resolver needs to
> > process _all_ DS records, not just the ones whose key tag matches the
> > child zone's KSK.
>
> Not quite.
>
> One way to validate a delegation is:
>
> * validate the DS RRset, which is signed using the parent's DNSKEY(s)
>   [ you can see the "com" signer field in the "example.com" RRSIG ]
>
> * get the key tags from the DS RRset (the first field in the records)
>   and the key tags from the child's DNSKEY RRSIG records (between lifetime
>   fields and the signer field) and calculate the key tags of the
>   child's DNSKEY records
>
> * take the intersection of these three sets; these key tags identify keys
>   that the parent says can validate the DNSKEY RRset, and that actually do
>   validate the DNSKEY RRset, and that can be used to validate the DNSKEY
>   RRset
>
> * for each DNSKEY in the set, ensure that there is a DS record that
>   whose digest matches it [ you can skip matching attempts when the key
>   tags do not match ]
>
> * using the public keys and signatures you just identified, try to
>   validate the self-signature on the DNSKEY RRset; if any of the
>   signatures validates, it's all good! [ again the key tags let you
>   skip pointless signature validation attempts ]
>
> There are some extra complications to do with downgrade protection, but
> that's the basic idea.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> women and men working together
>
___
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: DS record RRSIG

[Tony Finch]

Josh Kuo  wrote:
>
> There are 6 DS records total, but only 1 RRSIG. This leads me to believe
> that the single RRSIG is generated by somehow concatenating all DS records
> together.

Correct.

> This then leads me to believe that the validating resolver needs to
> process _all_ DS records, not just the ones whose key tag matches the
> child zone's KSK.

Not quite.

One way to validate a delegation is:

* validate the DS RRset, which is signed using the parent's DNSKEY(s)
  [ you can see the "com" signer field in the "example.com" RRSIG ]

* get the key tags from the DS RRset (the first field in the records)
  and the key tags from the child's DNSKEY RRSIG records (between lifetime
  fields and the signer field) and calculate the key tags of the
  child's DNSKEY records

* take the intersection of these three sets; these key tags identify keys
  that the parent says can validate the DNSKEY RRset, and that actually do
  validate the DNSKEY RRset, and that can be used to validate the DNSKEY
  RRset

* for each DNSKEY in the set, ensure that there is a DS record that
  whose digest matches it [ you can skip matching attempts when the key
  tags do not match ]

* using the public keys and signatures you just identified, try to
  validate the self-signature on the DNSKEY RRset; if any of the
  signatures validates, it's all good! [ again the key tags let you
  skip pointless signature validation attempts ]

There are some extra complications to do with downgrade protection, but
that's the basic idea.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
women and men working together
___
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: DS record RRSIG

[Josh Kuo]

Thank you for the clarification.

On Wed, Jul 3, 2019 at 1:49 AM Ondřej Surý  wrote:

> Yes, the whole RRSet is always signed.  Signing individual records would
> not protect against attacks stripping individual records and their RRSIGs.
>
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
>
> > On 2 Jul 2019, at 19:34, Josh Kuo  wrote:
> >
> > This may not be the right place to ask, if this is a better question
> asked in a different list, please let me know.
> >
> > I am curious as to how BIND generates and processes DS RRSIG, and this
> may not be unique to BIND, since I've seen this behavior across multiple
> vendors. From the following:
> >
> > $ dig example.com. DS +dnssec +nocrypto
> >
> > ; <<>> DiG 9.12.2-P2 <<>> example.com. DS +dnssec +nocrypto
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48102
> > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags: do; udp: 4096
> > ;; QUESTION SECTION:
> > ;example.com. IN  DS
> >
> > ;; ANSWER SECTION:
> > example.com.  84558   IN  DS  43547 8 2 [omitted]
> > example.com.  84558   IN  DS  31406 8 1 [omitted]
> > example.com.  84558   IN  DS  31406 8 2 [omitted]
> > example.com.  84558   IN  DS  31589 8 1 [omitted]
> > example.com.  84558   IN  DS  31589 8 2 [omitted]
> > example.com.  84558   IN  DS  43547 8 1 [omitted]
> > example.com.  84558   IN  RRSIG   DS 8 2 86400 20190709042256
> 20190702031256 3800 com. [omitted]
> >
> > ;; Query time: 228 msec
> > ;; SERVER: 10.0.22.1#53(10.0.22.1)
> > ;; WHEN: Wed Jul 03 01:27:42 PST 2019
> > ;; MSG SIZE  rcvd: 455
> >
> > There are 6 DS records total, but only 1 RRSIG. This leads me to believe
> that the single RRSIG is generated by somehow concatenating all DS records
> together. This then leads me to believe that the validating resolver needs
> to process _all_ DS records, not just the ones whose key tag matches the
> child zone's KSK. Is this true? It seems like a small overhead in the grand
> scheme of things, but that seems inefficient, if multiple DS records are
> left at the parent zone after a couple of key rollovers.
> >
> > Any information on this would be appreciated.
> >
> > -Josh
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DS record RRSIG

[Ondřej Surý]

Yes, the whole RRSet is always signed.  Signing individual records would not 
protect against attacks stripping individual records and their RRSIGs.

Ondrej
--
Ondřej Surý
ond...@isc.org

> On 2 Jul 2019, at 19:34, Josh Kuo  wrote:
> 
> This may not be the right place to ask, if this is a better question asked in 
> a different list, please let me know.
> 
> I am curious as to how BIND generates and processes DS RRSIG, and this may 
> not be unique to BIND, since I've seen this behavior across multiple vendors. 
> From the following:
> 
> $ dig example.com. DS +dnssec +nocrypto 
> 
> ; <<>> DiG 9.12.2-P2 <<>> example.com. DS +dnssec +nocrypto
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48102
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;example.com. IN  DS
> 
> ;; ANSWER SECTION:
> example.com.  84558   IN  DS  43547 8 2 [omitted]
> example.com.  84558   IN  DS  31406 8 1 [omitted]
> example.com.  84558   IN  DS  31406 8 2 [omitted]
> example.com.  84558   IN  DS  31589 8 1 [omitted]
> example.com.  84558   IN  DS  31589 8 2 [omitted]
> example.com.  84558   IN  DS  43547 8 1 [omitted]
> example.com.  84558   IN  RRSIG   DS 8 2 86400 20190709042256 
> 20190702031256 3800 com. [omitted]
> 
> ;; Query time: 228 msec
> ;; SERVER: 10.0.22.1#53(10.0.22.1)
> ;; WHEN: Wed Jul 03 01:27:42 PST 2019
> ;; MSG SIZE  rcvd: 455
> 
> There are 6 DS records total, but only 1 RRSIG. This leads me to believe that 
> the single RRSIG is generated by somehow concatenating all DS records 
> together. This then leads me to believe that the validating resolver needs to 
> process _all_ DS records, not just the ones whose key tag matches the child 
> zone's KSK. Is this true? It seems like a small overhead in the grand scheme 
> of things, but that seems inefficient, if multiple DS records are left at the 
> parent zone after a couple of key rollovers.
> 
> Any information on this would be appreciated.
> 
> -Josh
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

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

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

Re: SRV record not working

[Lee]

On 8/18/18, Doug Barton  wrote:
> On 08/18/2018 04:53 PM, Barry Margolin wrote:
>> In article ,
>>   Grant Taylor  wrote:
>>
>>> On 08/18/2018 07:25 AM, Bob McDonald wrote:
 I don't think anyone hates nslookup (well maybe a few do ) I
 suppose the immense dislike stems from the fact that it's the default
 utility under Windows. Folks who use dig as their default realize that
 when used properly, dig provides much more functionality than nslookup.
 For example, try using TSIG with nslookup or getting a NSID response.
 These are only a couple of examples. There's other reasons to change.
 The output from dig is much more comprehensive. And, yes, if you
 install
 the bind tools from ISC under Windows, dig works quite well.
>>>
>>> I've been told that nslookup will lie and provide incorrect information
>>> in some situations.  I have no idea what situations that is.  I would
>>> love to learn what they are.
>>>
>>> If you know of such an example, please enlighten me.
>>>
>>> As such, I tend to use nslookup on platforms without dig when or until I
>>> have reason to not do so.
>>
>> I don't think it "lies" much, but the output isn't as clear and
>> unambiguous as dig's. When it reports errors, it can be difficult to
>> tell specifically what the actual error was.
>>
>> One example I can think of is that for some reason it expects the
>> nameserver to be able to reverse-resolve its own IP. If it can't, it
>> reports this as an error, and you might think that it's reporting an
>> error about the name you're actually trying to look up.
>
> nslookup uses the local resolver stub. That's fine, if that's what you
> want/need to test. If you want to test specific servers, or what is
> visible from the Internet, etc. dig is the right tool, as the answers
> you get from nslookup cannot be guaranteed to be directly related to the
> question you asked.

Could you expand on that a bit please?  I thought
  nslookup  
was pretty much equivalent to
 dig  @

the exception being that nslookup looks for a &  records and dig
just looks for a records

Thanks,
Lee
___
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 record not working

[Doug Barton]

On 08/18/2018 04:53 PM, Barry Margolin wrote:

In article ,
  Grant Taylor  wrote:


On 08/18/2018 07:25 AM, Bob McDonald wrote:

I don't think anyone hates nslookup (well maybe a few do ) I
suppose the immense dislike stems from the fact that it's the default
utility under Windows. Folks who use dig as their default realize that
when used properly, dig provides much more functionality than nslookup.
For example, try using TSIG with nslookup or getting a NSID response.
These are only a couple of examples. There's other reasons to change.
The output from dig is much more comprehensive. And, yes, if you install
the bind tools from ISC under Windows, dig works quite well.


I've been told that nslookup will lie and provide incorrect information
in some situations.  I have no idea what situations that is.  I would
love to learn what they are.

If you know of such an example, please enlighten me.

As such, I tend to use nslookup on platforms without dig when or until I
have reason to not do so.


I don't think it "lies" much, but the output isn't as clear and
unambiguous as dig's. When it reports errors, it can be difficult to
tell specifically what the actual error was.

One example I can think of is that for some reason it expects the
nameserver to be able to reverse-resolve its own IP. If it can't, it
reports this as an error, and you might think that it's reporting an
error about the name you're actually trying to look up.


nslookup uses the local resolver stub. That's fine, if that's what you 
want/need to test. If you want to test specific servers, or what is 
visible from the Internet, etc. dig is the right tool, as the answers 
you get from nslookup cannot be guaranteed to be directly related to the 
question you asked.

___
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 record not working

[Barry Margolin]

In article ,
 Grant Taylor  wrote:

> On 08/18/2018 07:25 AM, Bob McDonald wrote:
> > I don't think anyone hates nslookup (well maybe a few do ) I 
> > suppose the immense dislike stems from the fact that it's the default 
> > utility under Windows. Folks who use dig as their default realize that 
> > when used properly, dig provides much more functionality than nslookup. 
> > For example, try using TSIG with nslookup or getting a NSID response. 
> > These are only a couple of examples. There's other reasons to change. 
> > The output from dig is much more comprehensive. And, yes, if you install 
> > the bind tools from ISC under Windows, dig works quite well.
> 
> I've been told that nslookup will lie and provide incorrect information 
> in some situations.  I have no idea what situations that is.  I would 
> love to learn what they are.
> 
> If you know of such an example, please enlighten me.
> 
> As such, I tend to use nslookup on platforms without dig when or until I 
> have reason to not do so.

I don't think it "lies" much, but the output isn't as clear and 
unambiguous as dig's. When it reports errors, it can be difficult to 
tell specifically what the actual error was.

One example I can think of is that for some reason it expects the 
nameserver to be able to reverse-resolve its own IP. If it can't, it 
reports this as an error, and you might think that it's reporting an 
error about the name you're actually trying to look up.

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

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

Re: SRV record not working

[Paul Kosinski]

Extra complexity -- "man dig" yields 289 lines while "man nslookup"
yields only 160 lines.

Also, dig is not simply an extension of nslookup (which I long ago
abbreviated to nsl), but is significantly different, so it using it
involves the human analog of a cache miss.


On Sat, 18 Aug 2018 20:12:01 +0200
Reindl Harald  wrote:

> 
> 
> Am 18.08.2018 um 20:02 schrieb Paul Kosinski:
> > When I started using Linux almost 20 years ago, I think there was
> > only nslookup, and no dig. So by habit, I tend to use it unless the
> > extra power of dig outweighs its extra complexity. 
> 
> which extra complexity?
> 
> because you have to add an @ when you want to use a non-default
> nameserver and that you need "dig -X" for a reverse-lookup?
> 
> you can use dig as nslookup, it's not required that you add a record
> type - just "dig whatever" which is in that case even shorter
> 
> > On Sat, 18 Aug 2018 11:42:20 -0600
> > Grant Taylor via bind-users  wrote:
> > 
> >> On 08/18/2018 07:25 AM, Bob McDonald wrote:
> >>> I don't think anyone hates nslookup (well maybe a few do )
> >>> I suppose the immense dislike stems from the fact that it's the
> >>> default utility under Windows. Folks who use dig as their default
> >>> realize that when used properly, dig provides much more
> >>> functionality than nslookup. For example, try using TSIG with
> >>> nslookup or getting a NSID response. These are only a couple of
> >>> examples. There's other reasons to change. The output from dig is
> >>> much more comprehensive. And, yes, if you install the bind tools
> >>> from ISC under Windows, dig works quite well.
> >>
> >> I've been told that nslookup will lie and provide incorrect
> >> information in some situations.  I have no idea what situations
> >> that is.  I would love to learn what they are.
> >>
> >> If you know of such an example, please enlighten me.
> >>
> >> As such, I tend to use nslookup on platforms without dig when or
> >> until I have reason to not do so
> 
> 
___
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 record not working

[Paul Kosinski]

When I started using Linux almost 20 years ago, I think there was only
nslookup, and no dig. So by habit, I tend to use it unless the extra
power of dig outweighs its extra complexity. I don't remember what I
used on Windows back when I was regularly using both.


On Sat, 18 Aug 2018 11:42:20 -0600
Grant Taylor via bind-users  wrote:

> On 08/18/2018 07:25 AM, Bob McDonald wrote:
> > I don't think anyone hates nslookup (well maybe a few do ) I 
> > suppose the immense dislike stems from the fact that it's the
> > default utility under Windows. Folks who use dig as their default
> > realize that when used properly, dig provides much more
> > functionality than nslookup. For example, try using TSIG with
> > nslookup or getting a NSID response. These are only a couple of
> > examples. There's other reasons to change. The output from dig is
> > much more comprehensive. And, yes, if you install the bind tools
> > from ISC under Windows, dig works quite well.
> 
> I've been told that nslookup will lie and provide incorrect
> information in some situations.  I have no idea what situations that
> is.  I would love to learn what they are.
> 
> If you know of such an example, please enlighten me.
> 
> As such, I tend to use nslookup on platforms without dig when or
> until I have reason to not do so.
> 
> 
> 
___
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 record not working

[Grant Taylor via bind-users]

On 08/18/2018 07:25 AM, Bob McDonald wrote:
I don't think anyone hates nslookup (well maybe a few do ) I 
suppose the immense dislike stems from the fact that it's the default 
utility under Windows. Folks who use dig as their default realize that 
when used properly, dig provides much more functionality than nslookup. 
For example, try using TSIG with nslookup or getting a NSID response. 
These are only a couple of examples. There's other reasons to change. 
The output from dig is much more comprehensive. And, yes, if you install 
the bind tools from ISC under Windows, dig works quite well.


I've been told that nslookup will lie and provide incorrect information 
in some situations.  I have no idea what situations that is.  I would 
love to learn what they are.


If you know of such an example, please enlighten me.

As such, I tend to use nslookup on platforms without dig when or until I 
have reason to not do so.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

re: SRV record not working

[Bob McDonald]

> I know that most of you hate nslookup but I have been using it since the
> 90's and it's my go-to utility. I get the same responses whether I use
> Dig or nslookup. If nslookup doesn't return what I am looking for, I do
> use Dig also.

I don't think anyone hates nslookup (well maybe a few do ) I suppose
the immense dislike stems from the fact that it's the default utility under
Windows. Folks who use dig as their default realize that when used
properly, dig provides much more functionality than nslookup. For example,
try using TSIG with nslookup or getting a NSID response. These are only a
couple of examples. There's other reasons to change. The output from dig is
much more comprehensive. And, yes, if you install the bind tools from ISC
under Windows, dig works quite well.

Just my $.02

Bob
___
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 record not working

[wharfratjoe]

Seems ok here using: dig +trace srv _minecraft._tcp.skyblock.mc-game.us.


mc-game.us. 3600IN  NS  ns1.sleepyvalley.net.
mc-game.us. 3600IN  NS  sdns2.ovh.ca.
;; Received 113 bytes from 156.154.126.70#53(156.154.126.70) in 168 ms

_minecraft._tcp.skyblock.mc-game.us. 300 IN SRV 0 5 25567
skyblock.mc-game.us.
;; Received 92 bytes from 167.114.154.31#53(167.114.154.31) in 73 ms


On Fri, Aug 17, 2018 at 10:42 AM, Carl Byington  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Fri, 2018-08-17 at 12:27 -0500, Thomas Strike wrote:
> > I need a 2nd pair of eyes on this one.
>
> Works for me.
>
> dig _minecraft._tcp.skyblock.mc-game.us srv
>
> ;; ANSWER SECTION:
> _minecraft._tcp.skyblock.mc-game.us. 300 IN SRV 0 5 25567 skyblock.mc-
> game.us.
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEAREKAAYFAlt3CPAACgkQL6j7milTFsHoywCfRQIVqUZnycWdYGdRupaSEWiU
> ZlsAn18No1vPczhoAURmolzbt3Z+I7PU
> =EQx5
> -END PGP SIGNATURE-
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



-- 
Peace,
Joe

"Without love in the dream
It will never come true"
Words by Robert Hunter
___
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 record not working

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, 2018-08-17 at 12:27 -0500, Thomas Strike wrote:
> I need a 2nd pair of eyes on this one.

Works for me.

dig _minecraft._tcp.skyblock.mc-game.us srv

;; ANSWER SECTION:
_minecraft._tcp.skyblock.mc-game.us. 300 IN SRV 0 5 25567 skyblock.mc-
game.us.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlt3CPAACgkQL6j7milTFsHoywCfRQIVqUZnycWdYGdRupaSEWiU
ZlsAn18No1vPczhoAURmolzbt3Z+I7PU
=EQx5
-END PGP SIGNATURE-



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

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

Re: SRV record not working

[Bob Harold]

On Fri, Aug 17, 2018 at 1:28 PM Thomas Strike 
wrote:

> I have created a SRV record for a new subdomain A record. I set nslookup
> to use my DNS server directly and when I query for the A record it
> returns it. When I set type=SRV and ask for the srv record nothing is
> returned.
>
> My SRV record: _minecraft._tcp.skyblock.mc-game.us.IN SRV0 5
> 25567 skyblock.mc-game.us.
>
> I need a 2nd pair of eyes on this one.
>
> Thanks, Tom Strike
>
>
Works for me:

nslookup -q=srv _minecraft._tcp.skyblock.mc-game.us. 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
_minecraft._tcp.skyblock.mc-game.us service = 0 5 25567 skyblock.mc-game.us.

Authoritative answers can be found from:


dig srv _minecraft._tcp.skyblock.mc-game.us. @8.8.8.8

; <<>> DiG 9.10.3-P4-Ubuntu <<>> srv _minecraft._tcp.skyblock.mc-game.us. @
8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53437
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;_minecraft._tcp.skyblock.mc-game.us. IN SRV

;; ANSWER SECTION:
_minecraft._tcp.skyblock.mc-game.us. 299 IN SRV 0 5 25567
skyblock.mc-game.us.

;; Query time: 56 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Aug 17 13:38:35 EDT 2018
;; MSG SIZE  rcvd: 103

-- 
Bob Harold
___
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: SOA record not signed with new key at key-rollover

[Nis Wechselberg]

Am 18.07.2016 um 12:48 schrieb Tony Finch:
> If your rollover time is much shorter then you are testing something that
> is more like an emergency unplanned rollover.

At the moment I am merely testing in this "high-frequency" setup to get
a good feeling for the mechanics and the interaction between the tools.

I understand that this is not the correct approach for a stable 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: SOA record not signed with new key at key-rollover

[Tony Finch]

Nis Wechselberg  wrote:

> Am I getting it right that the rest of the zone is not (re)signed
> because the current signature is still valid for some time?
>
> So if I were to set sig-validity-interval to a shorter value, this would
> help with the issue?

If you are testing out a fast rollover schedule then it would make sense
to set a short sig-validity-interval, scaled to match.

If your rollover time is much shorter then you are testing something that
is more like an emergency unplanned rollover.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: Southerly, becoming variable, 3 or 4, occasionally 5 at first in
west. Smooth or slight. Fog banks. Moderate or good, occasionally very poor.
___
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: SOA record not signed with new key at key-rollover

[Nis Wechselberg]

Hi,

you are right, I got confused there.
Am I getting it right that the rest of the zone is not (re)signed
because the current signature is still valid for some time?

So if I were to set sig-validity-interval to a shorter value, this would
help with the issue?
Sadly it seems to be a value in days, so it is not that easy to test.
I will try setting the interval to 1 day with 23 hours preview signing.

Thanks.

Am 17.07.2016 um 06:06 schrieb Mark Andrews:
> In message <5788c969.6070...@enbewe.de>, Nis Wechselberg writes:
>> Hi,
>>
>> I am curently testing a dnssec setup with the new dnssec-keymgr tool. I
>> created a test zone with very fast key rollover setings and very short
>> TTLs. (Configs below)
>>
>> The automated creation of keys seems to work fine but bind behaves other
>> than I would have expected.
>>
>> - Initial deployment looks fine with the current ZSK published and in use.
>> (http://dnsviz.net/d/testmichhartundwild.de/V4ep6A/dnssec/)
> 
> ZSK = 36141
>  
>> - At prepublication time the next key is published but not yet used (as
>> expected.
>> (http://dnsviz.net/d/testmichhartundwild.de/V4fV_A/dnssec/)
> 
> New ZSK is 10173
> 
>> - After rollover time the new key is used to sign the zone EXCEPT the
>> SOA record. This one is still signed by the old key.
>> (http://dnsviz.net/d/testmichhartundwild.de/V4fyNQ/dnssec/)
> 
> No.  The new ZSK signs the SOA record.  The old signatures still exist
> on the other records as the only RRset that changes is the SOA.
>  
>> - When post-publication of the old key expires it is removed and the new
>> key is used for all records.
>> (http://dnsviz.net/d/testmichhartundwild.de/V4gSGg/dnssec/)
>>
>>
>> I am confused becaus of the special treatment of the SOA record. I would
>> expect a complete switch to the new key. At the moment, cached responses
>> of the SOA record could not be verified in the timeframe between
>> deletion of the old key and the next TTL.
>>
>> Am I missing something?
>>
>> Regards,
>> Nis
>>
>> 
>>
>>
>> dnssec-keymgr policy:
>>
>> zone testmichhartundwild.de {
>>   algorithm RSASHA256;
>>   directory "/etc/bind/zones/keys";
>>   coverage 2d;
>>   keyttl 600;
>>   roll-period zsk 8h;
>>   post-publish zsk 2h;
>>   pre-publish zsk 2h;
>> };
>>
>>
>> bind zone config:
>>
>> zone "testmichhartundwild.de" IN {
>>   type master;
>>
>>   file "de/testmichhartundwild.de/zone.db";
>>
>>   // Allow zone transfers to trusted servers
>>   allow-transfer {
>> myServers;
>> localhost;
>>   };
>>
>>   // Allow updates with shared key
>>   update-policy {
>> grant morpheus-trinity. zonesub any;
>>   };
>>   serial-update-method unixtime;
>>
>>   // Activate dnssec for this domain
>>   key-directory "keys";
>>   auto-dnssec maintain;
>> };
>>
>>
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>>  from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: SOA record not signed with new key at key-rollover

[Mark Andrews]

In message <5788c969.6070...@enbewe.de>, Nis Wechselberg writes:
> Hi,
> 
> I am curently testing a dnssec setup with the new dnssec-keymgr tool. I
> created a test zone with very fast key rollover setings and very short
> TTLs. (Configs below)
> 
> The automated creation of keys seems to work fine but bind behaves other
> than I would have expected.
> 
> - Initial deployment looks fine with the current ZSK published and in use.
> (http://dnsviz.net/d/testmichhartundwild.de/V4ep6A/dnssec/)

ZSK = 36141
 
> - At prepublication time the next key is published but not yet used (as
> expected.
> (http://dnsviz.net/d/testmichhartundwild.de/V4fV_A/dnssec/)

New ZSK is 10173

> - After rollover time the new key is used to sign the zone EXCEPT the
> SOA record. This one is still signed by the old key.
> (http://dnsviz.net/d/testmichhartundwild.de/V4fyNQ/dnssec/)

No.  The new ZSK signs the SOA record.  The old signatures still exist
on the other records as the only RRset that changes is the SOA.
 
> - When post-publication of the old key expires it is removed and the new
> key is used for all records.
> (http://dnsviz.net/d/testmichhartundwild.de/V4gSGg/dnssec/)
> 
> 
> I am confused becaus of the special treatment of the SOA record. I would
> expect a complete switch to the new key. At the moment, cached responses
> of the SOA record could not be verified in the timeframe between
> deletion of the old key and the next TTL.
> 
> Am I missing something?
> 
> Regards,
> Nis
> 
> 
> 
> 
> dnssec-keymgr policy:
> 
> zone testmichhartundwild.de {
>   algorithm RSASHA256;
>   directory "/etc/bind/zones/keys";
>   coverage 2d;
>   keyttl 600;
>   roll-period zsk 8h;
>   post-publish zsk 2h;
>   pre-publish zsk 2h;
> };
> 
> 
> bind zone config:
> 
> zone "testmichhartundwild.de" IN {
>   type master;
> 
>   file "de/testmichhartundwild.de/zone.db";
> 
>   // Allow zone transfers to trusted servers
>   allow-transfer {
> myServers;
> localhost;
>   };
> 
>   // Allow updates with shared key
>   update-policy {
> grant morpheus-trinity. zonesub any;
>   };
>   serial-update-method unixtime;
> 
>   // Activate dnssec for this domain
>   key-directory "keys";
>   auto-dnssec maintain;
> };
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DS record update via nsupdate

[Mark Andrews]

In message <7966c1a9-a930-b748-7e09-531304b4d...@rotld.ro>, Catalin Leanca 
writes:
> 
> Hello,
> 
> When using nsupdate command to update DS records for subdomains
> without NS delegation, no error code is returned by command and also
> no errors appear in BIND logs (and DS is not updated in the zone).
> Is this a normal behavior?

Yes.  It is consistent with other UPDATE (RFC 2136) behaviours which
maintain zone consistancy.  UPDATE is silent about lots of things
w/o explict prerequisites.

> How to make BIND to issue errors when this happen ?

Add a prerequisite that a NS rrset exists at the name.  It the
prerequiste fails you will get a error.
 
> Best regards,
> 
> -- 
> 
> *CS Catalin LEANCA*
> ICI ROTLD - Serviciul Tehnic
> Bd. Maresal Averescu 8-10,
> Sector 1, Bucuresti
> Mobil: +40 744 81
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

RE: Forward record for WWW

[Cuttler, Brian R. (HEALTH)]

Stanley,

> Are you running DNSSEC?

Negative, we are not running dnssec.

Brian

___
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: Forward record for WWW

[Stanley Weilnau]

Are you running DNSSEC?

Stanley Weilnau

> On May 5, 2016, at 3:30 PM, Cuttler, Brian R. (HEALTH) 
> <brian.cutt...@health.ny.gov> wrote:
> 
> Ralf, All,
> 
> Sorry, there was a brief side discussion. A couple of years ago we 
> implemented a test server, same platform (in this case cloned virtual 
> systems) with same source tables and config, running in the same environment, 
> in this case my DMZ.
> 
> Because I didn't want to risk damage to the master, as we have corrupted 
> tables and crashed servers, we implement changes on the test server, and if 
> it works as expected we rsync the updated tables to the live master from the 
> test master.
> 
> Someone else reported a problem with dig to my server, and I'd thought the 
> list was CC'd, but the test is 199.184.16.7 and is apparently blocked at the 
> FW, as the test master and the actual master both live in the DMZ but the 
> test machine does not normally need to be seen from outside.
> 
> My - what an extraordinary result!
> 
> Looking again at the SOA from dig, included below we see 1604xxx, an April 
> date "YYMMHHMMSS". When I looked at dig output again a moment ago, I saw a 
> March date, 1603xxx (yes, I have a script that subs that in when I move the 
> tables from the source to the root directory, complex combo of RCS, followed 
> by # SED as RCS doesn't provide integer revision numbers and an # rsync to 
> the directory read by the daemon, all on my test machine. If that all checks 
> out, an rsync from the test machine live (rather than source) directory to 
> the live directory on the actual master server).
> 
> In any case, I stopped and started the server, and the A record is now being 
> reported.
> 
> So, for reasons I don't understand, the SOA as reported by DIG does not match 
> the SOA serial imbedded in the file and reported by the server log.
> 
> We solved my first problem, but I am now very confused by the apparent cause.
> 
> I have run the rsync from my test server to my production master, reloaded 
> the tables, reloaded the tables. I see the same SOA as the test server (I 
> rsync the tables with no changes, SOA on my test and production servers is 
> the same), in the named logs, in DIG output, in the source files.
> 
> Something is a bit hinky with my test server and I've no idea what.
> 
> If anyone has any suggestions I'd love to hear them, but with your help the 
> issue I was having has been resolved by restarting the server, rather than 
> reloading the zones files.
> 
> Many thanks,
> Brian
> 
>> -Original Message-
>> From: Bischof, Ralph F. (MSFC-IS40)[NICS] [mailto:ralph.bisc...@nasa.gov]
>> Sent: Thursday, May 05, 2016 3:03 PM
>> To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov>
>> Subject: RE: Forward record for WWW
>> 
>> ATTENTION: This email came from an external source. Do not open
>> attachments or click on links from unknown senders or unexpected emails.
>> 
>> 
>> Ah, I found it.
>> When I query, I get your old serial number, not the new one.
>> Perhaps the zone is "stuck" in cache and an rndc reload is not working for
>> you?
>> You can either stop/restart the server or try rndc flushname and rndc
>> reload again.
>> 
>> [rbisc...@nsc1.nasa.gov ~]$ dig @beacon.health.state.ny.us. wadsworth.org.
>> soa
>> 
>> ; <<>> DiG ALU DNS 6.1 Build 44 <<>> @beacon.health.state.ny.us.
>> wadsworth.org. soa ; (1 server found) ;; global options: +cmd ;; Got
>> answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51689 ;; flags: qr aa
>> rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; WARNING: recursion
>> requested but not available
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;wadsworth.org. IN  SOA
>> 
>> ;; ANSWER SECTION:
>> wadsworth.org.  86400   IN  SOA pauling.wadsworth.org.
>> qll.wadsworth.org. 1604120926 10800 3600 604800 86400
>> 
>> ;; AUTHORITY SECTION:
>> wadsworth.org.  86400   IN  NS  ns1.albany.edu.
>> wadsworth.org.  86400   IN  NS  pauling.wadsworth.org.
>> wadsworth.org.  86400   IN  NS  beacon.health.state.ny.us.
>> 
>> ;; ADDITIONAL SECTION:
>> pauling.wadsworth.org.  86400   IN  A   199.184.16.6
>> beacon.health.state.ny.us. 10800 IN A   192.135.176.22
>> 
>> ;; Query time: 68 msec
>> ;; SERVER: 192.135.176.22#53(192.135.176.22) ;; WHEN: Thu May 05 19:00:31
>> GMT 2016 ;; MSG SIZE  rcvd: 203
>>

RE: Forward record for WWW

[Cuttler, Brian R. (HEALTH)]

Ralf, All,

Sorry, there was a brief side discussion. A couple of years ago we implemented 
a test server, same platform (in this case cloned virtual systems) with same 
source tables and config, running in the same environment, in this case my DMZ.

Because I didn't want to risk damage to the master, as we have corrupted tables 
and crashed servers, we implement changes on the test server, and if it works 
as expected we rsync the updated tables to the live master from the test master.

Someone else reported a problem with dig to my server, and I'd thought the list 
was CC'd, but the test is 199.184.16.7 and is apparently blocked at the FW, as 
the test master and the actual master both live in the DMZ but the test machine 
does not normally need to be seen from outside.

My - what an extraordinary result!

Looking again at the SOA from dig, included below we see 1604xxx, an April date 
"YYMMHHMMSS". When I looked at dig output again a moment ago, I saw a March 
date, 1603xxx (yes, I have a script that subs that in when I move the tables 
from the source to the root directory, complex combo of RCS, followed by # SED 
as RCS doesn't provide integer revision numbers and an # rsync to the directory 
read by the daemon, all on my test machine. If that all checks out, an rsync 
from the test machine live (rather than source) directory to the live directory 
on the actual master server).

In any case, I stopped and started the server, and the A record is now being 
reported.

So, for reasons I don't understand, the SOA as reported by DIG does not match 
the SOA serial imbedded in the file and reported by the server log.

We solved my first problem, but I am now very confused by the apparent cause.

I have run the rsync from my test server to my production master, reloaded the 
tables, reloaded the tables. I see the same SOA as the test server (I rsync the 
tables with no changes, SOA on my test and production servers is the same), in 
the named logs, in DIG output, in the source files.

Something is a bit hinky with my test server and I've no idea what.

If anyone has any suggestions I'd love to hear them, but with your help the 
issue I was having has been resolved by restarting the server, rather than 
reloading the zones files.

Many thanks,
Brian

> -Original Message-
> From: Bischof, Ralph F. (MSFC-IS40)[NICS] [mailto:ralph.bisc...@nasa.gov]
> Sent: Thursday, May 05, 2016 3:03 PM
> To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov>
> Subject: RE: Forward record for WWW
> 
> ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.
> 
> 
> Ah, I found it.
> When I query, I get your old serial number, not the new one.
> Perhaps the zone is "stuck" in cache and an rndc reload is not working for
> you?
> You can either stop/restart the server or try rndc flushname and rndc
> reload again.
> 
> [rbisc...@nsc1.nasa.gov ~]$ dig @beacon.health.state.ny.us. wadsworth.org.
> soa
> 
> ; <<>> DiG ALU DNS 6.1 Build 44 <<>> @beacon.health.state.ny.us.
> wadsworth.org. soa ; (1 server found) ;; global options: +cmd ;; Got
> answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51689 ;; flags: qr aa
> rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; WARNING: recursion
> requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;wadsworth.org. IN  SOA
> 
> ;; ANSWER SECTION:
> wadsworth.org.  86400   IN  SOA pauling.wadsworth.org.
> qll.wadsworth.org. 1604120926 10800 3600 604800 86400
> 
> ;; AUTHORITY SECTION:
> wadsworth.org.  86400   IN  NS  ns1.albany.edu.
> wadsworth.org.  86400   IN  NS  pauling.wadsworth.org.
> wadsworth.org.  86400   IN  NS  beacon.health.state.ny.us.
> 
> ;; ADDITIONAL SECTION:
> pauling.wadsworth.org.  86400   IN  A   199.184.16.6
> beacon.health.state.ny.us. 10800 IN A   192.135.176.22
> 
> ;; Query time: 68 msec
> ;; SERVER: 192.135.176.22#53(192.135.176.22) ;; WHEN: Thu May 05 19:00:31
> GMT 2016 ;; MSG SIZE  rcvd: 203
> 
> [rbisc...@nsc1.nasa.gov ~]$
> 
> 
> Thank you,
> Ralph F. Bischof, Jr.
> The opinions expressed within this communication are not necessarily those
> of NASA.
> 
> 
> 
> > -Original Message-
> > From: Cuttler, Brian R. (HEALTH) [mailto:brian.cutt...@health.ny.gov]
> > Sent: Thursday, May 05, 2016 2:00 PM
> > To: Bischof, Ralph F. (MSFC-IS40)[NICS] <ralph.bisc...@nasa.gov>
> > Subject: RE: Forward record for WWW
> >
> > Good suggestions all.
> >
> > First was a look with # cat, # cat -evt has proven 

RE: Forward record for WWW

[Cuttler, Brian R. (HEALTH)]

Barry,

> The output shows that there clearly isn't an A record for the zone apex.
> You need to post the zone file if you want help with what you did wrong.

> My guess is you either forgot the "." at the end of the name, or didn't
> reload the server after updating the zone file.

Those would have been my guesses also, but I'm unable to resolve 
wadsworth.org.wadsworth.org which I'd expect to be the result of a missing dot.

I'm including the head of the file, it is longer than we really need.

Also including the last few lines of the server log file, SOA serial matches 
the zone file.

12-Apr-2016 09:29:23.221 general: info: reloading zones succeeded
12-Apr-2016 09:29:23.225 general: info: zone wadsworth.org/IN/internal: loaded 
serial 1604120926
12-Apr-2016 09:29:23.229 general: info: zone wadsworth.org/IN/external: loaded 
serial 1604120926
05-May-2016 11:27:07.264 general: info: received SIGHUP signal to reload zones
05-May-2016 11:27:07.265 general: info: loading configuration from 
'/etc/named.conf'
05-May-2016 11:27:07.266 general: info: reading built-in trusted keys from file 
'/etc/bind.keys'
05-May-2016 11:27:07.267 general: info: using default UDP/IPv4 port range: 
[1024, 65535]
05-May-2016 11:27:07.267 general: info: using default UDP/IPv6 port range: 
[1024, 65535]
05-May-2016 11:27:07.274 general: info: sizing zone task pool based on 48 zones
05-May-2016 11:27:07.275 general: warning: Warning: view internal: 
'empty-zones-enable/disable-empty-zone' not set: disabling RFC 1918 empty zones
05-May-2016 11:27:07.280 general: info: reloading configuration succeeded
05-May-2016 11:27:07.281 general: info: reloading zones succeeded
05-May-2016 11:27:07.284 general: info: zone wadsworth.org/IN/internal: loaded 
serial 1605051125
05-May-2016 11:27:07.287 general: info: zone wadsworth.org/IN/external: loaded 
serial 1605051125
[root@euclid named]#



[euclid]: /etc/dns-root > more db.wadsworth.org
$TTL 86400
@   IN  SOA pauling.wadsworth.org.  qll.wadsworth.org. (
1605051125  ; serial number
10800   ; refresh after 3 hours
3600; retry after 1 hour
604800  ; expire after 1000 hour
86400 ) ; minimum ttl of 1 day

IN  NS  pauling.wadsworth.org.
IN  NS  ns1.albany.edu.
IN  NS  beacon.health.state.ny.us.

pauling.wadsworth.org.  IN  A   199.184.16.6

; 27-feb-2007

gatecl1-dmz1IN  A   199.184.16.8
gatecl2-dmz1IN  A   199.184.16.9
gatecl-dmz1 IN  A   199.184.16.10


;ns1.albany.edu.IN  A   169.226.1.100
;beacon.health.state.ny.us. IN  A   192.135.176.22



localhost   IN  A   127.0.0.1

gate3.wadsworth.org.  INA 199.184.16.5

; 2016-03-24 BRC
; short TTL forward record pointing domain name to WWW IP address. DO NOT USE CN
AME, they are
; "cononical" and would screw up the MX records!!
; If no problems we can lengthen the TTL and later remove the record specific va
lue.
; Tested with no issues on intra-net DNS servers.

wadsworth.org.  300  IN A 199.184.16.22
; simply not being served, removed until I can figure out why

; 2012-12-10 per ivan
wadsworth.org.  IN  TXT "v=spf1 ptr:wadsworth.org ip4:199.184.28.0/22 ?all"

--removing dig output and other already posted information--

Thank you,
Brian


___
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: Forward record for WWW

[Barry Margolin]

In article <mailman.731.1462469692.73610.bind-us...@lists.isc.org>,
 "Cuttler, Brian R. (HEALTH)" <brian.cutt...@health.ny.gov> wrote:

> Since this is only a test server not production, and lives in the DMZ it must 
> be blocked at the FW.
> 
> # dig with no specification for query type and with "A" both give the same 
> result. Dig with q-type "any" is output included.
> 
> Sorry that prior email had bad line breaks, looked ok when I wrote it but 
> they have moved us to outlook and I am apparently not sufficient proficient 
> in its use.

The output shows that there clearly isn't an A record for the zone apex. 
You need to post the zone file if you want help with what you did wrong.

My guess is you either forgot the "." at the end of the name, or didn't 
reload the server after updating the zone file.

> 
> This is the output from dig against this server.
> 
> [euclid] ~ 201> dig @199.184.16.7 wadsworth.org
> 
> ; <<>> DiG 9.10.2-P3 <<>> @199.184.16.7 wadsworth.org
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8047
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;wadsworth.org. IN  A
> 
> ;; AUTHORITY SECTION:
> wadsworth.org.  86400   IN  SOA pauling.wadsworth.org. 
> qll.wadsworth.org. 1603081507 10800 3600 604800 86400
> 
> ;; Query time: 0 msec
> ;; SERVER: 199.184.16.7#53(199.184.16.7)
> ;; WHEN: Thu May 05 13:29:15 EDT 2016
> ;; MSG SIZE  rcvd: 90
> 
> 
> 
> [euclid] ~ 213> dig any @199.184.16.7 wadsworth.org
> 
> ; <<>> DiG 9.10.2-P3 <<>> any @199.184.16.7 wadsworth.org
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62021
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 5
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;wadsworth.org. IN  ANY
> 
> ;; ANSWER SECTION:
> wadsworth.org.  86400   IN  MX  10 smtptoo.wadsworth.org.
> wadsworth.org.  86400   IN  MX  10 smtpproxy.wadsworth.org.
> wadsworth.org.  86400   IN  MX  5 wish1.wadsworth.org.
> wadsworth.org.  86400   IN  TXT "v=spf1 ptr:wadsworth.org 
> ip4:199.184.28.0/22 ?all"
> wadsworth.org.  86400   IN  SOA pauling.wadsworth.org. 
> qll.wadsworth.org. 1603081507 10800 3600 604800 86400
> wadsworth.org.  86400   IN  NS  ns1.albany.edu.
> wadsworth.org.  86400   IN  NS  pauling.wadsworth.org.
> wadsworth.org.  86400   IN  NS  beacon.health.state.ny.us.
> 
> ;; ADDITIONAL SECTION:
> wish1.wadsworth.org.86400   IN  A   199.184.16.38
> smtptoo.wadsworth.org.  86400   IN  A   199.184.16.18
> smtpproxy.wadsworth.org. 86400  IN  A   199.184.16.16
> pauling.wadsworth.org.  86400   IN  A   199.184.16.6
> 
> ;; Query time: 0 msec
> ;; SERVER: 199.184.16.7#53(199.184.16.7)
> ;; WHEN: Thu May 05 13:30:49 EDT 2016
> ;; MSG SIZE  rcvd: 369
> 
> [euclid] ~ 214>
> 
> > -Original Message-
> > From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr]
> > Sent: Thursday, May 05, 2016 12:12 PM
> > To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov>
> > Cc: Stephane Bortzmeyer <bortzme...@nic.fr>; bind-users@lists.isc.org
> > Subject: Re: Forward record for WWW
> > 
> > ATTENTION: This email came from an external source. Do not open
> > attachments or click on links from unknown senders or unexpected emails.
> > 
> > 
> > On Thu, May 05, 2016 at 04:06:06PM +,  Cuttler, Brian R. (HEALTH)
> > <brian.cutt...@health.ny.gov> wrote  a message of 34 lines which said:
> > 
> > > I configured the change for my external test server only
> > > (199.184.16.7, which is _probably_ available for external query)
> > 
> > No.
> > 
> > % dig @199.184.16.7 A wadsworth.org
> > 
> > ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @199.184.16.7 A wadsworth.org ; (1
> > server found) ;; global options: +cmd ;; connection timed out; no servers
> > could be reached

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

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

RE: Forward record for WWW

[Cuttler, Brian R. (HEALTH)]

Since this is only a test server not production, and lives in the DMZ it must 
be blocked at the FW.

# dig with no specification for query type and with "A" both give the same 
result. Dig with q-type "any" is output included.

Sorry that prior email had bad line breaks, looked ok when I wrote it but they 
have moved us to outlook and I am apparently not sufficient proficient in its 
use.

This is the output from dig against this server.

[euclid] ~ 201> dig @199.184.16.7 wadsworth.org

; <<>> DiG 9.10.2-P3 <<>> @199.184.16.7 wadsworth.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8047
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wadsworth.org. IN  A

;; AUTHORITY SECTION:
wadsworth.org.  86400   IN  SOA pauling.wadsworth.org. 
qll.wadsworth.org. 1603081507 10800 3600 604800 86400

;; Query time: 0 msec
;; SERVER: 199.184.16.7#53(199.184.16.7)
;; WHEN: Thu May 05 13:29:15 EDT 2016
;; MSG SIZE  rcvd: 90



[euclid] ~ 213> dig any @199.184.16.7 wadsworth.org

; <<>> DiG 9.10.2-P3 <<>> any @199.184.16.7 wadsworth.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62021
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wadsworth.org. IN  ANY

;; ANSWER SECTION:
wadsworth.org.  86400   IN  MX  10 smtptoo.wadsworth.org.
wadsworth.org.  86400   IN  MX  10 smtpproxy.wadsworth.org.
wadsworth.org.  86400   IN  MX  5 wish1.wadsworth.org.
wadsworth.org.  86400   IN  TXT "v=spf1 ptr:wadsworth.org 
ip4:199.184.28.0/22 ?all"
wadsworth.org.  86400   IN  SOA pauling.wadsworth.org. 
qll.wadsworth.org. 1603081507 10800 3600 604800 86400
wadsworth.org.  86400   IN  NS  ns1.albany.edu.
wadsworth.org.  86400   IN  NS  pauling.wadsworth.org.
wadsworth.org.  86400   IN  NS  beacon.health.state.ny.us.

;; ADDITIONAL SECTION:
wish1.wadsworth.org.86400   IN  A   199.184.16.38
smtptoo.wadsworth.org.  86400   IN  A   199.184.16.18
smtpproxy.wadsworth.org. 86400  IN  A   199.184.16.16
pauling.wadsworth.org.  86400   IN  A   199.184.16.6

;; Query time: 0 msec
;; SERVER: 199.184.16.7#53(199.184.16.7)
;; WHEN: Thu May 05 13:30:49 EDT 2016
;; MSG SIZE  rcvd: 369

[euclid] ~ 214>

> -Original Message-
> From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr]
> Sent: Thursday, May 05, 2016 12:12 PM
> To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov>
> Cc: Stephane Bortzmeyer <bortzme...@nic.fr>; bind-users@lists.isc.org
> Subject: Re: Forward record for WWW
> 
> ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.
> 
> 
> On Thu, May 05, 2016 at 04:06:06PM +,  Cuttler, Brian R. (HEALTH)
> <brian.cutt...@health.ny.gov> wrote  a message of 34 lines which said:
> 
> > I configured the change for my external test server only
> > (199.184.16.7, which is _probably_ available for external query)
> 
> No.
> 
> % dig @199.184.16.7 A wadsworth.org
> 
> ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @199.184.16.7 A wadsworth.org ; (1
> server found) ;; global options: +cmd ;; connection timed out; no servers
> could be reached
___
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: Forward record for WWW

[Stephane Bortzmeyer]

On Thu, May 05, 2016 at 04:06:06PM +,
 Cuttler, Brian R. (HEALTH)  wrote 
 a message of 34 lines which said:

> I configured the change for my external test server only
> (199.184.16.7, which is _probably_ available for external query)

No.

% dig @199.184.16.7 A wadsworth.org

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @199.184.16.7 A wadsworth.org
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
___
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: Forward record for WWW

[Cuttler, Brian R. (HEALTH)]

Forgive me, while the records are fully live on my internal servers, I 
configured the change for my external test server only (199.184.16.7, which is 
_probably_ available for external query) but not on the master.

We had issues years ago, and implemented a server parallel to the master to vet 
changes on, so if we lost a zone or crashed the server we could find that out 
without taking out the actual master.

I did check the log files for my test server, there were no errors, the zone 
file seemed to reload without error and even noted the update in the soa serial 
number.

> -Original Message-
> From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr]
> Sent: Thursday, May 05, 2016 11:55 AM
> To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov>
> Cc: bind-users@lists.isc.org
> Subject: Re: Forward record for WWW
> 
> ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.
> 
> 
> On Thu, May 05, 2016 at 03:42:24PM +,  Cuttler, Brian R. (HEALTH)
> <brian.cutt...@health.ny.gov> wrote  a message of 29 lines which said:
> 
> > External record in the zone file is actually wadsworth.org. 300 IN A
> > 199.184.16.22
> 
> None of the three name servers for wadsworth.org serve this A record.
> 
> It seems the master was *not* reloaded. Did you check its BIND logs to
> see? May be the new zone with the A record at the apex was rejected for
> some reason.
___
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: Forward record for WWW

[Stephane Bortzmeyer]

On Thu, May 05, 2016 at 03:42:24PM +,
 Cuttler, Brian R. (HEALTH)  wrote 
 a message of 29 lines which said:

> External record in the zone file is actually
> wadsworth.org. 300 IN A 199.184.16.22

None of the three name servers for wadsworth.org serve this A record.

It seems the master was *not* reloaded. Did you check its BIND logs to
see? May be the new zone with the A record at the apex was rejected
for some reason.
___
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: Forward record for WWW

[Matthew Pounsett]

On 5 May 2016 at 11:55, Stephane Bortzmeyer  wrote:

> On Thu, May 05, 2016 at 03:42:24PM +,
>  Cuttler, Brian R. (HEALTH)  wrote
>  a message of 29 lines which said:
>
> > External record in the zone file is actually
> > wadsworth.org. 300 IN A 199.184.16.22
>
> None of the three name servers for wadsworth.org serve this A record.
>
> It seems the master was *not* reloaded. Did you check its BIND logs to
> see? May be the new zone with the A record at the apex was rejected
> for some reason.
>

Or perhaps the record was added to a hidden master without the serial
number being updated, and so a zone transfer hasn't happened?
___
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-users Digest, Vol 2012, Issue 1: Re: DMARC Record issue

[Darcy Kevin (FCA)]

I think you need to understand that what's in the zone file is of little 
importance -- what matters is how the data is being sent over the wire (as 
they say). The consumers of DMARC (mail servers) only care about the data that 
gets sent to them over the wire. If it's correct over-the-wire, then you can 
just ignore how the records are represented in the zone file on the master 
and/or slave. Nothing to see here, move along.

Do you have access to some sort of packet capture program (e.g. 
wireshark/tcpdump/snoop) and at least some rudimentary skills in using such a 
tool? Such a tool and the knowledge to use it, will serve you well if you 
intend to progress as a DNS administrator.


- Kevin


P.S. I trimmed the remainder of the message thread, since you responded to a 
digest and thus included a bunch of messages which are unrelated to the topic 
at hand.

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris Vaughan
Sent: Monday, January 05, 2015 11:04 PM
To: 'bind-users@lists.isc.org'
Subject: RE: bind-users Digest, Vol 2012, Issue 1: Re: DMARC Record issue 

Yes,

I have read that part of the FAQ, which concerns people asking whether they 
need to add escape characters manually in the DMARC record. 

I do not add these myself. As shown by my examples below, the entry in the 
master zone is free of any escape characters. However, when an update is 
triggered, the escape characters are being added to the entry on the slave zone 
automatically. Why is this happening and how do I stop it?

Chris Vaughan | Communications Officer, ICT Land and Property Information | 
Level 5, 1 Prince Albert Road Queens Square NSW 2000
e: chris.vaug...@lpi.nsw.gov.au | t: 02 92286884 | m: 0401 148061 | f: 02 
92231271 | http://www.services.nsw.gov.au I http://www.lpi.nsw.gov.au


___
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: DMARC Record issue

[Dave Warren]

On 2015-01-04 19:30, Chris Vaughan wrote:

I have been given the task of implementing DMARC in our BIND servers due the 
recommendation of a security audit on our systems.

Whenever I create the record in the forward server, and refresh the zone, it 
comes out in the slave zone with escape characters inserted in the TXT record.

This occurs in every version of BIND that I have tried, from 9.7 up to 9.10.

Primary test zone record:

_dmarc.domain. IN TXT v=DMARC1; p=reject; rua=root@dns-test-1.domain; aspf=s; 
rf=afrf; sp=reject

Slave test zone record:

_dmarc  TXT v=DMARC1\; p=reject\; 
rua=root@dns-test-1.domain\; aspf=s\; rf=afrf\; sp=reject



http://www.dmarc.org/faq.html#s_12 has some information on what is 
happening here.



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


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

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

Re: DMARC Record issue

[Tony Finch]

Dave Warren da...@hireahit.com wrote:

 http://www.dmarc.org/faq.html#s_12 has some information on what is happening
 here.

There is a fix for this which will be in the next 9.9 and 9.10 versions of
BIND.

https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commit;h=9a36fb86f5019f25705d25ea729d03fcf8ecaa95

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Dover, Wight, Portland, Plymouth: South 5 or 6, veering southwest 6 to gale 8,
becoming cyclonic 4 or 5 later. Moderate or rough, occasionally very rough in
Portland and Plymouth. Rain. Good, occasionally poor.
___
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-users Digest, Vol 2012, Issue 1: Re: DMARC Record issue

[Chris Vaughan]

Yes,

I have read that part of the FAQ, which concerns people asking whether they 
need to add escape characters manually in the DMARC record. 

I do not add these myself. As shown by my examples below, the entry in the 
master zone is free of any escape characters. However, when an update is 
triggered, the escape characters are being added to the entry on the slave zone 
automatically. Why is this happening and how do I stop it?

Chris Vaughan | Communications Officer, ICT
Land and Property Information | Level 5, 1 Prince Albert Road Queens Square NSW 
2000
e: chris.vaug...@lpi.nsw.gov.au | t: 02 92286884 | m: 0401 148061 | f: 02 
92231271 | http://www.services.nsw.gov.au I http://www.lpi.nsw.gov.au

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
bind-users-requ...@lists.isc.org
Sent: Monday, 5 January 2015 11:00 PM
To: bind-users@lists.isc.org
Subject: bind-users Digest, Vol 2012, Issue 1

Send bind-users mailing list submissions to
bind-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users
or, via email, send a message with subject or body 'help' to
bind-users-requ...@lists.isc.org

You can reach the person managing the list at
bind-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific than Re: 
Contents of bind-users digest...


Today's Topics:

   1. Re: BIND DNSSEC Guide draft (Timothe Litt)
   2. DMARC Record issue (Chris Vaughan)
   3. Re: DMARC Record issue (Dave Warren)
   4. Re: Unable to get  for www.revk.uk from some of our
  servers (Phil Mayers)


--

Message: 1
Date: Sun, 04 Jan 2015 16:13:40 -0500
From: Timothe Litt l...@acm.org
To: jr...@isc.org
Cc: bind-users@lists.isc.org
Subject: Re: BIND DNSSEC Guide draft
Message-ID: 54a9ad04.6010...@acm.org
Content-Type: text/plain; charset=windows-1252

On 31-Dec-14 21:00, Jeremy C. Reed wrote:
 ISC is seeking feedback and review for our first public draft of the 
 BIND DNSSEC Guide.  It was written in collaboration with DeepDive 
 Networking.
I haven't had a chance to look in detail, but a quick scan  resulted in several 
observations that I hope are useful.  Also, I posted your note to 
dnssec-deployment, where there should be enthusiasm for the topic :-)

The private network section 6.5.4 doesn't talk about how to configure 
views/stub zones so that authoritative (internal) zones on a shared 
resolver/authoritative server get validated.  (point 1 in the section dismisses 
the
possibility.)  This can be done.

Further, it's useful.  People are much more likely to experiment on internal 
zones.
More important, consider a typical scenario: my web server on the internal view 
has a different address from the external view.  (Besides efficiency, some 
commercial routers don't do NAT on a stick  - e.g. allow an internal client to 
NAT to an external address served by that router, which is NATed to an internal 
server.)

So we want to train users to look for DNSSEC authentication.  Unless one makes 
this work, a notebook on the road will authenticate, but the same notebook in 
the office will not.  Don't bother trying to explain this to users; they'll 
simply ignore the distinction.

Which is sort of a long way of saying: if the goal is to encourage people to 
adopt DNSSEC, your guide should make Private Networks and the corresponding 
recipes first class citizens, not a 'don't bother with this' afterthought.  
Both for admins to feel freer to experiment, and for users to have a consistent 
experience.

On key rollover - this is still a major hassle.  And while the recipes look 
pretty, the process is ugly.  Key rollover really needs to be automated.  There 
are too many steps that require too much indirection.  And too many 'you could 
do this or you could do that' choices - that don't really matter, especially 
for getting started. 
I don't see why a person should have to change parameters, dates, manually 
generate keys, etc.  You can work on the recipes, but I don't think they'll 
make the problem approachable - or safe.  Computers are good at this stuff - 
and people aren't.

It really needs something like a daily cron job with a simple config file that 
does all the work. 
Trigger based on dates, or a 'do it now' emergency/manual command. 
Key generation,
date setting, permissions, etc.  As for key uploads to external registrars, it 
can mail the new keys/DS records to the admin with 'please upload these by 
'date'', and only proceed with the roll-over when it can 'dig' them.
(The e-mail can - via the config file - include a hyperlink to the upload 
page...)  For internal, it can update the trusted keys include file, rndc 
reconfig, etc.
And the config file should come with reasonable default parameters, so it 'just 
works' oob.
E.g. roll the zsks

Re: DANE record rejected by named-checkzone

[Adrian (Aad) Offerman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 11/04/2014 11:54 PM, Mark Andrews wrote:
 In message 545954b0.8080...@offerman.com, Adrian (Aad) Offerman
 writes:
 
 named keeps refusing my zone file in which I included a DANE
 record:
 
 [root]# named-checkzone offerman.com db.offerman.com 
 db.offerman.com:59: _443._tcp.offerman.com: bad owner name
 (check-names) db.offerman.com:60: _443._tcp.offerman.com: bad owner
 name (check-names) zone offerman.com/IN: loaded serial 2014110103 
 OK [root]#
 
 This appears to be caused by the underscores used in the
 port/protocol combination.
 
 Here's what the record looks like:
 
 _443._tcp   IN  TLSA3 0 1 
 a66939453856cd6b0f78427eb38d3a9921cfb8bab928d24017a172647e323ce
 
 Well that isn't a valid TLSA record.  It has a bad hex encoding. 
 There are 63 hex digits.

Just an error in the cutting/pasting, in the mail message that is.


 TLSA records themselves are not subject to check-names
 processing so I suggest that you look at the reported lines in
 the file to find out what is actually there.
 
 In the example below it is the A record which has inherited the 
 _443._tcp owner name.

Ah, that did the job! :-) Inserting a block of TLSA records at the
wrong place screwed up the inheritance for the next record.

Thanks! Adrian


 Mark
 
 [rock:~/git/bind9] marka% bin/check/named-checkzone c.db
 c.db c.db:1: no TTL specified; using SOA MINTTL instead 
 dns_rdata_fromtext: c.db:3: near eol: bad hex encoding 
 c.db:4: _443._tcp.c.db: bad owner name (check-names) zone
 c.db/IN: loading from master file c.db failed: bad hex
 encoding zone c.db/IN: not loaded due to errors. 
 [rock:~/git/bind9] marka%
 
 @IN SOA . . 0 0 0 0 0 @  IN NS . _443._tcp IN TLSA 3 0 1
 a66939453856cd6b0f78427eb38d3a9921cfb8bab928d24017a172647e323ce 
 IN A 1.2.3.4
 
 
 It was created first using this: tlsa --create --output rfc
 offerman.com later using this: ldns-dane create offerman.com 443 
 both resulting in the same record, and both outputs resulting in
 the same error.
 
 I've upgraded the named version (on CentOS 6.6) from 9.8.2 to
 9.9.6, but all to no avail :-(
 
 [root]# named-checkzone -v 9.9.6-RedHat-9.9.6-0.el6
 
 Am I trying to do something here that is not yet supported or am I 
 overlooking something?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUe0v1AAoJECfzYtonqXzEKHgIAJyjwFIgXbZ1eO01eR8JO4Au
s51DVqywT7/0nVfF55Zi6N8mOi9GygYJjSEFJ4lL6g2BI2TaNVzeAQqGp9oJ8UUf
GzJOjLkb7UyPy5OXYjkIj4a2f7t8Eyk7kRXYhfDaPccox87R8NkIWkCftSrfgBEq
LwwTlHrtf2QUi5QxzhsNP/ljuC5mF0EW2ipa3kEggTgHwQ3Sg9pSvxWwP8LVFRn4
RW1ng/9iALxrgQLS7qjEc29vTfj0emRskQEXOgS/Ipt0U9b2Ep5l8uHsULH0jNwP
BJ5+QPJFETlHd6hqKNjpAsVBrZJ+fY4QgIC8Ig8nkWY4gBLtZ55qkb6zIbOFL4Y=
=YVKh
-END PGP SIGNATURE-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DANE record rejected by named-checkzone

[Mark Andrews]

In message 545954b0.8080...@offerman.com, Adrian (Aad) Offerman writes:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 
 named keeps refusing my zone file in which I included a DANE record:
 
 [root]# named-checkzone offerman.com db.offerman.com
 db.offerman.com:59: _443._tcp.offerman.com: bad owner name (check-names)
 db.offerman.com:60: _443._tcp.offerman.com: bad owner name (check-names)
 zone offerman.com/IN: loaded serial 2014110103
 OK
 [root]#
 
 This appears to be caused by the underscores used in the port/protocol
 combination.
 
 Here's what the record looks like:
 
 _443._tcp   IN  TLSA3 0 1
   a66939453856cd6b0f78427eb38d3a9921cfb8bab928d24017a172647e323ce

Well that isn't a valid TLSA record.  It has a bad hex encoding.
There are 63 hex digits.

TLSA records themselves are not subject to check-names processing
so I suggest that you look at the reported lines in the file to
find out what is actually there.

In the example below it is the A record which has inherited the
_443._tcp owner name.

Mark

[rock:~/git/bind9] marka% bin/check/named-checkzone c.db c.db
c.db:1: no TTL specified; using SOA MINTTL instead
dns_rdata_fromtext: c.db:3: near eol: bad hex encoding
c.db:4: _443._tcp.c.db: bad owner name (check-names)
zone c.db/IN: loading from master file c.db failed: bad hex encoding
zone c.db/IN: not loaded due to errors.
[rock:~/git/bind9] marka% 

@   IN SOA . . 0 0 0 0 0
@   IN NS .
_443._tcp IN TLSA 3 0 1  
a66939453856cd6b0f78427eb38d3a9921cfb8bab928d24017a172647e323ce
IN A 1.2.3.4

 
 It was created first using this:
   tlsa --create --output rfc offerman.com
 later using this:
   ldns-dane create offerman.com 443
 both resulting in the same record, and both outputs resulting in the
 same error.
 
 I've upgraded the named version (on CentOS 6.6) from 9.8.2 to 9.9.6,
 but all to no avail :-(
 
 [root]# named-checkzone -v
 9.9.6-RedHat-9.9.6-0.el6
 
 Am I trying to do something here that is not yet supported or am I
 overlooking something?
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 
 iQEcBAEBAgAGBQJUWVSwAAoJECfzYtonqXzEdIsIAIiHdjp726NW57jF6lxF7cFc
 oFNFx8uClGHveq6nWjzG9DhplEkFjl8UYMJyfKx3MUlgnKGerREI13WyEwmOrIvk
 TigcjVEwb3AnbX7RGtzeyqsSAJesx8JdYgLxpSTltfeNpYwjJ4Irl1YQKw3e6hHY
 y8Lcd9gOYYj+weyZv8BoaEIugit/fuxiLOyJ7mqhyHmrDlny1FLbHMOAJzU8WBxx
 aa3IUT91RYP5037d4k3Klk+XbieFoiAGSnvHiaqfg8SuXiosiEKAZOfxymb04sqd
 a4rDiLv6RkLGR8UIWuNfiXNTyGvcZZeW9micMIHVXk/EeEJ1Y7W6vdbwBDJ8M2s=
 =CVi6
 -END PGP SIGNATURE-
 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
  from this list
 
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: A record of domain name must be name server ?

[Matus UHLAR - fantomas]

On 11.09.14 13:14, Bob Harold wrote:

In reference to the question of using a CNAME or A record for 
www.example.com, it seems to me that the best solution, if we could ever
get there, would be to create a new record type that means redirect an A
or  lookup to this other name.  Like this:

example.com.  IN  SOA  
example.com.  IN  ANAME  my.webhosting.com.
www.example.com.  IN  CNAME  my.webhosting.com.

I use ANAME to mean like a CNAME, but only for A and  lookups, with
no restrictions on other names with the same left side (except perhaps
other A and  records if that is necessary for technical reasons).

Several DNS and hosting providers provide similar functionality, but is
there any chance of widespread DNS support for something like this?


It's a server-side thing. The current protocol does not support redirecting
only for A and/or , nor any particular types, only everything (CNAME).


Is there already and RFC for this?


I'm not sure whether this kind of RR should be introduced.
Maybe redirect that defines types to be redirected...

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux - It's now safe to turn on your computer.
Linux - Teraz mozete pocitac bez obav zapnut.
___
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 record of domain name must be name server ?

[Mark Elkins]

On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote:
 No, what I'm saying is that if
 
 example.com owns an A record 203.0.113.48, and
 www.example.com owns an A record 203.0.113.48, then
 
 where does 48.113.0.203.in-addr.arpa point?
 
 Some people will point it at example.com, some will point it at 
 www.example.com. What you get is a mish-mosh. No consistency.

Although I prefer the use of a CNAME solution (CNAME www.example.com to
example.com), in the case of separate A (and ) records, one could
point the reverse to both names. Nothing wrong with a PTR record having
more than one answer. There is then no inconsistency, just choice. After
all, pretty much every NS record has at least two Right-Hand-Sides
(Answers)


 If, on the other hand, www.example.com is a CNAME to example.com, then 
 it's crystal clear where the reverse record will point -- example.com. 
 There is no ambiguity or option for inconsistency.
 
  - Kevin
 
 On 9/10/2014 5:48 PM, Eliezer Croitoru wrote:
  Hey Kevin,
 
  This is not an issue at all.
  A PTR is different then a A record and can be used by two reverse 
  domain names and only the owner of the IP addresses space can define 
  them.
  I am not sure if two PTR records for two domains will be applied to 
  one IP but it is possible for two IP addresses to have the same PTR.
 
  Can we even use a CNAME as a PTR???
 
  Eliezer
 
  On 09/11/2014 12:37 AM, Kevin Darcy wrote:
  Also, have you considered the forward/reverse ambiguity that arises when
  multiple owner names resolve to the same address? To which of those
  names does the PTR point?
 
   - Kevin
 
  ___
  Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
  unsubscribe from this list
 
  bind-users mailing list
  bind-users@lists.isc.org
  https://lists.isc.org/mailman/listinfo/bind-users
 
 
 
 
 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
 from this list
 
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za


smime.p7s
Description: S/MIME cryptographic signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: A record of domain name must be name server ?

[Matus UHLAR - fantomas]

On 10.09.14 18:13, Kevin Darcy wrote:

No, what I'm saying is that if

example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then

where does 48.113.0.203.in-addr.arpa point?


Completely your decision.
Some people will point it at example.com, some will point it at 
www.example.com. What you get is a mish-mosh. No consistency.


Do not mix multiple A and PTR. they are just different things.
You are creating issues where there are none.

If, on the other hand, www.example.com is a CNAME to example.com, 
then it's crystal clear where the reverse record will point -- 
example.com. There is no ambiguity or option for inconsistency.


If you point www CNAME @, the 'www' will have both MX and NS records same as
example.com.  Which may e.g. cause rejectd on backup MX hosts, apparently
not designed to receive mail for www.example.com.

The same applies for all other RRs for exmaple.com Alan named crap.
And that's why I also think it's better to define 'www' as A record, not as
CNAME

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows.   -- Matthew D. Fuller
___
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 record of domain name must be name server ?

[Antonio Querubin]

On Thu, 11 Sep 2014, Matus UHLAR - fantomas wrote:


If you point www CNAME @, the 'www' will have both MX and NS records same as
example.com.  Which may e.g. cause rejectd on backup MX hosts, apparently
not designed to receive mail for www.example.com.


Actually no.  All other RRs are supposed to be ignored (except for RRSIG, 
etc) once the CNAME exists.  Ie. the MX and NS RRs exist only for 
example.com, but not www.example.com.


Antonio Querubin
e-mail:  t...@lavanauts.org
xmpp:  antonioqueru...@gmail.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: A record of domain name must be name server ?

[Sam Wilson]

In article mailman.892.1410364699.26362.bind-us...@lists.isc.org,
 Alan Clegg a...@clegg.com wrote:

 On 9/10/14, 8:42 AM, Sam Wilson wrote:
 
  And you could reduce maintenance very slightly by replacing
  
  www in  A   75.100.245.133
  
  with 
  
  www in  CNAME   @
 
 And now you have an MX record, 3 NS records and a bunch of other crap
 associated with the WWW address.  Keeping track of one extra A record
 (and associated  record if you go in that direction) isn't a bad thing.

And the discussion went on from there.  Sorry, I really didn't mean to 
poke a hornets' nest.

 (Personal preferences, of course)

Personal preference and dependent on the exact needs of the users of the 
data, of course.

Sam

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

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

Re: A record of domain name must be name server ?

[Sam Wilson]

In article mailman.902.1410422525.26362.bind-us...@lists.isc.org,
 Antonio Querubin t...@lavanauts.org wrote:

 On Thu, 11 Sep 2014, Matus UHLAR - fantomas wrote:
 
  If you point www CNAME @, the 'www' will have both MX and NS records same as
  example.com.  Which may e.g. cause rejectd on backup MX hosts, apparently
  not designed to receive mail for www.example.com.
 
 Actually no.  All other RRs are supposed to be ignored (except for RRSIG, 
 etc) once the CNAME exists.  Ie. the MX and NS RRs exist only for 
 example.com, but not www.example.com.

I think that's a misunderstanding of what Matus wrote.  With separate A 
records then www.example.com will only have an A record.  If you alias 
www to @ then looking up MX and NS records for www will return the ones 
for example.com.

Sam

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

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

Re: A record of domain name must be name server ?

[Kevin Darcy]

On 9/11/2014 3:47 AM, Matus UHLAR - fantomas wrote:

On 10.09.14 18:13, Kevin Darcy wrote:

No, what I'm saying is that if

example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then

where does 48.113.0.203.in-addr.arpa point?


Completely your decision.
Some people will point it at example.com, some will point it at 
www.example.com. What you get is a mish-mosh. No consistency.


Do not mix multiple A and PTR. they are just different things.
You are creating issues where there are none.
The issue is consistency. If you give admins choices where to point a 
PTR, and the RFCs don't provide any clear guidance, you're going to get 
inconsistent results.


If you make www a CNAME to apex, then the RFCs are clear that you 
can't point the PTR to the www name. The *only*legal*choice* is to 
point the PTR at the apex name. You're going to get *much*more* 
consistent results.


Consistency is a good thing, isn't it? Sure, the earth isn't going to 
fall off its axis of rotation just because of the way people point their 
A and PTR records, CNAME or don't CNAME. But if we can nudge people in 
the direction of consistency, and there is no downside, why wouldn't we 
do that? That's what best practices are all about -- impelling people 
towards processes/methods/conventions that ultimately benefit 
*everyone*. Greatest good for the greatest number, and all that.


If, on the other hand, www.example.com is a CNAME to example.com, 
then it's crystal clear where the reverse record will point -- 
example.com. There is no ambiguity or option for inconsistency.


If you point www CNAME @, the 'www' will have both MX and NS records 
same as

example.com.  Which may e.g. cause rejectd on backup MX hosts, apparently
not designed to receive mail for www.example.com.
So, is it better that mail sent erroneously to www.example.com fall 
through the RFC 5321 algorithm and attempt to be delivered to the A 
record? That host is almost certainly is a *web* server and quite likely 
to not even be listening on port 25. After some period of time, the user 
ultimately gets a connection timed out, still retrying NDR and 
scratches their head trying to figure out what went wrong. Meanwhile, 
the sending MTA keeps on retrying, web server sees garbage traffic on 
an off-port and generates ICMP packets back to the source. In the CNAME 
to @ scenario, at least the mail gets rejected promptly by a *mail* 
server, you have a nice clear audit trail on the server side and a 
meaningful error message (e.g. I don't accept mail for the 
www.example.com domain) back to the user.


(Yes, I'm aware that there was a proposal recently discussed on the 
DNSOP list for an MX-target convention to denote no mail service 
offered here. That would presumably solve the problem I cited in the 
previous paragraph. But AFAIK that proposal is many years away from 
widespread adoption, and even if adopted, it puts an extra burden on the 
DNS admins to populate the no service MX record, which, again, is 
going to produce inconsistent results -- some admins will remember to do 
it; many won't).


Obviously, if one wants mail for example.com and www.example.com to be 
delivered to *different* MX targets, then CNAME to @ isn't an option. 
But in the general case, where you don't want mail to www.example.com to 
be deliverable *at*all*, CNAME to @ is quite a viable option; 
arguably, a *better* option, since the failure mode is faster and 
cleaner than directing MTAs to try to deliver mail, as per RFC 5321, to 
a web server.




The same applies for all other RRs for exmaple.com Alan named crap.

Actually, the only other RR type that Alan enumerated specifically was 
NS, which operates on entirely different principles, and serves a 
significantly different function, than MX-based mail routing. Who would 
be looking up www.example.com with QTYPE=NS? Is that even a plausible 
use-case scenario?


What other RR types do you have in mind? SRV records? They have their 
own defined naming structure, which effectively precludes apex naming. 
TXT records used for SPF purposes? Worst case for that is that the same 
hosts trusted to send mail for example.com are also trusted to send mail 
for www.example.com -- but *sending* mail servers are presumably under 
the control (directly or indirectly) of the domain owner, so the 
potential for negative fallout seems rather minimal. Something else? Are 
you thinking that a LOC record should be differentiated between www 
and apex, if the web server is physically in a different datacenter than 
the corporate headquarters of the domain owner?


- Kevin

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

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

Re: A record of domain name must be name server ?

[Kevin Darcy]

Mark,
Depending on implementation, a PTR RRset with multiple 
records either


-- only ever gets answered with the first record of the set (in which 
case the second and subsequent records of the set are just a waste of 
space), or
-- answers in a random, cyclic and/or round-robin fashion (in which 
case, the results are non-deterministic from the standpoint of a client, 
and this can cause problems and/or confusion)


So, although the standards allow multiple RRs, in practical terms, it 
only makes sense for a PTR RRset to contain a *single* RR.


- Kevin

On 9/11/2014 3:45 AM, Mark Elkins wrote:

On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote:

No, what I'm saying is that if

example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then

where does 48.113.0.203.in-addr.arpa point?

Some people will point it at example.com, some will point it at
www.example.com. What you get is a mish-mosh. No consistency.

Although I prefer the use of a CNAME solution (CNAME www.example.com to
example.com), in the case of separate A (and ) records, one could
point the reverse to both names. Nothing wrong with a PTR record having
more than one answer. There is then no inconsistency, just choice. After
all, pretty much every NS record has at least two Right-Hand-Sides
(Answers)



If, on the other hand, www.example.com is a CNAME to example.com, then
it's crystal clear where the reverse record will point -- example.com.
There is no ambiguity or option for inconsistency.

  - Kevin

On 9/10/2014 5:48 PM, Eliezer Croitoru wrote:

Hey Kevin,

This is not an issue at all.
A PTR is different then a A record and can be used by two reverse
domain names and only the owner of the IP addresses space can define
them.
I am not sure if two PTR records for two domains will be applied to
one IP but it is possible for two IP addresses to have the same PTR.

Can we even use a CNAME as a PTR???

Eliezer

On 09/11/2014 12:37 AM, Kevin Darcy wrote:

Also, have you considered the forward/reverse ambiguity that arises when
multiple owner names resolve to the same address? To which of those
names does the PTR point?

  - Kevin

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

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




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

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



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

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


___
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 record of domain name must be name server ?

[Mark Elkins]

On Thu, 2014-09-11 at 11:27 -0400, Kevin Darcy wrote:
 Mark,
 Depending on implementation, a PTR RRset with multiple
 records either
 
 -- only ever gets answered with the first record of the set (in
 which case the second and subsequent records of the set are just a
 waste of space), or
 -- answers in a random, cyclic and/or round-robin fashion (in which
 case, the results are non-deterministic from the standpoint of a
 client, and this can cause problems and/or confusion)


Last time I checked, ALL matching records are returned as a single
Resource Record Set - (and in the case of DNSSEC - covered with a single
signature).

What the receiver does with it is up to that receiver... as you say -
some of the information may be discarded.

 So, although the standards allow multiple RRs, in practical terms, it
 only makes sense for a PTR RRset to contain a *single* RR.

I would still disagree. When there is forward--reverse checking, one
may need the complete answer. I certainly have some processes that do an
exhaustive check.


- Kevin
 
 On 9/11/2014 3:45 AM, Mark Elkins wrote:
 
  On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote:
   No, what I'm saying is that if
   
   example.com owns an A record 203.0.113.48, and
   www.example.com owns an A record 203.0.113.48, then
   
   where does 48.113.0.203.in-addr.arpa point?
   
   Some people will point it at example.com, some will point it at 
   www.example.com. What you get is a mish-mosh. No consistency.
  Although I prefer the use of a CNAME solution (CNAME www.example.com to
  example.com), in the case of separate A (and ) records, one could
  point the reverse to both names. Nothing wrong with a PTR record having
  more than one answer. There is then no inconsistency, just choice. After
  all, pretty much every NS record has at least two Right-Hand-Sides
  (Answers)
  
  
   If, on the other hand, www.example.com is a CNAME to example.com, then 
   it's crystal clear where the reverse record will point -- example.com. 
   There is no ambiguity or option for inconsistency.
   
- Kevin
   
   On 9/10/2014 5:48 PM, Eliezer Croitoru wrote:
Hey Kevin,

This is not an issue at all.
A PTR is different then a A record and can be used by two reverse 
domain names and only the owner of the IP addresses space can define 
them.
I am not sure if two PTR records for two domains will be applied to 
one IP but it is possible for two IP addresses to have the same PTR.

Can we even use a CNAME as a PTR???

Eliezer

On 09/11/2014 12:37 AM, Kevin Darcy wrote:
 Also, have you considered the forward/reverse ambiguity that arises 
 when
 multiple owner names resolve to the same address? To which of those
 names does the PTR point?
 
  - Kevin
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list

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



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

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za


smime.p7s
Description: S/MIME cryptographic signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: A record of domain name must be name server ?

[Matus UHLAR - fantomas]

On 9/11/2014 3:47 AM, Matus UHLAR - fantomas wrote:

On 10.09.14 18:13, Kevin Darcy wrote:

No, what I'm saying is that if

example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then

where does 48.113.0.203.in-addr.arpa point?


Completely your decision.
Some people will point it at example.com, some will point it at 
www.example.com. What you get is a mish-mosh. No consistency.


Do not mix multiple A and PTR. they are just different things.
You are creating issues where there are none.


On 11.09.14 11:20, Kevin Darcy wrote:
The issue is consistency. If you give admins choices where to point a 
PTR, and the RFCs don't provide any clear guidance, you're going to 
get inconsistent results.


sorry, but again - you are searching for consistency somewhere, where no
consistency (nor a PTR) is required.

Consistency is a good thing, isn't it? Sure, the earth isn't going to 
fall off its axis of rotation just because of the way people point 
their A and PTR records, CNAME or don't CNAME. But if we can nudge 
people in the direction of consistency, and there is no downside, why 
wouldn't we do that? That's what best practices are all about -- 
impelling people towards processes/methods/conventions that 
ultimately benefit *everyone*. Greatest good for the greatest number, 
and all that.


I haven't met a case where this level of consistency would be needed.
I have met a case where the only one A should point to an IP caused
troubles.

your argument fails immediately when there's need for more than just A on
www.example.com

(Yes, I'm aware that there was a proposal recently discussed on the 
DNSOP list for an MX-target convention to denote no mail service 
offered here. That would presumably solve the problem I cited in the 
previous paragraph. But AFAIK that proposal is many years away from 
widespread adoption, and even if adopted, it puts an extra burden on 
the DNS admins to populate the no service MX record, which, again, 
is going to produce inconsistent results -- some admins will remember 
to do it; many won't).


... and this is just example of it.


The same applies for all other RRs for exmaple.com Alan named crap.

Actually, the only other RR type that Alan enumerated specifically 
was NS, which operates on entirely different principles, and serves a 
significantly different function, than MX-based mail routing. Who 
would be looking up www.example.com with QTYPE=NS? Is that even a 
plausible use-case scenario?


well, me and Alan have shown examples why www CNAME @ is not a good idea.
we both also said it's personal preference.

What other RR types do you have in mind? 


Does it matter at all? It _may_ happen, and it's the case where CNAME is
not usable.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
___
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 record of domain name must be name server ?

[Kevin Darcy]

On 9/11/2014 12:08 PM, Matus UHLAR - fantomas wrote:

On 9/11/2014 3:47 AM, Matus UHLAR - fantomas wrote:

On 10.09.14 18:13, Kevin Darcy wrote:

No, what I'm saying is that if

example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then

where does 48.113.0.203.in-addr.arpa point?


Completely your decision.
Some people will point it at example.com, some will point it at 
www.example.com. What you get is a mish-mosh. No consistency.


Do not mix multiple A and PTR. they are just different things.
You are creating issues where there are none.


On 11.09.14 11:20, Kevin Darcy wrote:
The issue is consistency. If you give admins choices where to point a 
PTR, and the RFCs don't provide any clear guidance, you're going to 
get inconsistent results.


sorry, but again - you are searching for consistency somewhere, where no
consistency (nor a PTR) is required.

Consistency is a good thing, isn't it? Sure, the earth isn't going to 
fall off its axis of rotation just because of the way people point 
their A and PTR records, CNAME or don't CNAME. But if we can nudge 
people in the direction of consistency, and there is no downside, why 
wouldn't we do that? That's what best practices are all about -- 
impelling people towards processes/methods/conventions that 
ultimately benefit *everyone*. Greatest good for the greatest number, 
and all that.


I haven't met a case where this level of consistency would be needed.
Needed? Is that where you're setting the bar here? A little too high, 
I'd say. My point is that consistency is a good thing, and the CNAME to 
@ practice helps to foster that. Whether it's *needed* would be a whole 
other question. Somewhere between necessary and (what Alan called) 
preferences are these things called recommendations or best practices.




I have met a case where the only one A should point to an IP caused
troubles.
Well, sure. Some names, such as zone-apex names, *cannot* own CNAME 
records. If example1.com and example2.com need to resolve to the same 
IP, then, and assuming they are both zone-apex names, you're going to 
have multiple As with the same RDATA, and a reverse-record ambiguity. 
That's unavoidable. All I'm saying, is that in the normal case, where 
you have an option, CNAME to @ makes a lot of sense and should be 
followed.


your argument fails immediately when there's need for more than just A on
www.example.com
If the RDATA needs to be *different* between www and apex, or the 
application/subsystem which accesses the resource makes a distinction 
between canonical names and aliases, sure. I'm not laying down a 
hard-and-fast rule. Of course there will be exceptions, where the 
higher-level protocols or the user requirements demand it.


(Yes, I'm aware that there was a proposal recently discussed on the 
DNSOP list for an MX-target convention to denote no mail service 
offered here. That would presumably solve the problem I cited in the 
previous paragraph. But AFAIK that proposal is many years away from 
widespread adoption, and even if adopted, it puts an extra burden on 
the DNS admins to populate the no service MX record, which, again, 
is going to produce inconsistent results -- some admins will remember 
to do it; many won't).


... and this is just example of it.
An example of what? Of what bad things can happen when (semi-)important 
things are left to mere preference?



The same applies for all other RRs for exmaple.com Alan named crap.

Actually, the only other RR type that Alan enumerated specifically 
was NS, which operates on entirely different principles, and serves a 
significantly different function, than MX-based mail routing. Who 
would be looking up www.example.com with QTYPE=NS? Is that even a 
plausible use-case scenario?


well, me and Alan have shown examples why www CNAME @ is not a good 
idea.
Alan's concern was that the www name could get associated with record 
types that the DNS admin might not have expected. This is not a problem 
for a competent admin, who will have realistic expectations and an 
understanding of CNAME mechanics. You raised the possibility that a mail 
server might reject messages sent erroneously to www and I responded 
that if it's going to fail anyway, at least that failure mode is better 
than a mail server trying to deliver mail to a web server (which is what 
happens in the same scenario when www is an independent A record).


You got anything else?


we both also said it's personal preference.
And I'm saying that's a cop-out. It should be a recommended practice -- 
except where there are special mitigating circumstances which make it 
inappropriate or unworkable -- not merely a preference. Hair styles 
and musical genres are preferences; encouraging consistent 
forward/reverse mappings is something that all DNS admins have a stake 
in, whether they realize it or not.




What other RR types do you have in mind? 


Does it matter at all? It _may_ happen, and it's the case 

Re: A record of domain name must be name server ?

[Matus UHLAR - fantomas]

On 9/11/2014 12:08 PM, Matus UHLAR - fantomas wrote:

we both also said it's personal preference.


On 11.09.14 12:53, Kevin Darcy wrote:
And I'm saying that's a cop-out. It should be a recommended practice 


encouraging consistent 
forward/reverse mappings is something that all DNS admins have a 
stake in, whether they realize it or not.


correct reverse-forward mappings - yes.
correct forward-reverse mappings - no.

In zones apexes it's sometimes just impossible and I have already met people
uselessly insisting on such (pardon me) shit without understanding real
(and potentially much bigger) problem.

It's not usable where it's not usable, of course. But, where it *is* 
usable, I'm just saying it's recommended,


It's definitely not recommended by me. You are of course free to recommend
what you choose, but I think I should warn you I'll oppose that...

Did you seriously think I'd recommend 
something that *doesn't*work*? Please, give me a little more credit 
than that.


I remember you from your postings here, so I really don't think you are
incompetent, especially not an idiot :-)

I just don't agree with this point, because I have already met people not
getting this properly and insisting on something that was likely to get them
into troubles bigger than with having multiple A's...

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watson.  -- Daffy Duck  Porky Pig
___
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 record of domain name must be name server ?

[Bob Harold]

In reference to the question of using a CNAME or A record for 
www.example.com, it seems to me that the best solution, if we could ever
get there, would be to create a new record type that means redirect an A
or  lookup to this other name.  Like this:

example.com.  IN  SOA  
example.com.  IN  ANAME  my.webhosting.com.
www.example.com.  IN  CNAME  my.webhosting.com.

I use ANAME to mean like a CNAME, but only for A and  lookups, with
no restrictions on other names with the same left side (except perhaps
other A and  records if that is necessary for technical reasons).

Several DNS and hosting providers provide similar functionality, but is
there any chance of widespread DNS support for something like this?

Is there already and RFC for this?

I find these interesting sites:
http://www.dnsmadeeasy.com/services/aname-records/
http://aws.amazon.com/route53/faqs/#Supported_DNS_record_types
http://blog.andrewallen.co.uk/2012/06/27/cname-is-out-hello-aname/
(This last one points out a problem with the current implementations - I
think proper support in the DNS protocol would solve this.)

-- 
Bob Harold
DNS and DHCP
University of Michigan
___
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 record of domain name must be name server ?

[Kevin Darcy]

On 9/11/2014 11:51 AM, Mark Elkins wrote:

On Thu, 2014-09-11 at 11:27 -0400, Kevin Darcy wrote:

Mark,
 Depending on implementation, a PTR RRset with multiple
records either

-- only ever gets answered with the first record of the set (in
which case the second and subsequent records of the set are just a
waste of space), or
-- answers in a random, cyclic and/or round-robin fashion (in which
case, the results are non-deterministic from the standpoint of a
client, and this can cause problems and/or confusion)


Last time I checked, ALL matching records are returned as a single
Resource Record Set - (and in the case of DNSSEC - covered with a single
signature).

What the receiver does with it is up to that receiver... as you say -
some of the information may be discarded.
If the invoker is using the classic gethostbyaddr() interface, then 
it'll only see the RDATA from the first PTR RR, where first is 
determined by the local nameserver implementation and/or the local 
Operating System interface for name resolution.



So, although the standards allow multiple RRs, in practical terms, it
only makes sense for a PTR RRset to contain a *single* RR.

I would still disagree. When there is forward--reverse checking, one
may need the complete answer. I certainly have some processes that do an
exhaustive check.
Certainly if one gets down to the resolver-library level and grovels 
through all of the RRs in the Answer Section of the response packet, one 
could certainly care more than the typical reverse-resolving 
app/subsystem would. And any software that builds up certain heightened 
expectations is likely to complain if those expectations are not met.


- Kevin

On 9/11/2014 3:45 AM, Mark Elkins wrote:


On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote:

No, what I'm saying is that if

example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then

where does 48.113.0.203.in-addr.arpa point?

Some people will point it at example.com, some will point it at
www.example.com. What you get is a mish-mosh. No consistency.

Although I prefer the use of a CNAME solution (CNAME www.example.com to
example.com), in the case of separate A (and ) records, one could
point the reverse to both names. Nothing wrong with a PTR record having
more than one answer. There is then no inconsistency, just choice. After
all, pretty much every NS record has at least two Right-Hand-Sides
(Answers)



If, on the other hand, www.example.com is a CNAME to example.com, then
it's crystal clear where the reverse record will point -- example.com.
There is no ambiguity or option for inconsistency.

  - Kevin

On 9/10/2014 5:48 PM, Eliezer Croitoru wrote:

Hey Kevin,

This is not an issue at all.
A PTR is different then a A record and can be used by two reverse
domain names and only the owner of the IP addresses space can define
them.
I am not sure if two PTR records for two domains will be applied to
one IP but it is possible for two IP addresses to have the same PTR.

Can we even use a CNAME as a PTR???

Eliezer

On 09/11/2014 12:37 AM, Kevin Darcy wrote:

Also, have you considered the forward/reverse ambiguity that arises when
multiple owner names resolve to the same address? To which of those
names does the PTR point?

  - Kevin

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

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




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

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


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

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

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

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



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

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


___
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 record of domain name must be name server ?

[Thomas Schulz]

 On 9/11/2014 11:51 AM, Mark Elkins wrote:
 On Thu, 2014-09-11 at 11:27 -0400, Kevin Darcy wrote:
 Mark,
  Depending on implementation, a PTR RRset with multiple
 records either

 -- only ever gets answered with the first record of the set (in
 which case the second and subsequent records of the set are just a
 waste of space), or
 -- answers in a random, cyclic and/or round-robin fashion (in which
 case, the results are non-deterministic from the standpoint of a
 client, and this can cause problems and/or confusion)

 Last time I checked, ALL matching records are returned as a single
 Resource Record Set - (and in the case of DNSSEC - covered with a single
 signature).

 What the receiver does with it is up to that receiver... as you say -
 some of the information may be discarded.
 If the invoker is using the classic gethostbyaddr() interface, then 
 it'll only see the RDATA from the first PTR RR, where first is 
 determined by the local nameserver implementation and/or the local 
 Operating System interface for name resolution.

 So, although the standards allow multiple RRs, in practical terms, it
 only makes sense for a PTR RRset to contain a *single* RR.
 I would still disagree. When there is forward--reverse checking, one
 may need the complete answer. I certainly have some processes that do an
 exhaustive check.
 Certainly if one gets down to the resolver-library level and grovels 
 through all of the RRs in the Answer Section of the response packet, one 
 could certainly care more than the typical reverse-resolving 
 app/subsystem would. And any software that builds up certain heightened 
 expectations is likely to complain if those expectations are not met.
 
  - Kevin
 On 9/11/2014 3:45 AM, Mark Elkins wrote:

 On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote:
 No, what I'm saying is that if

 example.com owns an A record 203.0.113.48, and
 www.example.com owns an A record 203.0.113.48, then

 where does 48.113.0.203.in-addr.arpa point?

 Some people will point it at example.com, some will point it at
 www.example.com. What you get is a mish-mosh. No consistency.
 Although I prefer the use of a CNAME solution (CNAME www.example.com to
 example.com), in the case of separate A (and ) records, one could
 point the reverse to both names. Nothing wrong with a PTR record having
 more than one answer. There is then no inconsistency, just choice. After
 all, pretty much every NS record has at least two Right-Hand-Sides
 (Answers)


 If, on the other hand, www.example.com is a CNAME to example.com, then
 it's crystal clear where the reverse record will point -- example.com.
 There is no ambiguity or option for inconsistency.

   - Kevin

 On 9/10/2014 5:48 PM, Eliezer Croitoru wrote:
 Hey Kevin,

 This is not an issue at all.
 A PTR is different then a A record and can be used by two reverse
 domain names and only the owner of the IP addresses space can define
 them.
 I am not sure if two PTR records for two domains will be applied to
 one IP but it is possible for two IP addresses to have the same PTR.

 Can we even use a CNAME as a PTR???

 Eliezer

 On 09/11/2014 12:37 AM, Kevin Darcy wrote:
 Also, have you considered the forward/reverse ambiguity that arises when
 multiple owner names resolve to the same address? To which of those
 names does the PTR point?

   - Kevin

Well, this is certainly getting far away from an answer to the original
qustion!

Originally our web server was only available as www.adi.com. Later I
noticed that a lot of sites were available without the www. So I decided
to allow our web server to be available as adi.com. But I still consider
www.adi.com to be the real name of the server. And I certainly can not
alias adi.com to www.adi.com!

Tom Schulz
Applied Dynamics Intl.
sch...@adi.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: A record of domain name must be name server ?

[Mark Andrews]

In message 5411bdd6.4010...@chrysler.com, Kevin Darcy writes:
 (Yes, I'm aware that there was a proposal recently discussed on the 
 DNSOP list for an MX-target convention to denote no mail service 
 offered here. That would presumably solve the problem I cited in the 
 previous paragraph. But AFAIK that proposal is many years away from 
 widespread adoption, and even if adopted, it puts an extra burden on the 
 DNS admins to populate the no service MX record, which, again, is 
 going to produce inconsistent results -- some admins will remember to do 
 it; many won't).

No, it's more like formalising existing practice.  Universal adoption
would be a long time off but there is a large existing base of MTA's
that will do the right thing.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: A record of domain name must be name server ?

[Thomas Schulz]

 Hi,
 
 xxx.com and IP address 192.168.1.100 is just a example domain name and IP
 address. Our boss want everybody access our domain example.com through
 browser, then it will redirect to our web site www.example.com. So I want
 to get more information about unexpected impact when we changed DNS records.
 
 Thanks for your help.
 
 Best Regards,
 Pete Fong

Here is how I have things set up here. Our domain is adi.com. We have
three name servers set up. Our web site can be accessed as both
www.adi.com and adi.com. Here is what I have on our zone file:


@   in  ns  bluegill.adi.com.
in  ns  a.dns.tds.net.
in  ns  seahorse.adi.com.

bluegillin  A   75.100.245.131
seahorsein  A   75.100.245.134
www in  A   75.100.245.133
@   in  A   75.100.245.133

@   in  mx  0   mackerel.adi.com.
in  mx  10  seahorse.adi.com.
in  mx  20  bluegill.adi.com.

Note that address 75.100.245.133 is entered twice.
The mx records are to get email to work correctly.

Tom Schulz
Applied Dynamics Intl.
sch...@adi.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: A record of domain name must be name server ?

[Sam Wilson]

In article mailman.890.1410357943.26362.bind-us...@lists.isc.org,
 sch...@adi.com (Thomas Schulz) wrote:

  Hi,
  
  xxx.com and IP address 192.168.1.100 is just a example domain name and IP
  address. Our boss want everybody access our domain example.com through
  browser, then it will redirect to our web site www.example.com. So I want
  to get more information about unexpected impact when we changed DNS records.
  
  Thanks for your help.
  
  Best Regards,
  Pete Fong
 
 Here is how I have things set up here. Our domain is adi.com. We have
 three name servers set up. Our web site can be accessed as both
 www.adi.com and adi.com. Here is what I have on our zone file:
 
 
 @   in  ns  bluegill.adi.com.
 in  ns  a.dns.tds.net.
 in  ns  seahorse.adi.com.
 
 bluegillin  A   75.100.245.131
 seahorsein  A   75.100.245.134
 www in  A   75.100.245.133
 @   in  A   75.100.245.133
 
 @   in  mx  0   mackerel.adi.com.
 in  mx  10  seahorse.adi.com.
 in  mx  20  bluegill.adi.com.
 
 Note that address 75.100.245.133 is entered twice.
 The mx records are to get email to work correctly.

And you could reduce maintenance very slightly by replacing

www in  A   75.100.245.133

with 

www in  CNAME   @

Though in Thomas' case the PTR record for 75.100.245.133 returns 
www.adi.com, so that's a good reason for not doing the CNAME thing.

Sam

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

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

Re: A record of domain name must be name server ?

[Alan Clegg]

On 9/10/14, 8:42 AM, Sam Wilson wrote:

 And you could reduce maintenance very slightly by replacing
 
 www in  A   75.100.245.133
 
 with 
 
 www in  CNAME   @

And now you have an MX record, 3 NS records and a bunch of other crap
associated with the WWW address.  Keeping track of one extra A record
(and associated  record if you go in that direction) isn't a bad thing.

(Personal preferences, of course)

AlanC



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

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

Re: A record of domain name must be name server ?

[Matus UHLAR - fantomas]

On 9/10/14, 8:42 AM, Sam Wilson wrote:

And you could reduce maintenance very slightly by replacing

www in  A   75.100.245.133

with

www in  CNAME   @


On 10.09.14 08:58, Alan Clegg wrote:

And now you have an MX record, 3 NS records and a bunch of other crap
associated with the WWW address.  Keeping track of one extra A record
(and associated  record if you go in that direction) isn't a bad thing.


simply said: don't CNAME to @.


(Personal preferences, of course)


yes, but still...
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
___
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 record of domain name must be name server ?

[Kevin Darcy]

On 9/10/2014 11:58 AM, Alan Clegg wrote:

On 9/10/14, 8:42 AM, Sam Wilson wrote:


And you could reduce maintenance very slightly by replacing

www in  A   75.100.245.133

with

www in  CNAME   @

And now you have an MX record, 3 NS records and a bunch of other crap
associated with the WWW address.

And why is that a _bad_ thing?

If I ever change that IP, I want to change it in *one*place*. The CNAME 
allows everything to automatically follow that change. Why necessitate 
multiple updates when a single update will do? If TTL-manipulation is 
necessary in order to minimize caching complications, the number of 
RRset updates is magnified, of course.


MXes and NSes are a non-issue, IMO, since the contexts in which people 
look up a www name (usually end-users trying to access a website) are 
usually quite disjoint from the use cases of MXes (automated systems 
delivering mail) or NSes (nameserver-to-nameserver traffic). I see 
little or no risk of confusion or misdirection.


I suppose it's _possible_ that some day a mail sender might mistype a 
recipient as u...@www.example.com instead of (as they should have) 
u...@example.com, and maybe in that scenario the CNAME will cause the 
recipient address to show up in the headers of the received message in 
an unexpected way. But, to me, this falls under the generic category of 
GIGO (garbage in, garbage out) -- you type something wrong into a 
computer system, you might not get the results you expected...


- Kevin



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

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


___
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 record of domain name must be name server ?

[Alan Clegg]

On 9/10/14, 2:13 PM, Kevin Darcy wrote:
 On 9/10/2014 11:58 AM, Alan Clegg wrote:
 On 9/10/14, 8:42 AM, Sam Wilson wrote:

 And you could reduce maintenance very slightly by replacing

 www in  A   75.100.245.133

 with 

 www in  CNAME   @

 And now you have an MX record, 3 NS records and a bunch of other crap
 associated with the WWW address.  

 And why is that a _bad_ thing?

(Personal preferences, of course)

Answered before asked.

AlanC



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

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

Re: A record of domain name must be name server ?

[Kevin Darcy]

On 9/10/2014 5:20 PM, Alan Clegg wrote:

On 9/10/14, 2:13 PM, Kevin Darcy wrote:

On 9/10/2014 11:58 AM, Alan Clegg wrote:

On 9/10/14, 8:42 AM, Sam Wilson wrote:


And you could reduce maintenance very slightly by replacing

www in  A   75.100.245.133

with

www in  CNAME   @

And now you have an MX record, 3 NS records and a bunch of other crap
associated with the WWW address.

And why is that a _bad_ thing?

(Personal preferences, of course)

Answered before asked.

Well, I was asking about your _particular_ preference, which seemed 
rather clear from your use of the word crap. Why does it matter (in 
_your_ opinion) if the target of the www CNAME owns records of more 
types than just A and/or ?


Also, have you considered the forward/reverse ambiguity that arises when 
multiple owner names resolve to the same address? To which of those 
names does the PTR point?


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

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

Re: A record of domain name must be name server ?

[Eliezer Croitoru]

Hey Kevin,

This is not an issue at all.
A PTR is different then a A record and can be used by two reverse 
domain names and only the owner of the IP addresses space can define them.
I am not sure if two PTR records for two domains will be applied to one 
IP but it is possible for two IP addresses to have the same PTR.


Can we even use a CNAME as a PTR???

Eliezer

On 09/11/2014 12:37 AM, Kevin Darcy wrote:

Also, have you considered the forward/reverse ambiguity that arises when
multiple owner names resolve to the same address? To which of those
names does the PTR point?

 - Kevin


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

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

Re: A record of domain name must be name server ?

[Kevin Darcy]

No, what I'm saying is that if

example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then

where does 48.113.0.203.in-addr.arpa point?

Some people will point it at example.com, some will point it at 
www.example.com. What you get is a mish-mosh. No consistency.


If, on the other hand, www.example.com is a CNAME to example.com, then 
it's crystal clear where the reverse record will point -- example.com. 
There is no ambiguity or option for inconsistency.


- Kevin

On 9/10/2014 5:48 PM, Eliezer Croitoru wrote:

Hey Kevin,

This is not an issue at all.
A PTR is different then a A record and can be used by two reverse 
domain names and only the owner of the IP addresses space can define 
them.
I am not sure if two PTR records for two domains will be applied to 
one IP but it is possible for two IP addresses to have the same PTR.


Can we even use a CNAME as a PTR???

Eliezer

On 09/11/2014 12:37 AM, Kevin Darcy wrote:

Also, have you considered the forward/reverse ambiguity that arises when
multiple owner names resolve to the same address? To which of those
names does the PTR point?

 - Kevin


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


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





___
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 record of domain name must be name server ?

[Eliezer Croitoru]

Well this is a confusing point but it's rather an administrative 
decision to make.
If indeed the network\server\domain administrator is not aware of his 
services he will either have or will not have decision to make.

It will depend on whether he knows what he is doing.
Mish-mosh or banana he will eat it one way or another.

One conclusion he will probably learn is that dns records takes from 24 
to about 48 hours to be forgotten from dns caches :D


All The Bests,
Eliezer

On 09/11/2014 01:13 AM, Kevin Darcy wrote:

No, what I'm saying is that if

example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then

where does 48.113.0.203.in-addr.arpa point?

Some people will point it at example.com, some will point it at
www.example.com. What you get is a mish-mosh. No consistency.

If, on the other hand, www.example.com is a CNAME to example.com, then
it's crystal clear where the reverse record will point -- example.com.
There is no ambiguity or option for inconsistency.

 - Kevin


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

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

Re: A record of domain name must be name server ?

[Pete Fong]

Hi Kevin,

Thanks for your help. Do not worry. The IP address 192.168.1.100 is just
for example.

Best Regards,
Pete Fong


2014-09-09 3:30 GMT+08:00 Kevin Darcy k...@chrysler.com:

  Based on the zone contents below, you shouldn't have any problem
 changing the 192.168.1.100 address to anything you want.

 But, of course, the zone is illegal because it only has 1 NS record
 published at the apex (there is a strict minimum of at least 2), and, as it
 stands now, if it is an Internet-facing zone, it's also illegal due to the
 presence of a private (192.168.*.*) address in the zone. You said that
 192.168.1.100 is our one of DNS server, but hopefully you don't mean that
 it's a nameserver for *this* zone, or that the zone is not Internet-facing,
 or the 192.168.1.100 address is presented in a NAT (network address
 translated) form to the Internet, since, again, you can't use private
 addresses on the Internet. By definition.



 - Kevin
 On 9/8/2014 3:43 AM, Pete Fong wrote:

  Hi Everybody,

  The below item is our DNS (BIND) server configuration. our Domain*
 xxx.com http://xxx.com *is assigned IP address 192.168.1.100 which is
 our one of DNS server. Can we change it to our web server IP address ?
 Because we want anybody access our domain *xxx.com http://xxx.com* with
 internet browser then it will go to our webpage. Am I correct ? I really
 appreciate anybody help.

 @  IN SOA ns1.xxx.com. root.ns1.xxx.com (
   2014090801 ; serial
   2h  ; refresh
   10m; retry
   1w ; expiry
   1h )

 IN NS ns1.xxx.com.
 IN A  192.168.1.100

  Thank and Best Regards,
  Pete Fong


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

 bind-users mailing 
 listbind-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users



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

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

___
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 record of domain name must be name server ?

[Pete Fong]

Hi,

xxx.com and IP address 192.168.1.100 is just a example domain name and IP
address. Our boss want everybody access our domain example.com through
browser, then it will redirect to our web site www.example.com. So I want
to get more information about unexpected impact when we changed DNS records.

Thanks for your help.

Best Regards,
Pete Fong




2014-09-08 20:02 GMT+08:00 /dev/rob0 r...@gmx.co.uk:

 On Mon, Sep 08, 2014 at 03:43:22PM +0800, Pete Fong wrote:
  The below item is our DNS (BIND) server configuration. our Domain*
  xxx.com

 I think that is a porn site.  If you mean to use that name as an
 example, please use example.com instead.  Putting HTTP links to
 pornography in your emails is a sure way to fall afoul of various
 content filtering solutions which are in common use.

 See RFC 2606 regarding reserved domain names like example.com.

  http://xxx.com *is assigned IP address 192.168.1.100 which is
  our one of DNS server. Can we change it to our web server IP
  address ? Because we want anybody access our domain *xxx.com
  http://xxx.com* with internet browser then it will go to our
  webpage. Am I correct ? I really appreciate anybody help.

 It's not unusual to point an A record for @ at a HTTP server.
 Whatever you are not understanding here, I can't tell.

  @  IN SOA ns1.xxx.com. root.ns1.xxx.com (
2014090801 ; serial
2h  ; refresh
10m; retry
1w ; expiry
1h )
 
  IN NS ns1.xxx.com.
  IN A  192.168.1.100

 This zone file would fail named-checkzone(8) testing if loaded as
 xxx.com, because there is no A record for the NS name,
 ns1.xxx.com.  This zone would fail to load.

 If any of your NS names are inside the zone, you must have either or
 both A and  records for those NS names.  Here is the same zone
 without the XXX and with all relative names:

  @  IN SOA ns1 root.ns1 (
2014090801 ; serial
2h  ; refresh
10m; retry
1w ; expiry
1h )
 
  IN NS ns1
  IN A  192.168.1.100
  ns1 IN A  192.168.1.100
 --
   http://rob0.nodns4.us/
   Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to
 unsubscribe from this list

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

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

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

Re: A record of domain name must be name server ?

[Matus UHLAR - fantomas]

On 08.09.14 15:43, Pete Fong wrote:

Subject: A record of domain name must be name server ?


no.


The below item is our DNS (BIND) server configuration. our Domain* xxx.com
http://xxx.com *is assigned IP address 192.168.1.100 which is our one of
DNS server. Can we change it to our web server IP address ? 


yes.

... it's completely irelevant where does example.com A record point to.


It could only issue a problem if you pointed example.com. NS example.com.
or similar MX etc recods.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I intend to live forever - so far so good. 
___

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 record of domain name must be name server ?

[Pete Fong]

Hi Matus UHLAR - fantomas,

Sorry, I do not understand the meaning of It could only issue a problem if
you pointed example.com. NS example.com.
or similar MX etc records.  Do you mind to explain more details ? Thank
you very much.

Best Regards,
Pete Fong



2014-09-08 16:06 GMT+08:00 Matus UHLAR - fantomas uh...@fantomas.sk:

 On 08.09.14 15:43, Pete Fong wrote:

 Subject: A record of domain name must be name server ?


 no.

  The below item is our DNS (BIND) server configuration. our Domain*
 xxx.com
 http://xxx.com *is assigned IP address 192.168.1.100 which is our one
 of
 DNS server. Can we change it to our web server IP address ?


 yes.

 ... it's completely irelevant where does example.com A record point to.


 It could only issue a problem if you pointed example.com. NS example.com
 .
 or similar MX etc recods.

 --
 Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
 Warning: I wish NOT to receive e-mail advertising to this address.
 Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
 I intend to live forever - so far so good. __
 _
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to
 unsubscribe from this list

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

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

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

Re: A record of domain name must be name server ?

[Barry Margolin]

In article mailman.871.1410167955.26362.bind-us...@lists.isc.org,
 Pete Fong petefong2...@gmail.com wrote:

 Hi Matus UHLAR - fantomas,
 
 Sorry, I do not understand the meaning of It could only issue a problem if
 you pointed example.com. NS example.com.
 or similar MX etc records.  Do you mind to explain more details ? Thank
 you very much.

NS records tell everyone where the DNS servers for the domain are. So 
xxx.com only has to be assigned the IP of the DNS server if you have an 
NS record that says that xxx.com is the DNS server for xxx.com.

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

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

Re: A record of domain name must be name server ?

[/dev/rob0]

On Mon, Sep 08, 2014 at 03:43:22PM +0800, Pete Fong wrote:
 The below item is our DNS (BIND) server configuration. our Domain* 
 xxx.com

I think that is a porn site.  If you mean to use that name as an 
example, please use example.com instead.  Putting HTTP links to 
pornography in your emails is a sure way to fall afoul of various 
content filtering solutions which are in common use.

See RFC 2606 regarding reserved domain names like example.com.

 http://xxx.com *is assigned IP address 192.168.1.100 which is
 our one of DNS server. Can we change it to our web server IP 
 address ? Because we want anybody access our domain *xxx.com 
 http://xxx.com* with internet browser then it will go to our 
 webpage. Am I correct ? I really appreciate anybody help.

It's not unusual to point an A record for @ at a HTTP server. 
Whatever you are not understanding here, I can't tell.

 @  IN SOA ns1.xxx.com. root.ns1.xxx.com (
   2014090801 ; serial
   2h  ; refresh
   10m; retry
   1w ; expiry
   1h )
 
 IN NS ns1.xxx.com.
 IN A  192.168.1.100

This zone file would fail named-checkzone(8) testing if loaded as 
xxx.com, because there is no A record for the NS name, 
ns1.xxx.com.  This zone would fail to load.

If any of your NS names are inside the zone, you must have either or 
both A and  records for those NS names.  Here is the same zone 
without the XXX and with all relative names:

 @  IN SOA ns1 root.ns1 (
   2014090801 ; serial
   2h  ; refresh
   10m; retry
   1w ; expiry
   1h )
 
 IN NS ns1
 IN A  192.168.1.100
 ns1 IN A  192.168.1.100
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
___
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 record of domain name must be name server ?

[Kevin Darcy]

Based on the zone contents below, you shouldn't have any problem 
changing the 192.168.1.100 address to anything you want.


But, of course, the zone is illegal because it only has 1 NS record 
published at the apex (there is a strict minimum of at least 2), and, as 
it stands now, if it is an Internet-facing zone, it's also illegal due 
to the presence of a private (192.168.*.*) address in the zone. You said 
that 192.168.1.100 is our one of DNS server, but hopefully you don't 
mean that it's a nameserver for *this* zone, or that the zone is not 
Internet-facing, or the 192.168.1.100 address is presented in a NAT 
(network address translated) form to the Internet, since, again, you 
can't use private addresses on the Internet. By definition.


- Kevin
On 9/8/2014 3:43 AM, Pete Fong wrote:

Hi Everybody,

The below item is our DNS (BIND) server configuration. our 
Domain*xxx.com http://xxx.com *is assigned IP address 192.168.1.100 
which is our one of DNS server. Can we change it to our web server IP 
address ? Because we want anybody access our domain *xxx.com 
http://xxx.com* with internet browser then it will go to our 
webpage. Am I correct ? I really appreciate anybody help.


@  IN SOA ns1.xxx.com http://ns1.xxx.com. root.ns1.xxx.com 
http://root.ns1.xxx.com (

  2014090801 ; serial
  2h  ; refresh
  10m; retry
  1w ; expiry
  1h )

IN NS ns1.xxx.com http://ns1.xxx.com.
IN A  192.168.1.100

Thank and Best Regards,
Pete Fong


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

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


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

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

Re: PTR Record Issue

[Mark Andrews]

In message 525f4eea.5060...@cd.kcfam.net, Casey Daniels writes:
 Hello,
   I hope this is the right place to ask this question, if not maybe 
 someone could point me in the right direction.
 
 I'm using Bind 9.9.3-P2 and have the following issue
 
 when ever I run host ::1I always get 1.0.0..ip6.arpa has no PTR 
 Record.
 
 I'm pretty sure I have everything straight because if I were to type 
 host ::2 I get an a plain old doesn't exist message.  And for the fun of 
 it I added a record of 2.0.0.0.0.0.0 and then hosting ::2 gives me 
 an the expected answer.

Presumably you have 'zone 1.0.0.0.0.ip6.arpa {  };' in named.conf.

You need @ IN PTR localhost. not 1 IN PTR localhost..  This puts the
PTR record at the top of the zone not one label further down.

Also make sure the IPv4 reverse zone is called 1.0.0.127.in-addr.arpa,
not 0.0.127.in-addr.arpa, if it is using the same master file.

 
 Thank You,
 Casey
 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
  from this list
 
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: TXT Record Format with multiple records?

[Chris Thompson]

On Oct 12 2013, John Levine wrote:


Please forgive my ignorance, and sorry about all the details. I have
not been able to find a detailed specification.


TXT records haven't changed since RFC 1034 and 1035.

You can have multiple strings per record, and multiple records per
name.  At the application level, some applications glom multiple
strings per record together, some treat them separately.  There are a
few obscure designs that combine multiple TXT records at the same
name, but you're unlikely to run into any of them.


If you do use multiple TXT records, rather than multiple strings within
a single record, bear in mind that the order that the user/application
will see them is TAIAP unpredictable. You don't want to end up with

message.example.  TXT  is displayed in the right
message.example.  TXT  only makes sense when it
message.example.  TXT  order!
message.example.  TXT  A paragraph of text that

--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: TXT Record Format with multiple records?

[Mark Andrews]

In message CAH8yC8mWS=kypska2qv2r-stctw_mhhyprn42aa_cm1y7+0...@mail.gmail.com
, Jeffrey Walton writes:
  plugh.example TXT foo bar
 
 Thanks John.
 
 So I'm clear: (1) there is only one TXT record per host;

No.

 (2) multiple TXT records are not allowed;

No.

and (3) the individual character strings are delimited with the quote
character.

Yes and no.
 
 Related: is there an escape character so a quote can be present in the
 character-string?

Yes,  back slash.
 
 Related: is the single quote also accetped? What happens if the string
 is Knuth said, 'random numbers should not be generated with a method
 chosen at random.'
 
 Finally, is there a standard document that calls the convention out?

Yes.  RFC 1035 Section 5.1. Format.

character-string is expressed in one or two ways: as a contiguous set
of characters without interior spaces, or as a string beginning with a 
and ending with a .  Inside a  delimited string any character can
occur, except for a  itself, which must be quoted using \ (back slash).

Which is combined with the following to allow any 8 bit character
and to allow back slash to exist in a character-string.  Note the
escape conventions are not the same a in C.

\X  where X is any character other than a digit (0-9), is
used to quote that character so that its special meaning
does not apply.  For example, \. can be used to place
a dot character in a label.

\DDDwhere each D is a digit is the octet corresponding to
the decimal number described by DDD.  The resulting
octet is assumed to be text and is not checked for
special meaning.

Mark
 
 Please forgive my ignorance, and sorry about all the details. I have
 not been able to find a detailed specification.
 
 Jeff
 
 
 On Sat, Oct 12, 2013 at 12:52 AM, John Levine jo...@iecc.com wrote:
 How, precisely, is the second (or third) string added?
 
  plugh.example TXT foo bar
 
 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
  from this list
 
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: TXT Record Format with multiple records?

[John Levine]

Please forgive my ignorance, and sorry about all the details. I have
not been able to find a detailed specification.

TXT records haven't changed since RFC 1034 and 1035.

You can have multiple strings per record, and multiple records per
name.  At the application level, some applications glom multiple
strings per record together, some treat them separately.  There are a
few obscure designs that combine multiple TXT records at the same
name, but you're unlikely to run into any of 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: TXT Record Format with multiple records?

[John Levine]

How, precisely, is the second (or third) string added?

plugh.example TXT foo bar

___
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: TXT Record Format with multiple records?

[Jeffrey Walton]

 plugh.example TXT foo bar

Thanks John.

So I'm clear: (1) there is only one TXT record per host; (2) multiple
TXT records are not allowed; and (3) the individual character strings
are delimited with the quote character.

Related: is there an escape character so a quote can be present in the
character-string?

Related: is the single quote also accetped? What happens if the string
is Knuth said, 'random numbers should not be generated with a method
chosen at random.'

Finally, is there a standard document that calls the convention out?

Please forgive my ignorance, and sorry about all the details. I have
not been able to find a detailed specification.

Jeff


On Sat, Oct 12, 2013 at 12:52 AM, John Levine jo...@iecc.com wrote:
How, precisely, is the second (or third) string added?

 plugh.example TXT foo bar

___
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: NS record TTL versus nameserver's A record TTL

[Matthias Wimmer]

Hi John,

El 2013-10-08 11:49:24, John Wobus escribió:
 They took responsibility for their
 nameserver's deficiency, but it
 makes me wonder:
 -Is this addressed by a standard?  E.g.,
  the nameserver's A record have the same
  TTL as NS records pointing at it.
 -Is this addressed by a best practice?

I don't of any standard addressing this. Neither I know a best practice
document on this.

But due to my experience, it is a quite common practice to have longer
TTL on NS records than on A records. I consider this quite normal, as
often you will more often change individual host's IP address than the
addresses of your nameservers.
Setting longer TTLs on the NS records reduces load on the higher level
DNS servers while allowing you to update entries in your zone faster.

For example DynDNS uses a TTL of 60 seconds for their customer's A
records while having a TTL value of 86400 seconds (1 day) on their NS
records.


Regards,
Matthias

-- 
Matthias Wimmer
Contact details: http://matthias.wimmer.tel/


smime.p7s
Description: S/MIME cryptographic signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: NS record TTL versus nameserver's A record TTL

[Matus UHLAR - fantomas]

On 08.10.13 11:49, John Wobus wrote:

We received a report that a domain we serve
was not resolving at a remote site.  The site
also reported their own analysis that the issue
appeared to be that the domain's NS record had
a longer TTL than its target nameserver's
A record and their caching server didn't
seem able to handle this.  FYI, the nameserver
was not within the domain with the issue.


it's hard to say from this information. Maybe if you provided concrete
domain name(s) we could tell more.


They took responsibility for their
nameserver's deficiency, but it
makes me wonder:
-Is this addressed by a standard?  E.g.,
the nameserver's A record have the same
TTL as NS records pointing at it.


It should be the same, when the server is in the domain.  I met exactly
those issues when NS record had longer ttl then the A record in the same
domain.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...
___
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: SPF record with include:

[Chris Buxton]

On Jun 20, 2013, at 7:30 PM, Julie Xu j...@uws.edu.au wrote:

 Hi Steven, Jason, Ged and Bind expert
 
 Thanks for the reply. It is great help.
 
 However, I need ask more.
 
 For this include clause to be added in, I have also need to add DKIM records. 

SPF and DKIM are unrelated. There is no way to reference DKIM records inside 
your SPF records.

Chris
___
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: SPF record with include:

[Julie Xu]

Hi Steven, Jason, Ged and Bind expert

Thanks for the reply. It is great help.

However, I need ask more.

For this include clause to be added in, I have also need to add DKIM records. 

we do not use it currently, which means the mx part do not use, but include 
part will use it.

Could I get advice on if the DKIM records will impact the email service which 
related to mx related environment?

Thousands thanks for advice

Julie

-Original Message-
From: Steven Carr [mailto:sjc...@gmail.com] 
Sent: Tuesday, 18 June 2013 4:11 PM
To: Julie Xu
Cc: bind-users@lists.isc.org
Subject: Re: SPF record with include:

Remove the part... http://otheremailsrv.otherdomain, whatever mailer agent 
you use has screwed with the information that you were sent, it is not 
required. So your finished TXT record will be...

TXT v=spf1 mx include:otheremailsrv.otherdomain ~all

Steve


On 18 June 2013 06:56, Julie Xu j...@uws.edu.au wrote:
 Hi



 I be asked to add:

 include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain

  so the TXT records will be looked like:

 TXT v=spf1 mx
 include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain  ~all



 Question, from my limited research, I have not found any example to 
 put http part into TXT records, and a little bit worried.



 Could any one advice me if I can put http in spf record like above?



 If so, is my statement right?



 Any comments will be appreciated



 Thanks in advance



 julie


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

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

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

Re: SPF record with include:

[Steven Carr]

Remove the part... http://otheremailsrv.otherdomain, whatever
mailer agent you use has screwed with the information that you were
sent, it is not required. So your finished TXT record will be...

TXT v=spf1 mx include:otheremailsrv.otherdomain ~all

Steve


On 18 June 2013 06:56, Julie Xu j...@uws.edu.au wrote:
 Hi



 I be asked to add:

 include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain

  so the TXT records will be looked like:

 TXT v=spf1 mx
 include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain  ~all



 Question, from my limited research, I have not found any example to put http
 part into TXT records, and a little bit worried.



 Could any one advice me if I can put http in spf record like above?



 If so, is my statement right?



 Any comments will be appreciated



 Thanks in advance



 julie


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

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

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

Re: SPF record with include:

[Jason Hellenthal]

Really I can't see as it would hurt in either SPF/SPF or SPF/TXT

To me it looks to just be a referring URL for those that get a reject based on 
the SPF rule. Kinda like a comment judging by   .

I've not seen it in the wild this far besides this case. Not even in the google 
for business app references.

Personally I would just drop the http URL and angles.

Thus far I've only really had to use ip4 and 'a' and 'redirect' with no 
complaints.

-- 
 Jason Hellenthal
 Inbox: jhellent...@dataix.net
 Voice: +1 (616) 953-0176
 JJH48-ARIN


On Jun 18, 2013, at 1:56, Julie Xu j...@uws.edu.au wrote:

 Hi
  
 I be asked to add:
 include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain 
  so the TXT records will be looked like:
 TXT v=spf1 mx  
 include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain  ~all
  
 Question, from my limited research, I have not found any example to put http 
 part into TXT records, and a little bit worried.
  
 Could any one advice me if I can put http in spf record like above?
  
 If so, is my statement right?
  
 Any comments will be appreciated
  
 Thanks in advance
  
 julie
 ___
 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


smime.p7s
Description: S/MIME cryptographic signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: SPF record with include:

[G.W. Haywood]

Hi there,

On Tue, 18 Jun 2013, Julie Xu wrote:


I be asked to add:
include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain
 so the TXT records will be looked like:
 TXT v=spf1 mx include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain 
~all

Question, from my limited research, I have not found any example to
put http part into TXT records, and a little bit worried.

Could any one advice me if I can put http in spf record like above?


No, you cannot do that.  Also you should not use the 'mx mechanism'
unless you really know what you are doing.  It is almost always a bad
idea, not least because it wastes bandwidth.

It might be better to ask your question at spf-h...@listbox.com, but
PLEASE use real domain names in future when you ask your questions, it
is difficult to answer this kind of question without that information.

--

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

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

Re: cname record

[Chuck Swiger]

Hi, Dwayne--

On Mar 1, 2013, at 10:29 AM, Dwayne Hottinger wrote:
 I would like for users inside my network to not be able to do ssl searches 
 with google, because of cipa compliance issues.

OK, so you should block port tcp/443 to Google's network addresses 
(approximately 173.194.79.0/24) on your firewall.

  I added a cname record to my zone file:
 
 www.google.com CNAME nosslsearch.google.com
 
 To try and get it to redirect.  Since Im not authoritive for google, I dont 
 think this will work no matter how I tweak it.  Am I right in this assumption?

You can use RPZ capabilities in BIND to override their records:

  http://www.isc.org/software/rpz

...but that won't do anything to prevent a knowledgeable user from hitting 
something like https://173.194.79.99/ directly.

Regards,
-- 
-Chuck

___
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: DS record TTL question.

[GS Bryan]

Hmm... so what tool adds the DS key? I never use the dnssec-signzone
tool, so that's not it right? What I want is for the DS record to its
TTL the same as the rest of the zone entries.
--
Bryan S.G.


On Thu, Aug 9, 2012 at 1:26 PM, Mark Andrews ma...@isc.org wrote:

 In message 
 caektliseakw-xskaetgd7twkxuaxrkywyakybg2de_16trv...@mail.gmail.com
 , Casey Deccio writes:

 On Wed, Aug 8, 2012 at 9:36 AM, GS Bryan chif...@anime.my wrote:

  My question is how can I control the TTL of the DS record inserted into a
  signed zone via inline signing? I'm using BIND 9.9.1 P2.
 
  My zone file has a default TTL of 3600 a.k.a. 1 hour, but it seems the 2
  DS records put into the signed version of the zone has the TTL of 1 day. I
  would like that the zone default TTL be obeyed when the DS records are
  being inserted during inline signing.
 

 I don't know about BIND's default behavior for DS TTL or its options for
 customizing the TTL, but according to RFC 4035 (Section 2.4):

 The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
(that is, the NS RRset from the same zone containing the DS RRset).

 Casey

 Named doesn't add DS record as part of the inline signing process.

 You need to look at the tool used to add the DS records.

 Inline signing adds DNSKEY, NSEC, NSEC3 and NSEC3PARAM records.  DS
 is just data as far as inline signing is concerned.

 --
 Mark Andrews, ISC
 1 Seymour St., Dundas Valley, NSW 2117, Australia
 PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DS record TTL question.

[Mark Andrews]

In message caoj-cljgjtj_qm2pnfi3iv_0zzfxesnk9upuahhr-sukahr...@mail.gmail.com
, GS Bryan writes:
 Hmm... so what tool adds the DS key? I never use the dnssec-signzone
 tool, so that's not it right? What I want is for the DS record to its
 TTL the same as the rest of the zone entries.
 --
 Bryan S.G.

I don't know what tool you used.  If you are maintaining the records
by hand then you probably cut-and-pasted the records along with a
explicit TTL.  If you used nsupdate then the TTL was specified in
the update request.

Mark

 On Thu, Aug 9, 2012 at 1:26 PM, Mark Andrews ma...@isc.org wrote:
 
  In message CAEKtLiSEAkw-XskaeTgd7twkXUaxrkywYAkyBg2DE_16tRv61Q@mail.gmail.
 com
  , Casey Deccio writes:
 
  On Wed, Aug 8, 2012 at 9:36 AM, GS Bryan chif...@anime.my wrote:
 
   My question is how can I control the TTL of the DS record inserted into 
 a
   signed zone via inline signing? I'm using BIND 9.9.1 P2.
  
   My zone file has a default TTL of 3600 a.k.a. 1 hour, but it seems the 2
   DS records put into the signed version of the zone has the TTL of 1 day.
  I
   would like that the zone default TTL be obeyed when the DS records are
   being inserted during inline signing.
  
 
  I don't know about BIND's default behavior for DS TTL or its options for
  customizing the TTL, but according to RFC 4035 (Section 2.4):
 
  The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
 (that is, the NS RRset from the same zone containing the DS RRset).
 
  Casey
 
  Named doesn't add DS record as part of the inline signing process.
 
  You need to look at the tool used to add the DS records.
 
  Inline signing adds DNSKEY, NSEC, NSEC3 and NSEC3PARAM records.  DS
  is just data as far as inline signing is concerned.
 
  --
  Mark Andrews, ISC
  1 Seymour St., Dundas Valley, NSW 2117, Australia
  PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: NS record for subzone definition

[Casey Deccio]

On Tue, Mar 13, 2012 at 9:33 AM, hugo hugoo hugo...@hotmail.com wrote:

  Thanks for this interesting feedback.
 Now I have the problem to detect this kind of bad configuration.

 If I have:

 Zone toto.be:

 toto.be.

 NS  ns1.xxx.be

 + some records


 Zone titi.toto.be:


 titi.toto.be.

  NS   ns1.xxx.be

   + some records.


 What will be the command to detect that zone toto.be has no NS for
 titi.toto.be ??



Here's one command, given that ns1.xxx.be is authoritative for both toto.beand
titi.toto.be:

dig +noall +comments @ns1.xxx.be titi.toto.be ns | grep status: NOERROR
 \
  dig +noall +comments @ns1.xxx.be titi.toto.be ds | grep status: NXDOMAIN

A zero exit status for the above command indicates that the NS RRs are
missing from the parent.  Note, however, that a non-zero exit status
doesn't necessarily mean that the NS records exist.

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