Re: Troubleshooting DNSSEC issue w/ ic.fbi.gov

2013-07-18 Thread Casey Deccio
On Wed, Jul 17, 2013 at 10:58 AM, Bill Owens  wrote:
> This is one of the weirder ones I've seen. . . there are TXT and MX records 
> for ic.fbi.gov, both correctly signed:
>
> ...
> However, that NSEC3 record is not signed.

FWIW, DNSViz checks the chain of trust for authenticated
denial-of-existence, but it doesn't display it by default.  If you
select "denial of existence" from the "DNSSEC options" then you see
some errors on the left (maybe we could have it shown by default if
there are errors).

http://dnsviz.net/d/ic.fbi.gov/Ueea1Q/dnssec/?rr=all&a=all&ds=all&doe=on&ta=.&tk=

However, it seems the graph is missing corresponding red, dashed
arrows that are usually used to show when *some* servers are missing
RRSIGs--that will need to be looked into.  Because two of the servers
are returning RRSIGs for NSEC3, it does show arrows on the
authentication chain.  The rest, however, are certainly lacking
RRSIGs:

http://dnsviz.net/d/fbi.gov/UeeFmQ/servers/

Cheers,
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


Re: Troubleshooting DNSSEC issue w/ ic.fbi.gov

2013-07-18 Thread Barry S. Finkel

The SOA RNAME should work:


fbi.gov.600INSOAns1.fbi.gov. dns-admin.fbi.gov.
2013071601 7200 3600 2592000 43200


In my years as a DNS administrator, about 50% of the time I tried to
send e-mail to the SOA RNAME, that mail was returned as undeliverable.
I never have trusted that field.
--Barry Finkel

___
Please visit https://lists.isc.org/mailman/listinfo/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: Troubleshooting DNSSEC issue w/ ic.fbi.gov

2013-07-18 Thread Phil Mayers

On 18/07/13 14:35, Barry S. Finkel wrote:

The SOA RNAME should work:


fbi.gov.600INSOAns1.fbi.gov. dns-admin.fbi.gov.
2013071601 7200 3600 2592000 43200


In my years as a DNS administrator, about 50% of the time I tried to
send e-mail to the SOA RNAME, that mail was returned as undeliverable.
I never have trusted that field.


Unfortunately, this has been my experience. Clueful DNS admins keep it 
valid, but you never need to contact the clueful ones - only the clueless!

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

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


RFC requirements for relative CNAME targets?

2013-07-18 Thread John Miller
Hey there folks,

I know that for the following record in a zone file:

host.example.com.

-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/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: RFC requirements for relative CNAME targets?

2013-07-18 Thread John Miller
My apologies--sent mid-message!

I know that for the following record in example.com's zone file:

host.example.com.  IN CNAME otherhost

BIND will return:

host.example.com.  IN CNAME otherhost.example.com.

Is this behavior required anywhere in the RFCs, or would

host.example.com.  IN CNAME otherhost.

be equally valid from an RFC perspective?  Obviously this would also
pertain to NS, MX, SRV, PTR, etc. records.

John


On Thu, Jul 18, 2013 at 4:12 PM, John Miller  wrote:

> Hey there folks,
>
> I know that for the following record in a zone file:
>
> host.example.com.
>
> --
> John Miller
> Systems Engineer
> Brandeis University
> johnm...@brandeis.edu
> (781) 736-4619
>
___
Please visit https://lists.isc.org/mailman/listinfo/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: RFC requirements for relative CNAME targets?

2013-07-18 Thread Charles Swiger
On Jul 18, 2013, at 1:18 PM, John Miller  wrote:
> I know that for the following record in example.com's zone file:
> 
> host.example.com.  IN CNAME otherhost
> 
> BIND will return:
> 
> host.example.com.  IN CNAME otherhost.example.com.

Assuming $ORIGIN is set to example.com, but yes.

> Is this behavior required anywhere in the RFCs, or would
> 
> host.example.com.  IN CNAME otherhost.
> 
> be equally valid from an RFC perspective?  Obviously this would also pertain 
> to NS, MX, SRV, PTR, etc. records.

"otherhost." is equally valid from an RFC perspective, or 
"otherhost.other.domain."  If there is a trailing dot, the CNAME target is 
assumed to be fully qualified, otherwise $ORIGIN is appended just as it would 
be for any other record using an unqualified name.

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: RFC requirements for relative CNAME targets?

2013-07-18 Thread John Miller
On Thu, Jul 18, 2013 at 4:29 PM, Charles Swiger  wrote:

> On Jul 18, 2013, at 1:18 PM, John Miller  wrote:
> > I know that for the following record in example.com's zone file:
> >
> > host.example.com.  IN CNAME otherhost
> >
> > BIND will return:
> >
> > host.example.com.  IN CNAME otherhost.example.com.
>
> Assuming $ORIGIN is set to example.com, but yes.
>
> > Is this behavior required anywhere in the RFCs, or would
> >
> > host.example.com.  IN CNAME otherhost.
> >
> > be equally valid from an RFC perspective?  Obviously this would also
> pertain to NS, MX, SRV, PTR, etc. records.
>
> "otherhost." is equally valid from an RFC perspective, or
> "otherhost.other.domain."  If there is a trailing dot, the CNAME target is
> assumed to be fully qualified, otherwise $ORIGIN is appended just as it
> would be for any other record using an unqualified name.
>
> Regards,
> --
> -Chuck
>
>
I think what I was getting at was whether appending $ORIGIN to an
unqualified target--only talking target, not label--was _required_ by the
RFCs, and if so, the RFC/section.  I'll read through 'em; was just hoping
someone knew the answer off the top of their head.

John
___
Please visit https://lists.isc.org/mailman/listinfo/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: RFC requirements for relative CNAME targets?

2013-07-18 Thread Novosielski, Ryan
Are you asking if the target of a CNAME need be an FQDN if $ORIGIN is defined? 
If so, no, I use short names (no trailing dot) all the time.


From: John Miller [mailto:johnm...@brandeis.edu]
Sent: Thursday, July 18, 2013 05:49 PM
To: Bind Users Mailing List 
Subject: Re: RFC requirements for relative CNAME targets?


On Thu, Jul 18, 2013 at 4:29 PM, Charles Swiger 
mailto:cswi...@mac.com>> wrote:
On Jul 18, 2013, at 1:18 PM, John Miller 
mailto:johnm...@brandeis.edu>> wrote:
> I know that for the following record in example.com's 
> zone file:
>
> host.example.com.  IN CNAME otherhost
>
> BIND will return:
>
> host.example.com.  IN CNAME 
> otherhost.example.com.

Assuming $ORIGIN is set to example.com, but yes.

> Is this behavior required anywhere in the RFCs, or would
>
> host.example.com.  IN CNAME otherhost.
>
> be equally valid from an RFC perspective?  Obviously this would also pertain 
> to NS, MX, SRV, PTR, etc. records.

"otherhost." is equally valid from an RFC perspective, or 
"otherhost.other.domain."  If there is a trailing dot, the CNAME target is 
assumed to be fully qualified, otherwise $ORIGIN is appended just as it would 
be for any other record using an unqualified name.

Regards,
--
-Chuck


I think what I was getting at was whether appending $ORIGIN to an unqualified 
target--only talking target, not label--was _required_ by the RFCs, and if so, 
the RFC/section.  I'll read through 'em; was just hoping someone knew the 
answer off the top of their head.

John
___
Please visit https://lists.isc.org/mailman/listinfo/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: RFC requirements for relative CNAME targets?

2013-07-18 Thread Barry Margolin
In article ,
 John Miller  wrote:

> I think what I was getting at was whether appending $ORIGIN to an
> unqualified target--only talking target, not label--was _required_ by the
> RFCs, and if so, the RFC/section.  I'll read through 'em; was just hoping
> someone knew the answer off the top of their head.

All names in a zone file that do not end with "." get the $ORIGIN 
appended to them. This is required by the zone file specification.

-- 
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: RFC requirements for relative CNAME targets?

2013-07-18 Thread John Levine
>I think what I was getting at was whether appending $ORIGIN to an
>unqualified target--only talking target, not label--was _required_ by the
>RFCs, and if so, the RFC/section.  I'll read through 'em; was just hoping
>someone knew the answer off the top of their head.

RFC 1034, page 34.

R's,
John
___
Please visit https://lists.isc.org/mailman/listinfo/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: RFC requirements for relative CNAME targets?

2013-07-18 Thread John Miller

On 07/18/2013 06:07 PM, Barry Margolin wrote:

In article ,
  John Miller  wrote:


I think what I was getting at was whether appending $ORIGIN to an
unqualified target--only talking target, not label--was _required_ by the
RFCs, and if so, the RFC/section.  I'll read through 'em; was just hoping
someone knew the answer off the top of their head.


All names in a zone file that do not end with "." get the $ORIGIN
appended to them. This is required by the zone file specification.



Thanks, Barry.  That's exactly what I wanted to know--it _is_ required 
by the RFCs.


John
___
Please visit https://lists.isc.org/mailman/listinfo/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: RFC requirements for relative CNAME targets?

2013-07-18 Thread John Miller

Hi Ryan,

Sorry I wasn't more clear in my original post.  Barry hit the nail on 
the head:  I was curious if the RFCs required BIND to append $ORIGIN to 
targets that aren't fully qualified.  Sounds like they do.


I appreciate the help!

John



On 07/18/2013 05:59 PM, Novosielski, Ryan wrote:

Are you asking if the target of a CNAME need be an FQDN if $ORIGIN is
defined? If so, no, I use short names (no trailing dot) all the time.


*From*: John Miller [mailto:johnm...@brandeis.edu]
*Sent*: Thursday, July 18, 2013 05:49 PM
*To*: Bind Users Mailing List 
*Subject*: Re: RFC requirements for relative CNAME targets?


On Thu, Jul 18, 2013 at 4:29 PM, Charles Swiger mailto:cswi...@mac.com>> wrote:

On Jul 18, 2013, at 1:18 PM, John Miller mailto:johnm...@brandeis.edu>> wrote:
 > I know that for the following record in example.com
's zone file:
 >
 > host.example.com .  IN CNAME otherhost
 >
 > BIND will return:
 >
 > host.example.com .  IN CNAME
otherhost.example.com .

Assuming $ORIGIN is set to example.com , but yes.

 > Is this behavior required anywhere in the RFCs, or would
 >
 > host.example.com .  IN CNAME otherhost.
 >
 > be equally valid from an RFC perspective?  Obviously this would
also pertain to NS, MX, SRV, PTR, etc. records.

"otherhost." is equally valid from an RFC perspective, or
"otherhost.other.domain."  If there is a trailing dot, the CNAME
target is assumed to be fully qualified, otherwise $ORIGIN is
appended just as it would be for any other record using an
unqualified name.

Regards,
--
-Chuck


I think what I was getting at was whether appending $ORIGIN to an
unqualified target--only talking target, not label--was _required_ by
the RFCs, and if so, the RFC/section.  I'll read through 'em; was just
hoping someone knew the answer off the top of their head.

John

___
Please visit https://lists.isc.org/mailman/listinfo/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: RFC requirements for relative CNAME targets?

2013-07-18 Thread John Miller

On 07/18/2013 06:07 PM, Barry Margolin wrote:

In article ,
  John Miller  wrote:


I think what I was getting at was whether appending $ORIGIN to an
unqualified target--only talking target, not label--was _required_ by the
RFCs, and if so, the RFC/section.  I'll read through 'em; was just hoping
someone knew the answer off the top of their head.


All names in a zone file that do not end with "." get the $ORIGIN
appended to them. This is required by the zone file specification.



Thanks to everyone for their help with this.  You also spurred me to dig 
into RFC 1034/1035 a bit more deeply than I'd done in the past.  Not as 
painful as I'd feared.


From RFC 1035, Section 5.1:
"Domain names which do not end in a dot are called relative; the actual 
domain name is the concatenation of the relative part with an origin 
specified in a $ORIGIN, $INCLUDE, or as an argument to the master file 
loading routine.  A relative name is an error when no origin is available."


In other words, for any record type that contains a domain name in its 
RDATA section (CNAME, NS, SOA, MX, SRV, etc.), the nameserver must make 
sure that the domain name is either fully qualified, or it must append 
an origin somehow.


John


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

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